NTLM и Kerberos на схемах — почему аутентификация «падает» на NTLM

Даже в корпоративной сети, про которую говорят «у нас среда Kerberos», стоит собрать журналы аудита — и NTLM обязательно обнаружится. Причём обнаруживается обычно приложение, которое как раз и должно поддерживать Kerberos.

«Падение на NTLM» здесь означает не то, что аутентификация останавливается с ошибкой, а переключение на NTLM из-за невозможности использовать Kerberos. Бизнес-система может работать безупречно и при этом не использовать ожидаемый способ аутентификации.

В этой статье мы сначала сравним по схемам, что служит материалом для NTLM и Kerberos и чью подлинность проверяет каждый из них. Когда это различие понятно, из одного и того же механизма объясняется и то, почему аутентификация переключается на NTLM в зависимости от имени назначения или типа учётной записи, и то, почему работают атаки ретрансляции и Pass-the-Hash.

Порядок чтения — различия механизмов → условия переключения → решения о защите и миграции. Если цель — разбор инцидента, сначала разделите «работает на NTLM» и «аутентификация сама остановилась», а затем по путеводителю по целям из главы 1 переходите к главе 6.

Порядок инвентаризации собственной среды (настройка политик аудита, работа с событиями, последовательность исправлений) изложен в парной статье «Остановит ли отказ от NTLM бизнес-приложения?».

1. Сначала вывод

Сначала нужно усвоить три вещи: материал аутентификации, условия переключения на NTLM, а также политику безопасности и миграции.

Разберитесь в различиях механизмов

NTLM строит ответ из хеша, а Kerberos использует билет с указанием назначения. Учётные данные NTLM — это доменное имя, имя пользователя и односторонний хеш пароля.¹ В NTLMv2 ключ, производный от этого хеша, используется для вычисления HMAC по серверному вызову, метке времени, клиентскому вызову и сведениям о целевом объекте (раздел 2.2).²

Kerberos, напротив, выдаёт билет службы на основе SPN — имени службы назначения — и тем самым устанавливает «кто и к какой службе».³ Отсюда следуют три различия: взаимная аутентификация, обращение к контроллеру домена при аутентификации доменной учётной записи и делегирование другим службам (глава 5).⁴

Разделите откат и ошибку аутентификации

«Работает на NTLM» и «останавливается с ошибкой Kerberos» — это разные отправные точки расследования. Основные причины переключения на NTLM — жёстко прописанные IP-адреса, незарегистрированные SPN, рабочие группы и маршруты, не достигающие контроллера домена. Важнее всего — можно ли получить SPN из имени назначения (глава 6).⁵⁶

А проблемы, возникающие после того, как Kerberos уже выбран, например рассинхронизация времени, — это другое: аутентификация сама останавливается. Не считайте, что при любой неудаче происходит повторная попытка через NTLM (раздел 6.5).⁷

Усвойте политику безопасности и миграции

Даже с NTLMv2 остаются атаки ретрансляции и Pass-the-Hash. Ретрансляция следует из того, что обмен аутентификации не привязывает назначение; Pass-the-Hash — из того, что сам хеш служит материалом аутентификации. В главе 7 разобраны условия, при которых работает каждый из них, в том числе требует ли назначение подписи SMB или привязки канала.⁸¹

NTLMv1 уже удалён в Windows 11 версии 24H2 и Windows Server 2025. NTLMv2 ещё работает, но считается устаревшим (глава 8).⁹ Приложения не должны указывать NTLM напрямую: им следует использовать Negotiate, который предпочитает Kerberos, а затем привести в порядок имена, SPN и сетевые маршруты, при которых Kerberos работает.¹

Читайте по цели и симптому

Эта статья объясняет механизмы и решения. За процедурами настройки аудита и проведения инвентаризации обращайтесь к практической парной статье, упомянутой в начале.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 35, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что на самом деле делает NTLM

В этом разделе мы сначала разделим того, кто строит ответ, и того, кто его проверяет. Рассмотрев обмен с участием трёх сторон для доменной учётной записи, мы разберём, что именно вычисляет NTLMv2 и чем отличается локальная учётная запись.

NTLM (Windows Challenge/Response), как следует из названия, — протокол аутентификации по схеме «вызов — ответ». Если кратко изложить описание Microsoft: учётные данные состоят из доменного имени, имени пользователя и одностороннего хеша пароля, полученного при интерактивном входе (хешируется только пароль), и чтобы аутентифицироваться, не передавая пароль по сети, сторона, запрашивающая аутентификацию, выполняет вычисление, доказывающее, что она «может получить доступ к надёжно хранимым учётным данным NTLM».¹

Здесь важно то, что материалом аутентификации служит не сам пароль, а хеш пароля. Именно этот факт делает возможным Pass-the-Hash, как мы увидим дальше.

2.1. При доменной учётной записи участвуют три стороны

Рассмотрим пользователя, который уже вошёл в систему и обращается к ресурсу на сервере под доменной учётной записью. Это неинтерактивная аутентификация, и в ней участвуют следующие три стороны.¹

Ключевой момент: сервер ресурсов не проверяет ответ доменного пользователя сам — он просит контроллер домена выполнить вычисление.

Рис. 1 и семь шагов под ним — это концептуальная процедура со страницы обзора Microsoft. Точное вычисление ответа NTLMv2 рассмотрено в разделе 2.2. Читайте рис. 1 как «кто кого просит проверить», а рис. 2 — как «что именно вычисляется», и они не перепутаются.¹

sequenceDiagram
    autonumber
    participant C as Клиент
    participant S as Сервер
    participant DC as Контроллер домена

    Note over C: При входе вычисляет хеш<br/>пароля и отбрасывает сам пароль
    C->>S: Имя пользователя (открытым текстом)
    S->>C: 8-байтовое случайное число (вызов)
    Note over C: Шифрует вызов<br/>хешем пароля
    C->>S: Ответ
    S->>DC: Имя пользователя / вызов / ответ
    Note over DC: Извлекает хеш из SAM<br/>и выполняет то же вычисление
    DC-->>S: Аутентификация проходит при совпадении
    S-->>C: Предоставляет доступ

Рис. 1: Неинтерактивная аутентификация NTLM (с доменной учётной записью)

Если проследить рис. 1 как процедуру, получаются следующие семь шагов. Само вычисление ответа NTLMv2 изложено ниже, в разделе 2.2.

1. (Только при интерактивной аутентификации) Пользователь вводит доменное имя, имя пользователя и пароль. Клиент вычисляет криптографический хеш пароля и отбрасывает сам пароль.
2. Клиент отправляет серверу имя пользователя открытым текстом.
3. Сервер формирует 8-байтовое случайное число (вызов, nonce) и отправляет его клиенту.
4. Клиент шифрует этот вызов хешем пароля пользователя и возвращает результат (ответ).
5. Сервер отправляет контроллеру домена три вещи: имя пользователя, вызов, который он отправил клиенту, и полученный ответ.
6. Контроллер домена по имени пользователя извлекает хеш пароля из базы данных SAM и шифрует вызов им.
7. Он сравнивает вычисленный результат с ответом клиента; если они совпадают, аутентификация проходит.

2.2. Собственно вычисление — NTLMv2 устроен несколько сложнее

Семь шагов выше — базовая форма, которую Microsoft описывает на странице обзора. NTLMv2, который фактически использует современный Windows, идёт на шаг дальше «зашифровать вызов хешем пароля». Спецификация ([MS-NLMP]) определяет это так.²

Получите ключ ответа, затем вычислите HMAC по вызову и не только

• Ключ ответа — NTOWFv2 = HMAC_MD5( MD4(UNICODE(password)), uppercased user name + domain name )
• Клиент формирует temp — конкатенацию версии ответа, метки времени, 8-байтового вызова, сгенерированного на стороне клиента, и сведений о целевом объекте (пар AV)
• Ядро ответа — NTProofStr = HMAC_MD5( response key, server challenge + temp )

Если свести всё только к входным данным и последовательности обработки, это умещается на одной странице.

flowchart TD
    PW["Пароль"] --> MD4["MD4(UNICODE(password))<br/>= NT-хеш"]
    UD["Имя пользователя в верхнем регистре<br/>+ доменное имя"] --> H1["HMAC_MD5"]
    MD4 -->|"используется как ключ"| H1
    H1 --> KEY["Ключ ответа NTOWFv2"]

    MAT["Версия ответа / метка времени /<br/>8-байтовый клиентский вызов /<br/>сведения о целевом объекте (пары AV)"] --> TEMP["temp"]

    SC["Серверный вызов"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"используется как ключ"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

Рис. 2: Как формируется ответ NTLMv2 (пароль → NT-хеш → ключ ответа → HMAC)

Итак, фактически вычисляется HMAC, в который подмешаны не только серверный вызов, но и клиентское случайное число, метка времени и сведения о целевом объекте. Проверяющая сторона воспроизводит то же вычисление. Если учётная запись находится в Active Directory, пара «вызов/ответ» отправляется на контроллер домена для проверки; если учётная запись локальна для сервера, сервер вычисляет ожидаемое значение из OWF, которое хранит сам.²

Два момента, которые не меняются, как бы ни усложнялось вычисление

Для аргументации этой статьи важно, что при возросшей сложности следующие два момента не меняются.

1. Материалом для ключа по-прежнему служит хеш пароля. Отправная точка NTOWFv2 — это MD4(UNICODE(password)), то есть сам NT-хеш.² Именно поэтому работает Pass-the-Hash (раздел 7.2).
2. Клиент не проверяет подлинность сервера. Утверждение Microsoft о том, что в NTLM нет взаимной аутентификации, справедливо и для NTLMv2.⁴

Всё дальнейшее опирается на эти два пункта.

2.3. При локальной учётной записи достаточно двух сторон

При локальной учётной записи правая часть рис. 1 — контроллер домена — исчезает.

Сервер ресурсов обращается к службе аутентификации на контроллере домена в этом домене, когда учётная запись доменная, но при локальной учётной записи он обращается к локальной базе данных учётных записей.¹⁰

Поэтому на машине в рабочей группе или при доступе к общей папке под локальной учётной записью на файловом сервере контроллер домена не появляется: это обмен между двумя сторонами, в котором сервер смотрит в свой SAM и решает сам.

Это различие напрямую переходит в инвентаризацию зависимостей «Kerberos нельзя использовать, потому что это локальная учётная запись», о которой говорится в разделе 6.3. NTLM, идущий по этому пути, не появляется в журналах аудита контроллера домена.

2.4. Три следствия этой конструкции

Из рассмотренного обмена можно вывести три свойства, которые ведут к последующим сбоям и атакам.

Обращение из второй строки требуется каждый раз, когда серверу ресурсов нужен новый маркер доступа. Для доменной учётной записи он проверяет службу аутентификации на контроллере домена, для локальной — локальную базу данных учётных записей.¹⁰

Кроме того, поскольку вызов меняется каждый раз, один и тот же ответ нельзя просто использовать повторно. Но само по себе это не мешает ретранслировать вызов и ответ живого обмена на другой сервер. Этому различию посвящена глава 7.

3. Почему сервер спрашивает контроллер домена

NTLM просит проверить того, у кого есть хеш

Хеш пароля доменного пользователя находится в базе данных учётных записей на контроллере домена. Сервер ресурсов не знает хеш этого пользователя, поэтому не может проверить полученный ответ самостоятельно.

Поэтому сквозная аутентификация — это передача имени пользователя, вызова и ответа контроллеру домена с просьбой принять решение. Именно из-за такого разделения обязанностей аутентификация NTLM с доменной учётной записью требует обращения к контроллеру домена.¹⁰¹

Для локальной учётной записи хеш проверяется по собственному SAM сервера. Утверждение «NTLM спрашивает контроллер домена» относится только к доменным учётным записям.

Kerberos заменяет обращение билетом

Kerberos заменяет эту сквозную аутентификацию обновляемыми сеансовыми билетами. Microsoft поясняет, что при NTLM серверу приложения приходилось подключаться к контроллеру домена каждый раз, когда он аутентифицировал клиента, тогда как при Kerberos это обращение становится ненужным.⁴

Есть, однако, исключение: когда требуется проверка PAC (сертификата атрибутов привилегий). Это не значит, что при Kerberos трафик от сервера к контроллеру домена отсутствует вовсе.

Поэтому переход на Kerberos даёт не только улучшение безопасности — возможность проверять подлинность партнёра, — но и эксплуатационную выгоду: снижение зависимости от контроллера домена при каждой аутентификации. Как билет выполняет эту роль, разберём в следующем разделе.

4. Что на самом деле делает Kerberos

Там, где в NTLM ответ проверяется при каждой аутентификации, Kerberos доказывает подлинность заранее, получает билет и использует этот билет для следующей аутентификации. На рис. 3 показан весь поток от первичного доказательства подлинности до подключения к службе.

KDC (Key Distribution Center) работает на контроллере домена и использует базу данных служб домена Active Directory в качестве своей базы данных учётных записей безопасности.⁴

Прежде чем читать схему, разделите имена и билеты

В рис. 3 три этапа: доказать подлинность и получить TGT → указать SPN и получить билет службы → предъявить его службе. Главное — не читать TGT и билет службы как одно и то же.

sequenceDiagram
    autonumber
    participant C as Клиент
    participant KDC as KDC (контроллер домена)
    participant S as Служба (идентифицируется по SPN)

    Note over C,KDC: Обмен AS — доказательство подлинности и получение TGT
    C->>KDC: KRB_AS_REQ<br/>(имя пользователя + метка времени, зашифрованная долговременным ключом)
    Note over KDC: Подлинно, если расшифровывается долговременным ключом
    KDC-->>C: KRB_AS_REP<br/>TGT (зашифрован ключом krbtgt) + сеансовый ключ

    Note over C,KDC: Обмен TGS — получение билета службы
    C->>KDC: KRB_TGS_REQ<br/>(TGT + SPN назначения + аутентификатор)
    Note over KDC: Находит учётную запись службы по SPN<br/>и шифрует билет её долговременным ключом
    KDC-->>C: KRB_TGS_REP<br/>Билет службы + сеансовый ключ

    Note over C,S: Обмен AP — предъявление службе
    C->>S: KRB_AP_REQ<br/>(билет службы + аутентификатор)
    Note over S: Расшифровывается собственным долговременным ключом<br/>= билет адресован именно ей
    S-->>C: KRB_AP_REP (когда запрошена взаимная аутентификация)

Рис. 3: Три обмена Kerberos (AS / TGS / AP)

Легенда — AS = Authentication Service, TGS = Ticket Granting Service, AP = Application. В именах сообщений _REQ — запрос, а _REP — ответ. Например, KRB_TGS_REQ означает «запрос к службе выдачи билетов».

4.1. Обмен AS — однократное доказательство подлинности

Что отправляется: метка времени, зашифрованная долговременным ключом

Клиент отправляет KDC своё имя пользователя и доменное имя вместе с меткой времени, зашифрованной собственным долговременным ключом — ключом, производным от пароля. Это предварительная аутентификация. Если KDC может расшифровать её этим долговременным ключом и метка времени действительна, он заключает, что это подлинный пользователь.³

Что принимается: TGT и сеансовый ключ

KDC возвращает две вещи с разными ролями. Обе — «то, что клиент получает», но они различаются тем, может ли клиент прочитать их содержимое.³

Иметь TGT и уметь прочитать его содержимое — разные вещи. Из этого различия вытекает следующий шаг: «сделать запрос вместе с TGT и аутентификатором».

Если часы расходятся, Kerberos сам терпит неудачу

Здесь важно усвоить, что метка времени является частью аутентификации. Именно поэтому Kerberos строг к синхронизации времени: допускаемое расхождение по умолчанию — пять минут.⁷ За пределами этого окна предварительная аутентификация не проходит, и сама аутентификация Kerberos завершается ошибкой (синхронизация времени в Windows описана в «Руководстве по синхронизации времени Windows (w32time)»). Это «Kerberos терпит неудачу» и «переключение на NTLM» — две разные вещи. Различие разобрано в разделе 6.5.

4.2. Обмен TGS — заявляем, к какой службе подключаемся

Получив TGT, клиент запрашивает билет для целевой службы. Именно на этом этапе на первый план выходит имя, указывающее, к какой службе идёт подключение, — SPN.³

Клиент отправляет KDC SPN назначения, TGT и аутентификатор. KDC находит учётную запись службы, соответствующую SPN, шифрует билет службы долговременным ключом этой учётной записи и возвращает его.³

Если прочитать этот поток в обратную сторону, становятся видны проблемы, о которых говорится в главе 6.

• Если SPN не удаётся разрешить, билет выдать нельзя. Если на учётной записи службы не зарегистрирован SPN, KDC не может определить, чей ключ использовать. Подключение по IP-адресу — также условие, при котором Kerberos по умолчанию не предпринимается (раздел 6.1).
• Билет создаётся для своего назначения. Поскольку он зашифрован долговременным ключом этой службы, служба с другим долговременным ключом расшифровать его не может. Поэтому билет нельзя использовать повторно против другого назначения.

4.3. Обмен AP — предъявление службе и взаимная аутентификация

Последний обмен происходит с целевой службой, а не с KDC. Здесь также читайте проверку на стороне службы и проверку на стороне клиента по отдельности.

На стороне службы: вскрытие билета, адресованного ей

Клиент предъявляет билет службы и аутентификатор. Служба расшифровывает билет своим долговременным ключом и извлекает сеансовый ключ и данные авторизации. Возможность расшифровать его своим ключом и подтверждает, что билет адресован ей.³

На стороне клиента: проверка партнёра, когда запрошена взаимная аутентификация

Если клиент запросил взаимную аутентификацию, служба шифрует полученную метку времени сеансовым ключом и возвращает её. Клиент проверяет этот ответ и убеждается, что партнёр — подлинная служба.³

Не только служба проверяет клиента — клиент тоже может проверить службу. Это и есть взаимная аутентификация, которой нет в NTLM.

5. Решающие различия

В этом разделе механизмы из глав 2–4 сравниваются с точки зрения, важной для эксплуатации и проектирования. Обращение к контроллеру домена различается для доменных и локальных учётных записей, а у Kerberos есть собственное исключение — проверка PAC. Читайте условия вместе со строками.

Проект, использующий делегирование, дополнительно выбирает его разновидность

Делегирование — это механизм, с помощью которого, например, внешнее веб-приложение подключается к внутреннему SQL Server от имени пользователя. Олицетворение пользователя внутри одного сервера и перенос личности пользователя в другую службу — две разные вещи.⁴

Делегирование Kerberos бывает неограниченным, ограниченным (constrained delegation) и ограниченным по ресурсам (resource-based constrained delegation, RBCD). Решить «использовать Kerberos» — ещё не всё; какую разновидность делегирования применить — самостоятельный вопрос проектирования.

Эта статья не рассматривает настройку каждой разновидности. Держите эти три названия как следующие поисковые запросы, когда будете разбирать конфигурацию, которой нужно делегирование.

Условия по имени и домену ведут к следующему этапу разбора

Две нижние строки этой таблицы — как раз причины, по которым аутентификация переключается на NTLM. Сильные стороны Kerberos — привязка к назначению и проверка партнёра — опираются на то, что имена разрешаются правильно.

6. Почему аутентификация «падает» на NTLM

В этом разделе мы разбираемся, почему «бизнес-система работает, а аутентификация идёт по NTLM». Проверяйте имя назначения, регистрацию SPN, учётную запись и маршрут до KDC — именно в таком порядке. Если аутентификация сама завершается ошибкой, сначала загляните в раздел 6.5: возможно, нужна другая линия расследования.

NTLM используется даже тогда, когда приложение не указывает NTLM напрямую, потому что так ведёт себя Negotiate. Microsoft описывает Negotiate как выбор между Kerberos и NTLM, причём Kerberos выбирается, если ни одна из систем, участвующих в аутентификации, не может его использовать.¹

Поэтому даже при использовании Negotiate NTLM будет выбран, если выполнены не все условия для Kerberos. «Приложение поддерживает Kerberos» и «в конкретном соединении действительно используется Kerberos» — две разные вещи.

Схема и таблица ниже показывают типичные ветвления в конфигурации, где NTLM доступен. Они не означают, что аутентификация всегда проходит там, где сам NTLM ограничен. Сначала разберитесь в причине переключения, а затем проверяйте ограничения способов аутентификации вместе с главами 8 и 9.

flowchart TD
    START["Аутентификация начинается с Negotiate"]
    Q1{"Доменная<br/>учётная запись?"}
    Q2{"Можно ли построить SPN<br/>из имени назначения?"}
    Q3{"Этот SPN<br/>зарегистрирован?"}
    Q4{"KDC<br/>доступен?"}
    KRB["Аутентификация через Kerberos"]
    NTLM["Переключение на NTLM"]

    START --> Q1
    Q1 -->|"Нет<br/>(рабочая группа / локальная учётная запись)"| NTLM
    Q1 -->|Да| Q2
    Q2 -->|"Нет<br/>(жёстко прописанный IP-адрес)"| NTLM
    Q2 -->|Да| Q3
    Q3 -->|"Нет<br/>(SPN не зарегистрирован / доступ по псевдониму)"| NTLM
    Q3 -->|Да| Q4
    Q4 -->|"Нет<br/>(филиал / VPN / брандмауэр)"| NTLM
    Q4 -->|Да| KRB

Рис. 4: Ветвления, по которым Negotiate переключается на NTLM

Четыре основных фактора сначала изложены в трёх столбцах: условие, почему происходит переключение и как это исправить. Подробности — начиная с раздела 6.1.

6.1. Подключение идёт по IP-адресу

Поведение по умолчанию: для IP-адреса Kerberos не предпринимается

Это самая частая причина. Microsoft прямо указывает, что по умолчанию, когда имя узла — это IP-адрес, Windows не предпринимает аутентификацию Kerberos к этому узлу и переключается на другой допустимый протокол аутентификации, например NTLM.¹¹ Руководство по аудиту говорит то же со своей стороны: Kerberos не используется, если «Target Server» в событии 8001 не в форме NetBIOS и не в форме FQDN.⁵

Причина этого тоже названа: приложения, использующие IP-адрес вместо DNS-имени из-за ошибки конфигурации или указаний в документации поставщика.⁵ На практике чрезвычайно часто встречается настройка, которую кто-то переписал на IP-адрес годы назад «потому что разрешение имён работало ненадёжно» и которая с тех пор так и осталась.

Исключение: задать TryIPSPN и тот SPN, который действительно запрашивается

Отказ от Kerberos для IP-адреса — это поведение по умолчанию, а не абсолютное ограничение. Начиная с Windows 10 версии 1507 и Windows Server 2016 существует механизм, позволяющий использовать IP-адрес как имя узла в SPN.¹¹

Требуется и то и другое.

1. Задать значение реестра TryIPSPN равным 1 на клиенте.
2. Вручную зарегистрировать SPN с IP-адресом в форме Setspn -s <service class>/<IP address> <account>.

Зарегистрированный SPN должен совпадать с классом службы, который клиент фактически запрашивает. Даже для одного и того же IP-адреса назначения требуемое имя различается от службы к службе.

Регистрация только host/ не заставит Kerberos работать, если это не совпадает с запрашиваемым SPN. Microsoft позиционирует эту функцию как способ уменьшить влияние на совместимость при отключении NTLM.¹¹

Сначала исправьте на FQDN, а исключение оставьте крайней мерой

При этом это не первый выбор. Сама Microsoft говорит, что IP-адреса временны и могут вызывать конфликты и сбои аутентификации по мере истечения и продления аренды, поэтому их обычно не используют вместо имён узлов, а регистрация SPN на основе IP-адреса — ручная работа, к которой следует прибегать только тогда, когда переход на DNS-имя узла невозможен.¹¹ Для каждого жёстко прописанного IP-адреса, который обнаружит аудит, сначала подумайте о замене на FQDN. TryIPSPN — крайняя мера для тех партнёров, где это действительно нельзя сделать.

6.2. SPN не зарегистрирован

Следующее, на что нужно посмотреть, — зарегистрировано ли имя, фактически используемое для доступа, как SPN. Microsoft относит приложения, у которых SPN настроен неправильно, к одной из категорий приложений, использующих NTLM несмотря на поддержку Kerberos.⁵

В обмене TGS на рис. 3 KDC находит учётную запись службы по SPN и шифрует билет её долговременным ключом. Без SPN «ключ этой службы» определить нельзя.

То же происходит, когда соединение использует псевдоним DNS (CNAME) или собственное имя узла, а SPN для этого имени не зарегистрирован. «Дойти до сервера по имени» и «получить билет Kerberos для этого имени» — две разные вещи.

Что проверять — имя, записанное в настройке подключения приложения, и SPN для класса службы, запрашиваемого по этому имени. Приложение может работать безупречно, и при этом именно его имя может отсутствовать в регистре.

6.3. Вы изначально вне Active Directory

Найдите маршруты, которым NTLM действительно нужен сегодня

Машины в конфигурации рабочей группы и доступ к общим папкам под локальной учётной записью вообще не находятся на игровом поле Kerberos. Microsoft говорит, что NTLM используется и должен использоваться для аутентификации Windows в системах, настроенных как члены рабочей группы, и для аутентификации при локальном входе на машинах, не являющихся контроллерами домена.¹⁰

Разделите то, что закроет локальный KDC, и то, что он не закроет

Именно поэтому NTLM нельзя просто запретить. Локальный KDC, запланированный на фазу 2, — как раз та функция, которая призвана закрыть этот пробел.⁶

Считайте, однако, что он закрывает пробел только между поддерживающими его версиями Windows. Аутентификация локальной учётной записи к более старым версиям Windows или к сторонним устройствам вроде NAS и многофункциональных устройств не станет автоматически Kerberos с приходом локального KDC. Этому разделению посвящены главы 5 и 6 практической парной статьи.

6.4. KDC недоступен

Филиал или VPN, откуда контроллер домена недоступен, либо брандмауэр, блокирующий нужный для Kerberos трафик, — тоже причина переключения на NTLM.⁶ Это потому, что там, где требуемый билет нельзя получить у KDC, основу для использования Kerberos заложить нельзя.

Здесь разложите «доступен ли контроллер домена» по тому, кто является инициатором трафика.

«Клиент не может дойти до KDC» и «NTLM не нужен контроллер домена» — не одно и то же утверждение. Как показано в главе 3, NTLM с доменной учётной записью требует обращения от сервера к контроллеру домена.¹⁰ Даже когда выбран NTLM, аутентификация не завершится, если потерян и этот маршрут проверки.

6.5. Не путайте отказ Kerberos с переключением на NTLM

Kerberos вообще не запускается — или Kerberos терпит неудачу после того, как был выбран

И последнее: выделим то, что легко перепутать, но что действительно различается. Разделы 6.1–6.4 — все случаи, когда Kerberos не удалось запустить. Поскольку его нельзя запустить, Negotiate выбирает NTLM.

Проблемы, при которых Kerberos терпит неудачу после того, как был выбран, разбираются отдельно. Классический пример — рассинхронизация времени, упомянутая в разделе 4.1.

Если SPN разрешается и KDC доступен, Negotiate выбирает Kerberos первым. Но если расхождение времени превышает допуск, по умолчанию пять минут, предварительная аутентификация не проходит, и это завершается ошибкой Kerberos.⁷

«Выбрать NTLM, потому что Kerberos недоступен» и «повторить попытку через NTLM, потому что выбранный Kerberos дал сбой» — не одно и то же. Negotiate не обязательно идёт так далеко, а случай, когда приложение явно повторяет попытку другим способом, нужно рассматривать отдельно.

Разделите симптомы, прежде чем выбирать журналы и команды

Практический вывод прост. Сбой из-за рассинхронизации времени не найти, если искать событие 8001. Симптомы тоже различаются.

Прежде чем расследовать, разделите «произошло ли переключение на NTLM» и «сломан ли Kerberos». Описанный здесь симптом «работает, но на NTLM» предполагает конфигурацию, в которой NTLM доступен. Ограничения NTLM и его блокировка проверяются отдельно, в главе 8 и главе 9.

7. Различие со стороны атаки — ретрансляция и Pass-the-Hash

И ретрансляция, и Pass-the-Hash обсуждаются как проблемы NTLM, но используют они разное.

В разделе 7.1 сначала рассматриваются условия, при которых ретрансляция проходит, затем в разделе 7.2 — проблема, возникающая при краже хеша.

В документации по параметрам политики Microsoft прямо указывает, что аутентификация NTLM и NTLMv2 уязвима к множеству вредоносных атак, включая ретрансляцию SMB, атаки «злоумышленник посередине» и атаки перебором.⁸ Рис. 1 объясняет почему.

7.1. Атаки ретрансляции — следствие отсутствия привязки к назначению

sequenceDiagram
    autonumber
    participant V as ПК жертвы
    participant A as Сервер атакующего
    participant T as Настоящий сервер

    Note over V,A: Жертву заманивают на сервер атакующего
    V->>A: Начинает аутентификацию (имя пользователя)
    A->>T: Начинает аутентификацию от того же пользователя
    T-->>A: Вызов
    A-->>V: Пересылает этот вызов без изменений
    Note over V: Не может определить, пришёл ли он<br/>от настоящего сервера
    V->>A: Ответ (вычислен ключом, производным от хеша)
    A->>T: Пересылает этот ответ без изменений
    Note over T: Когда ни подпись, ни привязка<br/>канала не требуются
    T-->>A: Аутентификация проходит → соединение установлено как от жертвы

Рис. 5: Как работает ретрансляция NTLM (против партнёра без подписи и привязки канала)

Ретрансляция работает без кражи пароля или хеша

Атакующему не нужно знать ни пароль, ни хеш. Всё, что он делает, — передаёт вызов и ответ с одной стороны на другую. Это работает потому, что у клиента нет способа проверить, действительно ли его ответ идёт тому партнёру, которому он предназначен.

Пройдёт ли она, зависит от защиты назначения

Ретрансляция проходит не к любому партнёру. Превратится ли ретранслированный обмен в работоспособный сеанс, зависит от защиты назначения.

• Она не проходит к партнёру, требующему подписи SMB. Microsoft указывает, что подпись, добавляемая к каждому сообщению SMB, содержит хеш всего сообщения и подтверждает личности отправителя и получателя, что предотвращает атаки ретрансляции.¹² Учтите, что контроллеры домена по умолчанию требуют подпись SMB от всего, что к ним подключается.¹²
• Она не проходит и к службе, применяющей Extended Protection for Authentication (привязку канала). Поскольку это привязывает аутентификацию к нижележащему каналу TLS, аутентификация, ретранслированная в другой канал, больше не проходит.

Рис. 5 предполагает партнёра, который принимает NTLM и не требует ни подписи, ни привязки канала. Не читайте его так, будто эта ретрансляция проходит безусловно на любом соединении, использующем NTLM.

Проверять здесь нужно не только то, «поддерживаются» ли защитные механизмы, но и то, действительно ли они требуются и применяются. Наряду с инвентаризацией NTLM стоит проверить, требует ли конфигурация подписи SMB.

Рассматривайте переход на Kerberos вместе с защитой на стороне SMB

При Kerberos ретрансляция такой формы невозможна в принципе. Билет службы зашифрован долговременным ключом целевой службы, поэтому при переносе в другую службу он остаётся нерасшифровываемым.³ Вдобавок взаимная аутентификация позволяет клиенту проверить подлинность партнёра.⁴

Именно поэтому Microsoft предусмотрела блокировку NTLM на стороне SMB-клиента. Её заявленная цель — предотвратить приёмы, при которых NTLM-запросы отправляются на вредоносный сервер.¹³

Среди своих рекомендаций по подписи SMB Microsoft также называет использование Kerberos вместо NTLMv2, чтобы сеансовый ключ изначально был стойким, и отказ от подключения к общим папкам по IP-адресу или записи CNAME, поскольку из-за этого вместо Kerberos используется NTLM.¹² Это тот же момент, что в разделах 6.1 и 6.2.

7.2. Pass-the-Hash — хеш эквивалентен паролю

flowchart LR
    P["Пароль"] -->|"односторонний хеш"| H["Хеш пароля"]
    H -->|"вывести ключ ответа<br/>и вычислить HMAC"| R["Ответ"]
    R --> AUTH["Аутентификация проходит"]
    STEAL["Хеш похищен<br/>с машины"] --> H
    NOTE["Открытый пароль<br/>не нужен"] -.-> STEAL

Рис. 6: Аутентификации нужен хеш, а не открытый пароль

Проблема в том, что ответ можно построить из хеша

Материал учётных данных NTLM — односторонний хеш пароля.¹ В NTLMv2 ключ ответа тоже выводится с использованием MD4(UNICODE(password)) в качестве ключа, а ответ строится вычислением HMAC этим ключом.²

Так что отправная точка не меняется, как бы ни усложнялось вычисление. Атакующий, получивший хеш, может выполнить вычисление, необходимое для аутентификации под этим пользователем, не взламывая открытый пароль.

Одной сложности пароля этот путь не закрыть

Сделать пароли длинными и сложными — не то же самое, что не дать использовать похищенный хеш. Сложные пароли всё равно оставляют открытым путь кражи хеша и его использования. Microsoft называет Pass-the-Hash наряду с перебором и взломом среди атак, которым противодействует блокировка NTLM на SMB.¹³

У Kerberos тоже есть долговременные ключи. Но в повседневной аутентификации обмениваются билетами и сеансовыми ключами, у которых есть срок действия.³ Сравнение нужно доводить до того, насколько далеко похищенное продвигает атакующего.

8. NTLMv1, NTLMv2 и «удаление»

NTLM — не единый протокол, а семейство протоколов аутентификации, включающее LAN Manager версий 1 и 2 и NTLM версий 1 и 2.¹⁰

Различать здесь нужно устаревание и удаление. Устаревший означает вне активной разработки; удалённый означает непригодный к использованию в соответствующих версиях.

В таблице ниже объявление об устаревании от июня 2024 года сопоставлено с последующим удалением NTLMv1. Не читайте формулировку «всё ещё работает» в первой строке так, будто NTLMv1 пригоден на операционных системах из второй строки. Для NTLMv1 применяется более позднее удаление.⁹

Сначала найдите партнёров, которые умеют только NTLMv1

Так что «мы на NTLMv2, значит, можно пока оставить» не работает. Порядок приоритетов, впрочем, ясен: сначала устройства и узлы, которые умеют говорить только NTLMv1. Узел, записанный в аудите как NTLM V1, перестанет аутентифицироваться, как только его переведут на более новую Windows в текущем виде. Как различать версии по полю «Package Name (NTLM only)» в журнале Security, рассказано в разделе 4.4 практической парной статьи.⁵

Политики ограничения действуют и на v1, и на v2

Учтите, что политики аудита и блокировки, ограничивающие NTLM, оказывают одинаковое действие и на NTLMv1, и на NTLMv2.⁵ Поведение не меняется от версии, когда вы применяете ограничение.

9. Куда всё идёт

Направление миграции проще всего усвоить в таком порядке: изменить то, что вызывают приложения → сократить ситуации, где нужен NTLM → изменить значение по умолчанию для сетевой аутентификации.

Сроки появления IAKerb и локального KDC, описанных ниже, а также изменение значения по умолчанию указаны в приведённой здесь дорожной карте Microsoft как планы. Их не следует воспринимать как уже выпущенные функции или как функции, которые автоматически заработают на каждом устройстве.⁶

Первое: использовать Negotiate на стороне приложения

Замена вызовов NTLM вызовами Negotiate — это указание, содержащееся в самом объявлении об устаревании.⁹ Прямо сказано и то, что приложения не должны обращаться к пакету безопасности NTLM напрямую.¹

Второе: сократить сами ситуации, где нужен NTLM

Сюда относятся IAKerb и локальный KDC, запланированные на фазу 2 (вторая половина 2026 года).⁶ Это попытка закрыть на уровне протокола два пробела из раздела 6.3: «Kerberos нельзя использовать, потому что это локальная учётная запись» и «Kerberos нельзя использовать, потому что контроллер домена недоступен».

Но закрывают они не всё. IAKerb решает вопрос доступности контроллера домена, а не поддержки протокола партнёром. Локальный KDC тоже работает только между поддерживающими его версиями Windows.

Когда партнёр — сторонний NAS или многофункциональное устройство, ожидание фазы 2 ничего не меняет, поэтому выбирать придётся самому: заменить устройство, присоединить его к домену, перейти на другой протокол или держать его как исключение.

Третье: изменить значение по умолчанию для сетевой аутентификации NTLM

В фазе 3 сетевую аутентификацию NTLM планируется отключить по умолчанию в следующем крупном выпуске.⁶ Сказано и то, что её можно снова включить политикой.

Что делать сейчас: разделить зависимости на те, что, возможно, закроют новые функции, и те, что придётся исправлять самому

План следует порядку «убрать причины использовать NTLM, затем изменить значение по умолчанию». Если разложить собственные зависимости так же, ожидание отделяется от того, что нужно исправлять первым.

Важно не сваливать аутентификацию к более старым версиям Windows и сторонним устройствам в одну корзину «ждём фазу 2». Сама по себе она в Kerberos не превратится, а если оставить её без внимания, она проявится как сбой, когда значение по умолчанию переключат.

Конкретная процедура инвентаризации и разделения изложена в практической парной статье.

10. Итоги

В завершение — повторение в порядке решений.

Механизм: ответ на основе хеша или билет для назначения

NTLM строит ответ на вызов из хеша пароля. Проверяет его контроллер домена для доменной учётной записи или собственный SAM сервера для локальной.¹¹⁰

Kerberos использует билет, зашифрованный долговременным ключом целевой службы.³ Понимание различий во взаимной аутентификации, обращении к контроллеру домена при каждой аутентификации и делегировании вскрывает предпосылки для выбора между двумя способами.⁴

Разбор: работает на NTLM или аутентификация остановилась?

Если аутентификация переключилась на NTLM, проверьте четыре условия: жёстко прописанные IP-адреса, незарегистрированные SPN, нахождение вне Active Directory и доступность KDC.⁵⁶¹¹

Проблемы, дающие ошибку аутентификации после того, как Kerberos был выбран, например рассинхронизация времени, — отдельная тема. Вместо того чтобы гоняться только за событием 8001 в NTLM/Operational, изучайте события Kerberos и синхронизацию времени.⁷ Отправная точка расследования — не делать вывода «работает, значит, точно Kerberos» или «остановилось, значит, переключилось на NTLM».

Реакция: проверьте защиту, затем переходите к Negotiate и именам

Ретрансляция, пересылающая обмен NTLM, и Pass-the-Hash, использующий похищенный хеш, различаются и в том, почему они работают, и в том, что им нужно.⁸¹¹³ Проверяйте защитные условия на каждом назначении, одновременно снижая саму зависимость от NTLM.

NTLMv1 удалён в Windows 11 24H2 и Windows Server 2025, а все версии, включая NTLMv2, устарели.⁹ В приложениях используйте Negotiate, приводите назначения к FQDN и регистрируйте SPN.¹⁵ Затем ведите миграцию дальше, отделяя зависимости, которые, возможно, закроют новые функции, от зависимостей, которые придётся исправлять самому.

Похожие статьи

• Остановит ли отказ от NTLM бизнес-приложения? — как снимать журналы аудита и в каком порядке убирать зависимости
• Подводные камни сетевых дисков и UNC-путей — работа с файловым сервером (общими папками) из бизнес-приложения
• Руководство по синхронизации времени Windows (w32time)
• Практический разбор журнала событий через Get-WinEvent — скорость фильтрации определяет время расследования
• Безопасная работа с учётными данными в PowerShell — изгоняем пароли в открытом виде из скриптов
• Что такое TPM в Windows? — наглядное руководство о «сейфе, который не выпускает ключи», и измеряемой загрузке
• 10 главных угроз информационной безопасности 2026 — как читать рейтинг и от чего на самом деле должны защищаться малые и средние компании

Смежные области консультаций

KomuraSoft LLC занимается доработкой бизнес-приложений для Windows, связанной с пересмотром способов аутентификации, и расследованием первопричин проблем аутентификации вокруг Kerberos и NTLM.

• Разработка приложений для Windows
• Расследование дефектов и анализ первопричин
• Использование существующих активов и поддержка миграции
• Контакты

Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

В чём, собственно, разница между NTLM и Kerberos?

Самое большое различие — можно ли убедиться, с кем именно вы говорите. Microsoft прямо указывает, что при NTLM клиент не может проверить подлинность сервера, и один сервер не может проверить подлинность другого. NTLM проектировался для сред, где серверы можно считать подлинными; Kerberos такого допущения не делает. Второе различие — должен ли сервер обращаться к контроллеру домена. При NTLM, когда аутентифицируется доменная учётная запись, сервер приложения подключается к контроллеру домена при каждой аутентификации клиента (если учётная запись локальна для сервера, сервер обращается к своей базе данных учётных записей и решает сам, и контроллер домена вообще не появляется). При Kerberos обновляемые сеансовые билеты заменяют эту сквозную аутентификацию, поэтому сервер не идёт к контроллеру домена, кроме случаев, когда требуется проверка PAC. Третье — Kerberos поддерживает делегирование службами, то есть механизм подключения к другой службе от имени клиента.

Почему аутентификация уходит на NTLM, хотя приложение заявлено как поддерживающее Kerberos?

Kerberos выдаёт билеты, привязанные к «имени назначения», поэтому он не может работать, если имя не разрешается. Клиент предъявляет KDC SPN (имя субъекта-службы) назначения, чтобы запросить билет службы, но по умолчанию Windows не предпринимает аутентификацию Kerberos, когда имя узла — это IP-адрес, а если на учётной записи службы не зарегистрирован SPN, KDC не может выдать билет. Руководство Microsoft по аудиту говорит то же: Kerberos не используется, если «Target Server» в событии 8001 не в форме NetBIOS и не в форме FQDN. (Для IP-адресов можно заставить Kerberos работать как исключение, задав на клиенте TryIPSPN и вручную зарегистрировав SPN для IP-адреса, но это описано как крайняя мера для случаев, когда DNS-имя невозможно.) Другие условия, при которых Kerberos не может работать, — аутентификация на машинах в рабочей группе или с локальными учётными записями (то есть вообще вне Active Directory), площадки, не имеющие доступа к контроллеру домена, и аутентификация к партнёру без отношений доверия. Negotiate выбирает NTLM, когда Kerberos недоступен, — именно это и означает «падение» в таких случаях.

Что такое атака ретрансляции NTLM и почему она работает?

Атакующий заманивает жертву на свой сервер и ретранслирует обмен аутентификации NTLM, пришедший туда, напрямую на настоящий сервер, выдавая себя за жертву. Это работает потому, что в схеме «вызов — ответ» NTLM нет механизма, привязывающего «к кому именно вы аутентифицируетесь». Клиент просто вычисляет ответ по вызову, который выдал сервер, и возвращает его, не имея способа проверить, предназначен этот ответ настоящему серверу или его ретранслирует атакующий. Сама Microsoft в документации по параметру политики указывает, что аутентификация NTLM и NTLMv2 уязвима к множеству вредоносных атак, включая ретрансляцию SMB, атаки «злоумышленник посередине» и атаки перебором. При этом ретрансляция проходит не к любому партнёру. Если назначение требует подписи SMB, подпись подтверждает личности отправителя и получателя, и ретрансляция не проходит; то же верно для служб, применяющих Extended Protection for Authentication (привязку канала). И наоборот, целями становятся партнёры, которые принимают NTLM и не требуют ни подписи, ни привязки канала. При Kerberos билет службы зашифрован долговременным ключом этой службы, поэтому билет, предназначенный одной службе, не может быть расшифрован другой.

Значит ли Pass-the-Hash, что можно выдать себя за пользователя, не взламывая его пароль?

Именно так. Учётные данные NTLM состоят из доменного имени, имени пользователя и одностороннего хеша пароля. В NTLMv2, который использует современный Windows, ключ ответа выводится как ключ HMAC, построенный на MD4-хеше пароля (NT-хеше), и затем этим ключом вычисляется HMAC по набору из серверного вызова, метки времени, клиентского вызова и сведений о целевом объекте. Это не просто шифрование вызова, но отправной точкой всё равно остаётся хеш пароля. Иначе говоря, для аутентификации нужен хеш, а не открытый пароль. Поэтому атакующий, который может извлечь хеш, скажем, из памяти машины, аутентифицируется как этот пользователь, не взламывая пароль. Более длинные и сложные пароли этот путь не закрывают. Одна из названных Microsoft причин предусмотреть блокировку NTLM на стороне SMB-клиента — противодействие атакам Pass-the-Hash.

Если мы используем NTLMv2, разве нам пока ничего не грозит?

NTLMv2 сильнее NTLMv1, но из числа устаревших он не исключён. В списке устаревших функций Microsoft сказано, что все версии NTLM, включая LANMAN, NTLMv1 и NTLMv2, находятся вне активной разработки и устарели. Политики ограничения ведут себя так же: про политики аудита и блокировки сказано, что они оказывают одинаковое действие на обе версии. Иначе обстоит дело с NTLMv1: он прошёл стадию устаревания и дошёл до удаления, и был удалён из Windows 11 версии 24H2 и Windows Server 2025. Поэтому формулировка не «мы на NTLMv2, значит, можно оставить», а «NTLMv1 — это срок прямо сейчас; по NTLMv2 нужна инвентаризация в преддверии отключения по умолчанию».

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.