Вихідна дата публікації: 11 липня 2025 р.
Ідентифікатор KB: 5064479
У цій статті:
Вступ
У цій статті наведено огляд майбутніх змін до функції аудиту NT LAN Manager (NTLM) у Windows 11 версії 24H2 та Windows Server 2025. Ці вдосконалення дають змогу підвищити видимість дії автентифікації NTLM, що дає змогу адміністраторам визначати ідентифікаційні дані користувачів, обґрунтування використання NTLM і певні розташування, де NTLM використовується в середовищі. Розширений аудит підтримує покращений моніторинг безпеки та ідентифікацію застарілих залежностей автентифікації.
Призначення змін аудиту NTLM
Автентифікація NTLM продовжує існувати в різних корпоративних сценаріях, часто через застарілі програми та конфігурації. Оголошення про вилучення NTLM і подальше вимкнення (див. ІТ-блог Windows Еволюція автентифікації Windows) оновлені функції аудиту призначені для того, щоб допомогти адміністраторам визначити використання NTLM, зрозуміти закономірності використання та виявити потенційні ризики для безпеки, зокрема використання NT LAN Manager версії 1 (NTLMv1).
Журнали аудиту NTLM
Windows 11 версії 24H2 та Windows Server 2025 запроваджено нові можливості журналювання аудиту NTLM для клієнтів, серверів і контролерів домену. Кожен компонент створює журнали, які надають докладні відомості про події автентифікації NTLM. Ці журнали можна знайти в перегляд подій в розділі Журнали програм і служб > Microsoft > Windows > NTLM > Operational.
У порівнянні з наявними журналами аудиту NTLM нові вдосконалені зміни аудиту дають змогу адміністраторам відповідати на запитання Who (Хто), The Why (Причини) і Where (Де):
-
Хто використовує протокол NTLM, зокрема обліковий запис і процес на комп'ютері.
-
Чому було вибрано автентифікацію NTLM замість сучасних протоколів автентифікації, таких як Kerberos.
-
Коли відбувається автентифікація NTLM, включно з іменем комп'ютера та IP-адресою комп'ютера.
Розширений аудит NTLM також містить відомості про використання NTLMv1 для клієнтів і серверів, а також доменне використання NTLMv1, зареєстроване контролером домену.
керування Групова політика
Нові функції аудиту NTLM можна настроїти в оновлених параметрах Групова політика. Адміністратори можуть використовувати ці політики, щоб визначити, які події автентифікації NTLM перевіряються, і керувати поведінкою аудиту для клієнтів, серверів і контролерів домену відповідно до їхнього середовища.
За замовчуванням події ввімкнуто.
-
Для журналювання клієнтів і серверів події контролюються за допомогою політики "NTLM Enhanced Logging" у розділі Адміністративні шаблони > System > NTLM.
-
Для домену входу на контролері домену, події контролюються за допомогою політики "Журнали NTLM розширеного домену" в розділі адміністративних шаблонів > система > Netlogon.
Рівні аудиту
Кожен контрольний журнал NTLM розділено на два різні ідентифікатори подій з однаковими відомостями, які відрізняються лише за рівнем подій:
-
Відомості: указує на стандартні події NTLM, наприклад автентифікацію диспетчера NT LAN Manager версії 2 (NTLMv2), де не виявлено зниження безпеки.
-
Увага! Позначає пониження рівня безпеки NTLM, наприклад використання NTLMv1. Ці події виділяють незахищену автентифікацію. Подію може бути позначено як "Попередження" для таких випадків:
-
Використання NTLMv1 виявлено клієнтом, сервером або контролером домену.
-
Розширений захист для автентифікації позначається як не підтримуваний або незахищений (докладні відомості див. в статті KB5021989: розширений захист для автентифікації).
-
Деякі функції безпеки NTLM, наприклад перевірка цілісності повідомлень (MIC), не використовуються.
-
Журнали клієнтів
Нові журнали аудиту записують вихідні спроби автентифікації NTLM. Ці журнали містять відомості про програми або служби, що ініціюють підключення NTLM, а також відповідні метадані для кожного запиту автентифікації.
Журналювання клієнтів має унікальне поле з ідентифікатором використання або причиною, яке підкреслює, чому було використано автентифікацію NTLM.
ID |
Опис |
0 |
Невідома причина. |
1 |
Виклик NTLM викликано безпосередньо програмою, що викликається. |
2 |
Автентифікація локального облікового запису. |
3 |
RESERVED, який зараз не використовується. |
4 |
Автентифікація хмарного облікового запису. |
5 |
Ім'я цільового об'єкта відсутнє або пусте. |
6 |
Не вдалося розпізнати цільове ім'я За допомогою Kerberos або інших протоколів. |
7 |
Цільове ім'я містить IP-адресу. |
8 |
У службі Active Directory знайдено цільове ім'я. |
9 |
Не вдалося встановити лінію зору за допомогою контролера домену. |
10 |
NTLM викликано за допомогою інтерфейсу замикання на себе. |
11 |
Викликано NTLM із null-сеансом. |
Журнал подій |
Microsoft-Windows-NTLM/Operational |
Ідентифікатор події |
4020 (Відомості), 4021 (попередження) |
Джерело події |
NTLM (NTLM) |
Текст події |
Цей комп'ютер спробував автентифікувати віддалений ресурс за допомогою NTLM. Відомості про процес: Ім'я процесу: ім'я <> Ідентифікатор PID процесу: <> PID Відомості про клієнт: Ім'я користувача: <ім'я користувача> Домен: <> імені домену Ім'я хоста: <ім'я хоста> тип Sign-On: <одинарний Sign-On / Доданий creds> Цільова інформація: Цільовий комп'ютер:> імені <комп'ютера Цільовий домен: <> домену комп'ютера Цільовий ресурс: ім'я учасника служби <(SPN)> Цільова IP-адреса: IP-адреса <> Цільове мережеве ім'я: <> мережевого імені Використання NTLM: Ідентифікатор причини: ідентифікатор <використання> Причина: <причина використання> Безпека NTLM: Позначки узгодження: прапори <> Версія NTLM: <NTLMv2 / NTLMv1> Стан ключа сеансу: < присутній або відсутній> Прив'язування каналу: < підтримується або не підтримується> Зв'язування служби: ім'я учасника служби <(SPN)> Стан мікрофона: < захищений або незахищений> AvFlags: <позначки NTLM> Рядок AvFlags: <рядок позначки NTLM> Докладні відомості див. в статті aka.ms/ntlmlogandblock. |
Журнали серверів
Нові журнали аудиту записують вхідні спроби автентифікації NTLM. У цих журналах містяться подібні відомості про автентифікацію NTLM, як журнали клієнта, а також звіт про успішність автентифікації NTLM.
Журнал подій |
Microsoft-Windows-NTLM/Operational |
Ідентифікатор події |
4022 (Відомості), 4023 (попередження) |
Джерело події |
NTLM (NTLM) |
Текст події |
Віддалений клієнт використовує протокол NTLM для автентифікації на цій робочій станції. Відомості про процес: Ім'я процесу: ім'я <> Ідентифікатор PID процесу: <> PID Відомості про віддалений клієнт: Ім'я користувача: ім'я користувача клієнта <> Домен: <клієнтський домен> Клієнтський комп'ютер:> імені клієнтського комп'ютера < IP-адреса клієнта: IP-> <клієнта Мережеве ім'я клієнта: <мережеве ім'я клієнта> Безпека NTLM: Позначки узгодження: прапори <> Версія NTLM: <NTLMv2 / NTLMv1> Стан ключа сеансу: < присутній або відсутній> Прив'язування каналу: < підтримується або не підтримується> Зв'язування служби: ім'я учасника служби <(SPN)> Стан мікрофона: < захищений або незахищений> AvFlags: <позначки NTLM> Рядок AvFlags: <рядок позначки NTLM> Стан: <код стану> Повідомлення про стан: рядок стану <> Докладні відомості див. в статті aka.ms/ntlmlogandblock |
Журнали контролера домену
Контролери домену отримують перевагу розширеного аудиту NTLM із новими журналами, які записують успішну та невдалу автентифікацію NTLM для всього домену. Ці журнали підтримують ідентифікацію міждоменного використання NTLM і оповіщають адміністраторів про потенційні пониження системи безпеки автентифікації, наприклад автентифікацію NTLMv1.
Різні журнали контролера домену створюються залежно від таких сценаріїв:
Якщо обліковий запис клієнта та серверний комп'ютер належать до одного домену, створюється журнал, подібний до такого:
Журнал подій |
Microsoft-Windows-NTLM/Operational |
Ідентифікатор події |
4032 (Відомості), 4033 (попередження) |
Джерело події |
Security-Netlogon |
Текст події |
Dc <DC Name> обробив запит автентифікації NTLM, який походить із цього домену. Відомості про клієнт: Ім'я клієнта: <ім'я користувача> Домен клієнта: <домен> Клієнтський комп'ютер:> робочої станції клієнта < Відомості про сервер: Ім'я сервера: ім'я комп'ютера <сервера> Домен сервера:> домену сервера < IP-адреса сервера: IP-<сервера> ОС сервера:> операційної системи <Server Безпека NTLM: Позначки узгодження: прапори <> Версія NTLM: <NTLMv2 / NTLMv1> Стан ключа сеансу: < присутній або відсутній> Прив'язування каналу: < підтримується або не підтримується> Зв'язування служби: ім'я учасника служби <(SPN)> Стан мікрофона: < захищений або незахищений> AvFlags: <позначки NTLM> Рядок AvFlags: <рядок позначки NTLM> Стан: <код стану> Повідомлення про стан: рядок стану <> Докладні відомості див. в статті aka.ms/ntlmlogandblock |
Якщо клієнтський обліковий запис і сервер належать до різних доменів, контролер домену матиме різні журнали залежно від того, чи контролер домену належить до домену, де розташовано клієнт (ініціюючи автентифікацію) або де розташовано сервер (прийняття автентифікації):
Якщо сервер належить до того ж домену, що й контролер домену, який обробляє автентифікацію, створюється журнал, схожий на "Журнал домену".
Якщо клієнтський обліковий запис належить до домену, що й контролер домену, який обробляє автентифікацію, створюється журнал, подібний до такого:
Журнал подій |
Microsoft-Windows-NTLM/Operational |
Ідентифікатор події |
4030 (Відомості), 4031 (попередження) |
Джерело події |
Security-Netlogon |
Текст події |
Dc <DC Name> обробив запит автентифікації NTLM, який походить із цього домену. Відомості про клієнт: Ім'я клієнта: <ім'я користувача> Домен клієнта: <домен> Клієнтський комп'ютер:> робочої станції клієнта < Відомості про сервер: Ім'я сервера: ім'я комп'ютера <сервера> Домен сервера:> домену сервера < Переслано з: Тип захищеного каналу: <Відомості про безпечний канал> Далеке ім'я: <міждоменний dc ім'я комп'ютера > Farside Domain(Домен): <міждоменне ім'я домену> Farside IP: <cross-Domain DC IP> Безпека NTLM: Позначки узгодження: прапори <> Версія NTLM: <NTLMv2 / NTLMv1> Стан ключа сеансу: < присутній або відсутній> Прив'язування каналу: < підтримується або не підтримується> Зв'язування служби: ім'я учасника служби <(SPN)> Стан мікрофона: < захищений або незахищений> AvFlags: <позначки NTLM> Рядок AvFlags: <рядок позначки NTLM> Стан: <код стану> Докладні відомості див. в статті aka.ms/ntlmlogandblock |
Зв'язок між новими та наявними подіями NTLM
Нові події NTLM покращать наявні журнали NTLM, наприклад мережеву безпеку: обмежити автентифікацію NTLM Audit NTLM у цьому домені. Розширені зміни аудиту NTLM не впливають на поточні журнали NTLM; якщо активовано поточні журнали аудиту NTLM, вони будуть і надалі записуватися до журналу.
Відомості про розгортання
Відповідно до розгортання функцій, контрольованих корпорацією Майкрософт (CFR), зміни спочатку поступово розгортатимуться до комп'ютерів Windows 11 версії 24H2, а потім комп'ютерів Windows Server 2025, включаючи контролери домену.
Поступове розгортання розповсюджує оновлення випуску протягом певного періоду часу, а не відразу. Це означає, що користувачі отримують оновлення в різний час, і вони можуть бути доступні не відразу для всіх користувачів.