Огляд удосконалень аудиту протоколу NTLM у Windows 11Windows 11 версії 24H2 та Windows ServerWindows Server 2025

Примітка.

  • Дата початкової публікації: 11 липня 2025 р.
  • Ідентифікатор бази знань: 5064479

У цій статті:

Вступ

У цій статті наведено огляд майбутніх змін у функціях аудиту NT LAN Manager (NTLM) у Windows 11Windows 11 версії 24H2 та Windows ServerWindows Server 2025. Ці вдосконалення покликані збільшити видимість автентифікації NTLM, даючи змогу адміністраторам визначити ідентичність користувачів, обґрунтування використання NTLM і конкретні розташування, де NTLM використовується в середовищі. Розширений аудит підтримує покращений моніторинг безпеки та виявлення залежностей старої автентифікації.

Мета змін аудиту NTLM

Автентифікація NTLM продовжує бути присутньою в різних корпоративних сценаріях, часто через застарілі програми та конфігурації. У зв'язку з оголошенням про відхилення протоколу NTLM і його подальше вимкнення (див. блог Windows IT " Еволюція автентифікації Windows"), оновлені функції аудиту покликані допомогти адміністраторам у визначенні використання протоколу NTLM, розумінні моделей використання та виявленні потенційних загроз безпеці, включаючи використання NTLM LAN Manager версії 1 (NTLM v1).

Журнали аудиту протоколу NTLM

Windows 11Windows 11, версії 24H2 та Windows ServerWindows Server 2025 Запровадити нові можливості журналювання перевірки NTLM для клієнтів, серверів і контролерів доменів. Кожен компонент створює журнали з докладною інформацією про події автентифікації NTLM. Ці журнали можна знайти в перегляд подій в розділі "Журнали програм і служб">Microsoft>Windows>NTLM>Operational.

У порівнянні з існуючими журналами аудиту NTLM, нові розширені зміни аудиту дозволяють адміністраторам відповідати на запитання «Хто», «Чому» та «Де»:

  • хто використовує протокол NTLM, включно з обліковим записом і процесом на комп'ютері.
  • Чому було обрано автентифікацію NTLM, а не сучасні протоколи автентифікації, як-от Kerberos.
  • Місце виконання автентифікації NTLM, включно з іменем комп'ютера та IP-адресою комп'ютера.

Розширений аудит NTLM також надає відомості про використання NTLMv1 для клієнтів і серверів, а також про використання NTLMv1 у межах домену, зареєстроване контролером домену.

Group PolicyГрупова політика management

Нові функції аудиту NTLM можна налаштувати за допомогою оновлених параметрів Групова політика. Адміністратори можуть використовувати ці політики, щоб визначити, які події автентифікації NTLM відстежувати, а також керувати поведінкою клієнтів, серверів і контролерів доменів відповідно до їхнього середовища.

За замовчуванням події ввімкнуто.

  • Для журналювання на клієнті та сервері події контролюються за допомогою політики "Розширене журналювання NTLM" усистемі>адміністративних шаблонів>NTLM.

    Політика розширеного журналювання NTLM

  • Для журналювання на рівні домену на контролері домену керування подіями здійснюється за допомогою політики "Журнали NTLM для всього домену" розділу "Адміністрування шаблонів>System>Netlogon".

    Політика журналів NTLM для всього домену

Рівні аудиту

Кожен контрольний журнал NTLM розділено на два різні ідентифікатори подій з однаковими відомостями, які відрізняються лише залежно від рівня події.

  • Відомості: указує на стандартні події NTLM, як-от автентифікація в Диспетчері локальної мережі NTLM версії 2 (NTLMv2), коли не виявлено зниження безпеки.

  • Попередження: указує на зниження рівня безпеки протоколу NTLM, наприклад на використання NTLMv1. Ці події свідчать про небезпечну автентифікацію. Подію може бути позначено як "попередження" в таких випадках:

    • Використання протоколу NTLMv1, виявленого клієнтом, сервером або контролером домену.
    • Розширений захист для автентифікації позначено як такий, що не підтримується або незахищений (додаткові відомості див. у KB5021989. Розширений захист для автентифікації).
    • Деякі функції безпеки NTLM, наприклад перевірка цілісності повідомлень (MIC), не використовуються.

Журнали клієнта

У нових контрольних журналах записуються вихідні спроби автентифікації NTLM. Ці журнали містять відомості про програми та служби, які ініціюють підключення NTLM, а також відповідні метадані для кожного запиту автентифікації.

Журналювання клієнта має унікальне поле «Ідентифікатор використання/причина», яке підкреслює, чому було використано автентифікацію NTLM.

Поточний опис полів поля "Ідентифікатор використання/причина"
Ідентифікатор Опис
0 Причина невідома.
1 Протокол NTLM викликався безпосередньо програмою, що викликала виклик.
2 Автентифікація локального облікового запису.
3 ЗАРЕЗЕРВОВАНО, зараз не використовується.
4 Автентифікація хмарного облікового запису.
5 Цільове ім'я було відсутнє або пусте.
6 Не вдалося визначити цільове ім'я за допомогою Kerberos або інших протоколів.
7 Цільове ім'я містить IP-адресу.
8 Виявилося, що цільове ім'я дублюється в Active Directory.
9 Не вдалося встановити лінію прямої видимості за допомогою контролера домену.
10 NTLM викликався через інтерфейс зациклення.
11 NTLM було викликано з нульовим сеансом.
Приклад журналу клієнта
Журнал подій Microsoft-Windows-NTLM/Operational
Ідентифікатор події 4020 (інформація), 4021 (попередження)
Джерело події NTLM
Текст події Цей комп'ютер спробував автентифікуватися на віддаленому ресурсі за допомогою протоколу NTLM.
Інформація про процес:
Ім'я процесу: <Ім'я>
PID процесу: <PID>
Інформація про клієнта:
Ім'я користувача: <Ім'я користувача>
Домен: <Доменне ім'я>
Hostname (Ім'я хоста): <Host Name (Ім'я хоста);>
Sign-On Тип: <Одинарний Sign-On / Креди, що поставляються в комплекті>
Цільова інформація:
Цільовий комп'ютер: <Ім'я комп'ютера>
Цільовий домен: <домен комп'ютера>
Цільовий ресурс: <ім'я учасника-служби (SPN)>
Цільова IP-адреса: <IP-адреса>
Цільове мережеве ім'я: <Мережеве ім'я>
Використання NTLM:
Ідентифікатор причини: <Ідентифікатор використання>
Причина: <Причина використання>
Безпека NTLM:
Узгоджені прапори: <Прапори>
Версія NTLM: <NTLMv2 / NTLMv1>
Статус ключа сеансу: < присутній / відсутній>
Прив'язка каналу: < підтримується або не підтримується>
Прив'язування служби: <ім'я учасника служби (SPN)>
Стан MIC: < захищено / незахищено>
AvFlags: <прапори NTLM>
Рядок AvFlags: <NTLM Рядок позначки>
Додаткові відомості див. у aka.ms/ntlmlogandblock.

Журнали сервера

У нових контрольних журналах записуються вхідні спроби автентифікації NTLM. Ці журнали містять схожі відомості про автентифікацію NTLM, що й журнали клієнта, а також інформацію про успішну автентифікацію NTLM.

Приклад журналу сервера
Журнал подій Microsoft-Windows-NTLM/Operational
Ідентифікатор події 4022 (інформація), 4023 (попередження)
Джерело події NTLM
Текст події Віддалений клієнт використовує протокол NTLM для автентифікації на цій робочій станції.
Інформація про процес:
Ім'я процесу: <Ім'я>
PID процесу: <PID>
Відомості про віддаленого клієнта:
Ім'я користувача: <Ім'я користувача клієнта>
Домен: <Домен клієнта>
Клієнтський комп'ютер: <ім'я клієнтського комп'ютера>
IP-адреса клієнта: <IP-адреса клієнта>
Ім'я клієнтської мережі: <Ім'я мережі клієнта>
Безпека NTLM:
Узгоджені прапори: <Прапори>
Версія NTLM: <NTLMv2 / NTLMv1>
Статус ключа сеансу: < присутній / відсутній>
Прив'язка каналу: < підтримується або не підтримується>
Прив'язування служби: <ім'я учасника служби (SPN)>
Стан MIC: < захищено / незахищено>
AvFlags: <прапори NTLM>
Рядок AvFlags: <NTLM Рядок позначки>
Стан: <код стану>
Повідомлення стану: <рядок стану>
Додаткові відомості див. в aka.ms/ntlmlogandblock

Журнали контролера домену

Контролери домену можуть скористатися перевагами розширеного аудиту NTLM із новими журналами, які записують успішні та невдалі спроби автентифікації NTLM для всього домену. Ці журнали дають змогу визначати міждоменне використання протоколу NTLM і попереджати адміністраторів про потенційне зниження рівня безпеки автентифікації, наприклад автентифікації NTLMv1.

Різні журнали контролера домену створюються в залежності від таких сценаріїв:

Журнал одного домену

Якщо і обліковий запис клієнта, і серверний комп'ютер належать одному домену, створюється журнал, схожий на такий:

Журнал подій Microsoft-Windows-NTLM/Operational
Ідентифікатор події 4032 (інформація), 4033 (попередження)
Джерело події Security-Netlogon
Текст події <Ім'я DC DC обробляє> пересланий запит автентифікації NTLM, що походить із цього домену.
Інформація про клієнта:
Ім'я клієнта: <Ім'я користувача>
Домен клієнта: <Domain>
Клієнт-комп'ютер: <Клієнтська робоча станція>
Відомості про сервер:
Ім'я сервера: <Ім'я серверного комп'ютера>
Домен сервера: <Домен сервера>
IP-адреса сервера: <IP-адреса сервера>
ОС сервера: <серверна операційна система>
Безпека NTLM:
Узгоджені прапори: <Прапори>
Версія NTLM: <NTLMv2 / NTLMv1>
Статус ключа сеансу: < присутній / відсутній>
Прив'язка каналу: < підтримується або не підтримується>
Прив'язування служби: <ім'я учасника служби (SPN)>
Стан MIC: < захищено / незахищено>
AvFlags: <прапори NTLM>
Рядок AvFlags: <NTLM Рядок позначки>
Стан: <код стану>
Повідомлення стану: <рядок стану>
Додаткові відомості див. в aka.ms/ntlmlogandblock
Міждоменний журнал

Якщо обліковий запис клієнта та сервер належать до різних доменів, контролер домену матиме різні журнали залежно від того, чи належить контролер домену до домену, у якому перебуває клієнт (ініціює автентифікацію), чи де перебуває сервер (приймає автентифікацію):

Якщо сервер належить до того самого домену, що й контролер домену, який обробляє автентифікацію, створюється журнал, подібний до журналу того самого домену.

Якщо обліковий запис клієнта належить до того самого домену, що й контролер домену, який обробляє автентифікацію, створюється журнал приблизно такого:

Журнал подій Microsoft-Windows-NTLM/Operational
Ідентифікатор події 4030 (довідка), 4031 (попередження)
Джерело події Security-Netlogon
Текст події <Ім'я DC DC обробляє> пересланий запит автентифікації NTLM, що походить із цього домену.
Інформація про клієнта:
Ім'я клієнта: <Ім'я користувача>
Домен клієнта: <Domain>
Клієнт-комп'ютер: <Клієнтська робоча станція>
Відомості про сервер:
Ім'я сервера: <Ім'я серверного комп'ютера>
Домен сервера: <Домен сервера>
Переслано від:
Тип захищеного каналу: <Netlogon Відомості про захищений канал>
Farside name: <Cross-Domain DC Machine Name >
Домен Farside: <міждоменне ім'я домену>
Farside IP: <міждоменна IP-адреса DC>
Безпека NTLM:
Узгоджені прапори: <Прапори>
Версія NTLM: <NTLMv2 / NTLMv1>
Статус ключа сеансу: < присутній / відсутній>
Прив'язка каналу: < підтримується або не підтримується>
Прив'язування служби: <ім'я учасника служби (SPN)>
Стан MIC: < захищено / незахищено>
AvFlags: <прапори NTLM>
Рядок AvFlags: <NTLM Рядок позначки>
Стан: <код стану>
Додаткові відомості див. в aka.ms/ntlmlogandblock

Зв'язок між новими та наявними подіями NTLM

Нові події NTLM – це розширення існуючих журналів NTLM, наприклад "Безпека мережі: обмеження перевірки NTLM" для автентифікації NTLM у цьому домені. Розширені зміни аудиту NTLM не впливають на поточні журнали NTLM; якщо поточні журнали аудиту NTLM увімкнуто, вони й надалі записуватимуться.

Відомості про розгортання

Відповідно до контрольованого корпорацією Майкрософт розгортання функцій (CFR) зміни спочатку поступово розгортатимуться на комп'ютерах Windows 11 версії 24H2, а потім на комп'ютерах Windows Server 2025 року, включно з контролерами доменів.

Поступове розгортання передбачає розповсюдження оновлення випуску протягом певного періоду часу, а не всіх відразу. Це означає, що користувачі отримують оновлення в різний час, тому вони можуть стати доступними не всім користувачам одразу.