Остановит ли отказ от NTLM ваши бизнес-приложения? — Как собирать журналы аудита и в каком порядке устранять зависимости

«Говорят, NTLM отменяют. С нами всё будет в порядке?» — чтобы ответить на этот вопрос, первым делом нужно не блокировать NTLM во всей компании, а провести аудит той аутентификации, которая работает прямо сейчас. Все версии NTLM были объявлены устаревшими в июне 2024 года, но одно это объявление не останавливает ни один бизнес-процесс.¹

Отказ от NTLM — это не тот случай, когда однажды приходит обновление и вся компания встаёт; ограничения ужесточаются шаг за шагом с каждой новой версией ОС. Пока NTLM ещё работает, составьте список зависящих от него машин, приложений и адресов назначения, попробуйте изменение на небольшом масштабе и только потом вводите ограничения. Сначала заблокировать всё, а потом искать, что сломалось, — это неправильный порядок.

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

Механика самого протокола (почему NTLM опасен и почему аутентификация «падает» до NTLM вместо Kerberos) вынесена в парную статью «NTLM и Kerberos в рисунках — почему аутентификация «падает» до NTLM».

Дорожная карта отказа и доступность функций указаны по состоянию на июль 2026 года — та же точка отсчёта, что и в японском оригинале. Не путайте её с датой последнего обновления структуры этой статьи. Доступность IAKerb, локального KDC и остального проверяйте по заметкам о выпуске вашей целевой версии в тот момент, когда действительно принимаете решение о миграции.²

Начните с того, что вас беспокоит

Если читаете подряд, начинайте с главы 1; когда приступите к практической работе, вернитесь к аудиту в главе 4.

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

Разграничьте, на какой стадии находится изменение

NTLM был объявлен устаревшим в июне 2024 года. Это касается всех версий, включая LANMAN, NTLMv1 и NTLMv2, и означает, что активная разработка функции прекращена. В том же объявлении сказано, что использование NTLM продолжит работать в следующем выпуске Windows Server и в следующем ежегодном выпуске Windows.¹

Часть уже удалена. NTLMv1 удалён в Windows 11 версии 24H2 и Windows Server 2025.¹

Отказ идёт в три фазы. Фаза 1 — визуализация использования и аудит, фаза 2 (вторая половина 2026 года) — функции, устраняющие ситуации, в которых без NTLM не обойтись (IAKerb и локальный KDC), фаза 3 — отключение сетевой аутентификации NTLM по умолчанию в следующем крупном выпуске.²

Прежде чем что-то блокировать, определите зависимости

Сейчас нужно сделать ровно одну вещь. Включить режим аудита и составить список: «какая машина, какое приложение и к какому серверу» использует NTLM (глава 4).

Для доменных учётных записей расследование начинается с контроллера домена. Если идти по цепочке: событие 8004 → 8003 на рядовом сервере → 8001 на клиенте, — вы доберётесь до имени приложения (раздел 4.2). Учтите, однако, что аутентификация с локальными учётными записями не проходит через контроллер домена, поэтому событие 8004 не появляется. Этот маршрут приходится выявлять по 8003 на сервере и 8001 на клиенте.³

Большинство причин — это имена. Жёстко прописанные IP-адреса и незарегистрированные SPN — две главные из них, и ни одна не требует переписывать приложение (глава 5).³²

Проверяйте на малом масштабе и правьте сторону приложения

Есть безопасный способ проверить всё на одной машине. В Windows 11 24H2 или Windows Server 2025 команда NET USE \\server\share /BLOCKNTLM позволяет выяснить, «подключается ли это без NTLM», не меняя ни одной политики (глава 7).⁴

В собственных приложениях замените места, где явно указан NTLM, на Negotiate. Microsoft прямо пишет: «не обращайтесь к пакету безопасности NTLM напрямую» (глава 8).⁵

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

2. Что на самом деле означает «устарело»

Начните с терминологии. Если объяснять внутри компании, пока формулировки размыты, одновременно разойдутся «говорят, этим больше нельзя пользоваться» и «говорят, у нас ещё годы в запасе», и обсуждение развалится.

Разделите объявление об устаревании и уже состоявшееся удаление

Если кратко, запись о NTLM в списке устаревших функций Microsoft говорит о трёх вещах.¹

1. Все версии NTLM, включая LANMAN, NTLMv1 и NTLMv2, выведены из активной разработки и объявлены устаревшими.
2. Использование NTLM продолжит работать в следующем выпуске Windows Server и в следующем ежегодном выпуске Windows.
3. Вызовы NTLM следует заменить вызовами Negotiate. Negotiate пытается выполнить аутентификацию через Kerberos и откатывается к NTLM только тогда, когда это необходимо.

Далее в обновлении добавлено, что NTLMv1 удалён из Windows 11 версии 24H2 и Windows Server 2025.¹

Итак, текущее состояние — «устарело», а не «удалено». Только NTLMv1 перешёл границу устаревания и уже находится в фазе удаления. Если старый МФУ или NAS умеет аутентифицироваться только по NTLMv1, само обновление до Windows 11 24H2 и есть авария. Это не проблема будущего — это происходит уже сейчас.

Для сценариев без альтернативы проверьте и условия на другой стороне

Ещё одна вещь, которую стоит держать в голове: у NTLM остаются сценарии, для которых альтернативы нет. Microsoft прямо указывает, что NTLM по-прежнему используется и должен использоваться для аутентификации Windows на системах, настроенных как члены рабочей группы, и для локального входа на компьютерах, не являющихся контроллерами домена.⁶ Локальный KDC, запланированный на фазу 2, — как раз та функция, которая призвана закрыть этот разрыв «локальные учётные записи требуют NTLM».²

2.1. Где находятся три фазы

Дорожная карта отказа состоит из трёх фаз. Эта информация зависит от времени, поэтому она приводится с указанием точки отсчёта (таблица ниже отражает ситуацию на июль 2026 года).

Эта таблица должна показать главное: фаза 1 — единственная, которую вы можете двигать своими руками уже сегодня. В таблице решений в главе 6 про некоторые пункты сказано, что «ответом может стать» функция фазы 2, но каждый из них требует проверки доступности. Сроки поставки могут меняться, поэтому всегда перепроверяйте содержимое этой таблицы в момент, когда ваша организация принимает решение.

3. Почему от него отказываются — три минуты

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

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

Взаимной аутентификации нет

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

При доменной аутентификации сервер обращается к контроллеру домена

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

Украденный хеш используют, не зная пароля

Учётные данные NTLM состоят из имени домена, имени пользователя и одностороннего хеша пароля (хешируется только пароль), и клиент шифрует этим хешем запрос-вызов, формируя свой ответ.⁵ Отсюда следует свойство: украденного хеша достаточно, чтобы выдать себя за пользователя, вообще не зная пароля в открытом виде.

Практический смысл отсутствия взаимной аутентификации в том, что одна лишь попытка подключиться к общей папке SMB может отдать ваши учётные данные подделанному серверу. Причина, по которой Microsoft встроила блокировку NTLM в SMB-клиент, описывается так же: чтобы предотвратить приёмы, заставляющие отправлять запросы NTLM вредоносным серверам.⁴

4. Аудит — составление списка мест, где используется NTLM

Это сердце статьи. Сама Microsoft прямо указывает, что до внедрения политик ограничения необходимо обнаружить и провести аудит текущего состояния трафика аутентификации NTLM.⁹

4.1. Включаем режим аудита

Примечание. Режим аудита только записывает события, он ничего не блокирует. С другой стороны, в среде с большим числом машин объём журнала сразу возрастает. Если вы не используете сбор событий (WEF), проверьте ограничение размера журнала и срок хранения до его включения. В руководстве Microsoft также сказано, что анализ может занять несколько месяцев в зависимости от сложности среды.³

Отсчитывайте период аудита с того момента, когда настройки дошли до целевых машин. Чтобы не упустить ежемесячную обработку или маршруты, задействованные во время инцидента, заранее прочитайте также раздел 9.2 о «полном бизнес-цикле».

Где настраивать и три политики

Настроить нужно три политики. Все они находятся в разделе Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности, и перезагрузка не требуется. Сохраняете вы их локально или распространяете групповой политикой — они вступают в силу в момент применения настройки.⁷

Не считайте момент сохранения GPO началом аудита

Однако «перезагрузка не требуется» и «действует на каждой машине немедленно» — разные вещи. Когда вы распространяете доменную GPO, сохранение GPO обновляет политику только в AD и SYSVOL; каждая машина фактически начинает аудит при следующем фоновом обновлении или после выполнения gpupdate /force. Отсчитывайте начало периода аудита от момента, когда настройки дошли до целевых машин, а не от момента сохранения GPO. Если ошибиться, результат искажается вполне определённым образом: только первая агрегация охватывает меньше машин, чем вы думаете.

У третьей политики, “Outgoing NTLM traffic to remote servers”, четыре значения: Allow all (разрешить все), Audit all (аудит всех), Deny all (запретить все) и Not Defined (не задано), причём Not Defined обрабатывается так же, как Allow all. Рекомендация Microsoft столь же однозначна: не переходите сразу к “Deny all”; сначала установите “Audit all”, просмотрите операционный журнал, поймите, какие серверы получают запросы аутентификации, и только затем составляйте список исключений.⁷

Смотрите NTLM/Operational, а не журнал безопасности

События записываются в Просмотр событий > Журналы приложений и служб > Microsoft > Windows > NTLM (Microsoft-Windows-NTLM/Operational). Для этого аудита нет соответствующей политики аудита событий безопасности, поэтому смотрите именно этот канал, а не журнал безопасности.⁷

Соотнесите роли машин с записываемыми событиями

Самая простая вещь, которую легче всего перепутать на практике, — это соответствие «какая политика на какой машине и какое событие смотреть». Обозначим три политики из таблицы выше как (1), (2) и (3) — вот контрольный список.

Журнал на всех машинах один и тот же — Microsoft-Windows-NTLM/Operational. Политика (1) действует только на контроллерах домена, а машина, на которой забыли про (2) и (3), — это не «машина, которая не использует NTLM», а «машина, которая не записывает события». Это различие — самый крупный источник искажённых агрегатов.

4.2. Идём по цепочке «вниз от контроллера домена»

Начните с разделения учётных записей, используемых для аутентификации. Для доменных учётных записей идите по цепочке вниз от контроллера домена; для локальных — от сервера и клиента.³

Учтите также, что бывают случаи, когда на контроллере домена событие 8004 не появляется: когда локальная учётная запись пользователя подключается к файловому серверу, эта аутентификация не проходит через контроллер домена.³ Не делайте вывод «в журналах контроллера домена мало событий, значит у нас всё в порядке».

Доменные учётные записи прослеживаются как 8004 → 8003 → 8001

Путь трассировки для доменных учётных записей, приведённый в руководстве Microsoft, выглядит так.³

flowchart TD
    DC["Контроллер домена<br/>Событие 8004"]
    MS["Рядовой сервер<br/>Событие 8003"]
    CL["Клиент<br/>Событие 8001"]
    APP["Виновное приложение"]

    DC -->|"Secure Channel Name =<br/>сервер для проверки"| MS
    MS -->|"Workstation Name =<br/>клиент для проверки"| CL
    CL -->|"Client Process Name"| APP
    MS -.->|"PID 4 (SYSTEM) означает,<br/>что пришло через SMB"| CL

Рисунок 1: Порядок трассировки событий аудита NTLM

Поля, на которые нужно смотреть в каждом событии, таковы.³

В конце смотрят на назначение и имя процесса

Особую ценность этому пути придают «Target Server» и «Client Process Name» в событии 8001. Первое прямо говорит, почему аутентификация не стала Kerberos, второе прямо указывает, кто виноват. Руководство Microsoft описывает то же самое: по этой информации можно определить, что пользователь подключается к IP-адресу веб-сервера, а не к имени NetBIOS или FQDN, которые позволили бы использовать Kerberos.³

4.3. Агрегация с помощью PowerShell

Шаг 1. Считаем, какие Event ID записаны на машине

Разглядывать тысячи записей в графическом интерфейсе «Просмотра событий» нереалистично, поэтому сводим их с помощью Get-WinEvent. Сначала проверьте, какие события появляются на машине и сколько их каждого типа.

# Агрегируем события NTLM/Operational по ID (запуск от имени администратора)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

Шаг 2. Открываем одно событие 8001 и проверяем фактические имена полей

Убедившись, что события появляются, сгруппируйте клиентские события 8001 по принципу «сервер назначения × вызывающий процесс». Набор полей события различается для разных Event ID, поэтому безопасный подход — сначала открыть одно событие через Format-List и посмотреть его структуру, а уже потом решать, по каким именам полей агрегировать.

# Сначала смотрим одно событие
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# Чтобы увидеть структурированные поля
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

Шаг 3. Агрегируем по «назначение × вызывающий процесс»

Когда структура понятна, извлекайте значения по атрибуту Name из XML и агрегируйте. Имена атрибутов различаются между версиями ОС, поэтому поиск по имени ломается реже, чем обращение по позиционным индексам.

# Агрегируем события 8001 за последние 7 дней по «назначение x вызывающий процесс»
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # Берём только те имена полей, которые реально существуют, в порядке приоритета
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Шаг 4. Смотрим на назначение и ответственное приложение, а не на количество

Итоговая агрегация возвращает два столбца: Count и Name (назначение и вызывающий процесс, соединённые запятой). То есть вывод выглядит так (значения приведены для примера).

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

Смотреть нужно на первую половину Name, то есть на назначение. Вот как читать каждую строку.

Абсолютное количество само по себе мало что значит. Смотрите на две вещи: стоят ли вверху строки, адресованные IP-адресам, и сколько строк доведено до имени исполняемого файла. Первые — это зависимости, которые после исправления точно перестанут быть проблемой; вторым можно назначить ответственного.

Если в агрегате пусто или сплошь PID, вернитесь к именам полей

Поскольку имена полей различаются между версиями ОС, в коде перечислены кандидаты в массиве с заданным порядком приоритета, и берутся только те, что реально существуют. Если применить здесь частичное совпадение вроде -match 'Process', под него попадут и поля PID, например ClientProcessId, и вы начнёте агрегировать по PID, который меняется каждый раз, вместо имени исполняемого файла (порядок ключей в хеш-таблице не определён, поэтому стабильности в том, что попадётся, тоже нет). Если столбец Process пуст во всех строках, это признак того, что имена кандидатов не совпадают с фактической схемой, поэтому добавьте в массив имя, проверенное на предыдущем шаге.

Прежде чем масштабировать, добейтесь одинакового чтения на одной машине

Если вы собираете данные с нескольких машин, быстрый способ — запустить их параллельно через PowerShell Remoting («Введение в PowerShell Remoting (WinRM) — управление несколькими машинами Windows сразу»). От того, используете вы -FilterHashtable или нет, время фильтрации в Get-WinEvent различается на порядок; суть этого собрана в статье «Практическое исследование журналов событий с Get-WinEvent — скорость фильтрации определяет время расследования».

4.4. Взгляд со стороны журнала безопасности — используется ли ещё NTLMv1?

Помимо NTLM/Operational, есть ещё способ проверить версию NTLM по событиям входа в журнале безопасности. Процедура такая: найдите в журнале безопасности «Authentication Package» и посмотрите «Detailed Authentication Information» в каждом событии.³

Detailed Authentication Information:
    Logon Process:              NtLmSsp
    Authentication Package:     NTLM
    Transited Services:         -
    Package Name (NTLM only):   NTLM V1
    Key Length:                 128

Записи NTLM V1 выделите в отдельный, более высокий приоритет

Это поле «Package Name (NTLM only)» показывает, какой подпротокол семейства NTLM использовался.³ Узел, где зафиксировано NTLM V1, становится кандидатом на отказ аутентификации в тот самый момент, когда его обновят до Windows 11 24H2 или Windows Server 2025, потому что NTLMv1 в этих версиях удалён.¹ Когда проводите аудит, поднимите приоритет именно этого аспекта.

4.5. Когда везде PID 4 (SYSTEM) и дальше не продвинуться

Начнёте аудит — и почти наверняка упрётесь в эту стену. В приложениях, которые общаются через редиректор, например через SMB (общие папки), запрос на аутентификацию исходит от редиректора в режиме ядра, поэтому в событии всегда остаётся PID 4 (SYSTEM).³

Сузьте круг до одной машины по журналам, а затем идите по ней одной через ProcMon

Рекомендуемый в руководстве Microsoft порядок действий таков.³

1. Установите средство мониторинга процессов на клиенте, который отправляет учётные данные NTLM («Computer» в событии 8001).
2. Фильтруйте пути одновременно по имени компьютера сервера-партнёра и по его IP-адресу. Если нужно записывать долго, запустите в фоновом режиме.
3. Сопоставьте запись с отметками времени события 8003 на стороне сервера. Пользователь, путь и идентификатор аутентификации совпадут, и по ним можно определить вызывающее приложение.

Инструмент — Process Monitor (ProcMon). Как задавать фильтры и читать вывод, собрано в статье «Практическое руководство по Process Monitor (ProcMon) — как за 10 минут найти «настройки не применяются» и «ACCESS DENIED»».

Добавим один практический совет: сузить круг «какая это машина» только по журналам событий до этого момента, а затем настроить ProcMon лишь на этой одной машине — заметно быстрее. Разворачивать ProcMon на каждой машине нереалистично.

5. Типичные случаи, которые откатываются к NTLM

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

• Приложения, в которых можно выбирать различные конфигурации безопасности и поставщиков
• Приложения, у которых SPN (имя участника службы) настроен неправильно
• Приложения, которые из-за ошибки в настройке или из-за документации поставщика используют IP-адрес вместо DNS-имени
• Приложения с унаследованной кодовой базой, в которой остались части, работающие только по NTLM

В блоге поддержки Microsoft Japan типичными причинами использования NTLM названы доступ к серверу, заданный по IP-адресу, ограничения брандмауэра на порты, необходимые Kerberos, незарегистрированные SPN, аутентификация в доверенном партнёрском домене и аутентификация в среде рабочей группы.²

Фиксируйте причину и приоритет исправления в одной таблице

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

NTLMv1 — вперёд, а долгие согласования начинайте параллельно

Порядок работ механически следует из этих двух столбцов.

1. Независимо от масштаба последствий высший приоритет — оборудование, которое умеет только NTLMv1, и узлы, где зафиксировано NTLM V1 (раздел 4.4). Этот пункт стоит вне расчёта приоритетов, потому что его срок уже наступил.¹
2. Далее идут большой масштаб последствий и высокая простота исправления, то есть жёстко прописанные IP-адреса. Событий много, и исправить их можно собственным решением. Сосредоточьтесь на них в первый месяц.
3. После этого — пункты со средней простотой исправления, связанные с SPN. Разбирайтесь с ними вместе с унификацией имён.
4. Пункты с низкой простотой исправления (зависимые от устройства, сетевой маршрут, ожидание фазы 2) не поздно начинать; у них просто долгий срок реализации, поэтому запросы поставщикам и заявки на бюджет начинайте параллельно с пунктами 1–3.

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

6. Таблица решений по способам устранения

Выбирайте способ устранения в соответствии с классом, присвоенным в главе 5. Сначала выполните переход на FQDN и проверку SPN, а TryIPSPN оставьте как последнее средство на случай, когда имя использовать нельзя. В том, куда регистрируются SPN для IIS, есть исключение, поэтому перед началом прочитайте раздел 8.3 об «учётной записи, которая расшифровывает билет».

7. Блокировка NTLM для SMB — кратчайший путь к проверке на практике

Журналы аудита говорят, что что-то используется, но не говорят, что произойдёт, если это остановить. Здесь и помогает блокировка NTLM на стороне SMB-клиента, добавленная в Windows Server 2025 и Windows 11 версии 24H2.⁴

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

Примечание. Это функция SMB-клиента.⁴ NTLM на маршрутах, отличных от SMB (HTTP-трафик собственных приложений, подключения к SQL Server, WinRM и так далее), она не останавливает. Их придётся устранять по отдельности, согласно классификации из главы 5.

Есть два предварительных условия.⁴

• SMB-клиент — Windows Server 2025 или более поздней версии либо Windows 11 версии 24H2 или более поздней
• SMB-сервер назначения умеет использовать Kerberos (ОС на стороне SMB-сервера может быть любой, поддерживающей PKU2U или Kerberos)

7.1. Сначала проверьте на одной машине и одном соединении

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

# Пробуем подключиться с запретом NTLM только для этого соединения (если подключается, эта общая папка не нуждается в NTLM)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# То же самое можно сделать через подключение в PowerShell
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

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

Проверяйте результат в три этапа, как показано ниже. Не делайте вывод о зависимости от NTLM только по формулировке сообщения об ошибке.

Четыре шага, чтобы не получить ложный вывод

Однако эта проверка требует процедуры. Если выполнять её бездумно, ложные выводы получатся в обе стороны.

$server = 'fileserver.corp.example.com'

# 1. Удаляем все без исключения подключения к этому серверу
#    Если останется хотя бы одна другая общая папка, сеанс с сервером сохранится
net use | Select-String $server              # Сначала смотрим, что подключено
net use \\$server\share  /delete
net use \\$server\other  /delete             # И все остальные общие папки на том же сервере

# 2. Убеждаемся, что сеанс действительно исчез (пока здесь не пусто, дальше не идём)
Get-SmbConnection -ServerName $server

# 3. Сначала убеждаемся, что подключение проходит без флага (неудача здесь — не проблема NTLM)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # Здесь тоже снова пусто

# 4. И только после этого пробуем с /BLOCKNTLM
net use \\$server\share /BLOCKNTLM

Шаги 1 и 2. Разрываем сеанс с сервером, а не только с общей папкой

SMB-сеансы привязаны к серверу, а не к общей папке. Если аутентифицированный сеанс с этим сервером сохраняется, редиректор переиспользует его вместо повторной аутентификации. /BLOCKNTLM влияет только на аутентификацию, выполняемую для этого подключения; он не проверяет задним числом сеанс, который уже установлен (и, возможно, был установлен по NTLM).

Иными словами, удалить только проверяемую общую папку через /delete недостаточно. Если другая общая папка на том же сервере всё ещё подключена, проверка пройдёт успешно, хотя зависимость от NTLM существует. Разрывайте подключения, пока Get-SmbConnection не вернёт ничего. Кроме ваших собственных подключений сеанс могут удерживать постоянно работающие приложения и задания резервного копирования. Самый надёжный и быстрый подход — проверять с машины, которая никогда не подключалась к этому серверу.

Шаг 3. Успех без флага используйте как базу для сравнения

Запуск с /BLOCKNTLM может не пройти и из-за ошибки разрешения имён, неверных учётных данных или недостаточных прав на саму общую папку. Если без флага тоже не проходит, это не зависимость от NTLM, а другая проблема.

Успех ещё не означает, что способ аутентификации установлен

Учтите, что здесь можно утверждать лишь «NTLM не потребовался», а не «аутентификация прошла по Kerberos». Предварительное условие этой функции — «SMB-сервер, умеющий использовать Kerberos», но на стороне назначения допускается ОС, поддерживающая PKU2U.⁴ Значит, остаётся вероятность, что причиной успеха был PKU2U, а не Kerberos. Если вторая сторона — файловый сервер, введённый в домен, это вряд ли имеет значение, но когда нужно точно установить, что именно аутентифицировалось, после подключения выполните klist на клиенте и посмотрите, получен ли билет cifs/ для этого сервера, либо проверьте пакет аутентификации в событии входа в журнале безопасности на стороне сервера (раздел 4.4).

7.2. Включаем на отдельной машине

Когда перепроверка завершена, переходите к блокировке на уровне всей машины на пилотных компьютерах.⁴

# Блокируем NTLM для всего SMB-клиента (запуск от имени администратора)
Set-SmbClientConfiguration -BlockNTLM $true

Через групповую политику включите «Block NTLM (LM, NTLM, NTLMv2)» в разделе Конфигурация компьютера > Административные шаблоны > Сеть > Рабочая станция Lanman.⁴

7.3. Неизменяемых партнёров вносим в список исключений

Партнёров, которым NTLM действительно нужен, например SMB-серверы, не введённые в домен, можно сделать исключениями. Включите в групповой политике Lanman Workstation > Block NTLM Server Exception List и перечислите IP-адреса, имена NetBIOS и FQDN, которые нужно разрешить.⁴

Разделяйте постоянные исключения и аварийное редактирование реестра

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

# Добавляем записи в существующий список исключений
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

Примечание. В примере, опубликованном в документации Microsoft, ветка «значения ещё нет» устанавливает только @(""), поэтому записи, которые вы хотели добавить, отбрасываются.⁴ Поведение таково, что первый запуск не добавляет исключений вовсе и только второй их добавляет, поэтому приведённый выше код записывает записи как есть и в случае, когда значение ещё не создано. Тем не менее это значение реестра относится к области, которой управляет групповая политика. Постоянные исключения ведите на стороне групповой политики, а эту операцию оставьте для аварийного, временного применения. Следующее применение политики её перезапишет.

8. NTLM глазами разработчика — используем Negotiate

Если вы разрабатываете приложения для Windows своими силами, что исправлять — понятно. Microsoft прямо говорит следующее.⁵

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

Короче говоря, правило такое: заменить места, где написано «NTLM», на «Negotiate». В списке устаревших функций сказано то же самое: вызовы NTLM следует заменить вызовами Negotiate.¹

8.1. Частая ситуация в .NET — явное указание NTLM

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

// Плохо: NTLM указан как тип аутентификации
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// Хорошо: меняется только тип аутентификации. Учётные данные передаются как и раньше
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

Здесь меняется только строка типа аутентификации. Если заменить credential на CredentialCache.DefaultNetworkCredentials, изменится не только протокол аутентификации, но и субъект, под которым выполняется аутентификация. Тогда аутентификация пойдёт от учётной записи, под которой запущен процесс (учётной записи службы или вошедшего пользователя), а не от указанной вами, и в зависимости от прав на стороне назначения может перестать работать. Замену протокола и пересмотр учётных данных держите как отдельные изменения.

Переход на аутентификацию от текущего пользователя — отдельное решение

Если же вам изначально нужно аутентифицироваться с учётными данными вошедшего пользователя (встроенная проверка подлинности Windows), это записывается заметно проще. Так пишут, когда сознательно меняют «от чьего имени выполняется аутентификация».

// Встроенная проверка подлинности Windows (аутентификация от имени текущего вошедшего пользователя)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

Обращение с самим HttpClient (не оборачивать в using, шаблоны создания, проектирование тайм-аутов) разобрано в статье «Не оборачивайте HttpClient в using — практическая работа с HTTP в бизнес-приложениях на C# (шаблоны создания, тайм-ауты, повторы)».

При прямой работе с SSPI там тоже указывайте Negotiate

Если приходится работать с SSPI напрямую, класс System.Net.Security.NegotiateAuthentication, добавленный в .NET 7, позволяет выполнять аутентификацию через Negotiate из управляемого кода. Ключевой момент здесь тот же: не указывать NTLM как имя пакета.

8.2. То, как записан адрес назначения, важнее кода

Даже если исправить код, если адрес назначения остался IP-адресом, всё равно получится NTLM. По умолчанию, когда имя узла — это IP-адрес, Windows не пытается выполнить аутентификацию Kerberos для этого узла и откатывается к другому допустимому протоколу, например NTLM.¹⁰ Конкретно проверьте следующее.

• Имена серверов, записанные в файлах конфигурации (appsettings.json, App.config, ini-файлы)
• Указание сервера в строках подключения SQL Server (Data Source)
• Места, где собираются UNC-пути. Проверьте на жёстко прописанные IP-адреса
• Значения по умолчанию в установщиках и в процедурах настройки ПК
• Места, которые во время прошлого инцидента переписали на IP «потому что разрешение имён работало нестабильно» и так и не вернули обратно

Последний пункт действительно встречается. Жёстко прописанный IP-адрес был правильной временной мерой в тот момент, но сегодня это технический долг.

8.3. Если вы делаете сторону службы

Если вы хотите, чтобы ваша служба Windows или приложение IIS принимали Kerberos, нужно зарегистрировать SPN — по имени, которое клиенты используют для доступа, — на учётной записи, которая расшифровывает билет. Как указывает сама Microsoft, приложение без зарегистрированного SPN — классический пример того, что откатывается к NTLM, даже заявляя поддержку Kerberos.³

В IIS удостоверение пула приложений и удостоверение, расшифровывающее билет, не обязательно совпадают

Если считать, что SPN регистрируется просто «на учётной записи, под которой работает служба», вы споткнётесь именно на IIS. В проверке подлинности Windows в IIS по умолчанию включена аутентификация в режиме ядра, и в этом случае билет Kerberos расшифровывает не удостоверение пула приложений, а учётная запись компьютера, которую использует HTTP.sys. Если запустить пул приложений под выделенной доменной учётной записью и зарегистрировать HTTP SPN сайта на этой учётной записи, владелец SPN и учётная запись, которая фактически расшифровывает билет, разойдутся, и вместо отката к NTLM сама аутентификация не пройдёт с ошибкой KRB_AP_ERR_MODIFIED.

Смысл в том, чтобы привести цель регистрации SPN и удостоверение, расшифровывающее билет, к одному. Работоспособных вариантов два.

Что выбрать, зависит от того, используется ли одна и та же учётная запись службы на нескольких серверах (если да, приводить к удостоверению пула проще в управлении). Учтите, что SPN можно зарегистрировать только на одной учётной записи, поэтому при переключении не забудьте удалить старую регистрацию. Дублирующиеся регистрации ломают саму аутентификацию Kerberos.

Делегирование другим серверам проверяйте вместе со сменой протокола

Если в вашем проекте клиент олицетворяется для доступа к другому серверу (делегирование), NTLM и Kerberos обрабатывают это по-разному. Kerberos поддерживает механизм делегирования, при котором служба подключается к другим службам от имени клиента, тогда как NTLM предоставляет лишь информацию авторизации, необходимую для локального олицетворения.⁸ Реализация олицетворения разобрана в статье «Как правильно обращаться с маркерами олицетворения Windows — заимствование прав на поток и безопасный возврат».

9. Дорожная карта поэтапного ужесточения

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

9.1. Остановить SMB — это лишь половина работы с NTLM

Этапы с 4 по 6 касаются только SMB. Как сказано в главе 7, блокировка NTLM на стороне SMB-клиента — это функция SMB-клиента,⁴ и на любые другие маршруты она не влияет. Всё, что вы в этапе 2 классифицировали как «аутентификация по HTTP», «SQL Server использует NTLM» или «WinRM использует NTLM», остаётся нетронутым, когда вы заканчиваете этап 6. А поскольку это не попадает и в список исключений SMB, подсчёт этого списка ничего не выявит.

Для всего, кроме SMB: аудит, исключения, запрет — через Restrict NTLM

Именно этап 6b закрывает этот пробел. Он использует ровно те три политики, которые вы перевели в режим аудита в главе 4. Процедура имеет ту же форму.¹¹

1. Оставьте “Outgoing NTLM traffic to remote servers” в значении Audit all и перечислите оставшиеся назначения
2. Внесите действительно нужных партнёров в «Add remote server exceptions»
3. Переведите пилотные машины в Deny all и дождитесь, пока бизнес пройдёт полный цикл
4. Если проблем нет, разворачивайте

И для всего домена: перед запретом подтвердите влияние соответствующим аудитом

Для домена в целом проведите “NTLM authentication in this domain” через тот же порядок: аудит, исключения («Add server exceptions in this domain»), затем запрет.¹² Microsoft также говорит, что перед выбором варианта запрета следует установить соответствующую политику аудита в то же значение и оценить влияние.¹²

«Мы заблокировали SMB, значит работа с NTLM завершена» — неправда. Если нужна метрика завершённости, считайте и список исключений SMB, и список исключений серверов Restrict NTLM.

9.2. Период аудита задавайте «полным бизнес-циклом», а не днями

Легче всего ошибиться в этапе 1 при определении периода. Если объявить его завершённым потому, что «мы собирали две недели», всё, что не запускалось за эти две недели, в список не попадёт. А то, чего нет в списке, сломается впервые уже после того, как вы разошлёте блокировку в этапе 6.

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

Конкретно, чаще всего упускают следующее.

• Ежемесячная и квартальная обработка закрытия периода. Классический пример — пакетная обработка на конец месяца, которая подключается к общей папке или базе данных по жёстко прописанному IP-адресу.
• Ежегодная обработка. Инвентаризация, переход на новый финансовый год, всё, что связано с закрытием финансового периода.
• Маршруты, задействуемые только во время инцидента. Процедуры восстановления из резервной копии, переключение на резервный сервер, учения по восстановлению после аварии.
• Машины, которые подолгу выключены. Ноутбуки, вывозимые за пределы офиса, машины сотрудников в длительном отпуске, запасные машины, которые обычно выключены.
• Бизнес-приложения, которые используются лишь несколько раз в год.

Если ждать нельзя, запустите низкочастотную обработку намеренно

Само руководство Microsoft говорит, что анализ может растянуться на несколько месяцев в зависимости от сложности развёртывания.³ Реалистично провести границу одним из двух способов.

1. Держите аудит включённым, пока бизнес не пройдёт полный цикл. Как минимум одно закрытие месяца, а лучше — в пределах квартала.
2. Проведите инвентаризацию низкочастотной обработки и запустите её намеренно. Если выдержать период невозможно, выполните обработку закрытия и процедуры восстановления после аварии в тестовой среде и добавьте эти результаты в список. Ключевое — заранее перечислить, опросив ответственных, ту обработку, которая «не дала событий только потому, что ни разу не запускалась».

В любом случае переходите к следующему этапу только тогда, когда сможете различать «событие не появилось» и «это ещё не запускалось».

9.3. Не переводите сразу в запрет

Ключевое здесь — не включать “Outgoing NTLM traffic = Deny all” одним движением. Microsoft также говорит, что установка этой политики в запрет может привести к отказу множества запросов аутентификации NTLM и снизить производительность, поэтому перед её внедрением следует просмотреть журнал в режиме “Audit all”, проанализировать серверы и составить список исключений для тех, которые нужно исключить.⁷ Такое же предупреждение написано для политики “NTLM authentication in this domain”, охватывающей весь домен.¹²

10. Итоги

• Все версии NTLM были объявлены устаревшими в июне 2024 года. Это не изменение, которое что-то немедленно останавливает; указано, что NTLM продолжит работать в следующем выпуске Windows Server и в следующем ежегодном выпуске Windows.¹
• С другой стороны, NTLMv1 уже удалён (Windows 11 24H2 и Windows Server 2025). Оборудование, которое умеет только NTLMv1, и узлы, где зафиксировано NTLM V1, — ближайший срок.¹
• Отказ состоит из трёх фаз: фаза 1 — аудит, фаза 2 (вторая половина 2026 года) — IAKerb и локальный KDC, фаза 3 — отключение по умолчанию.²
• Аудит означает перевод трёх политик в режим аудита и сбор журнала Microsoft-Windows-NTLM/Operational. Для доменных учётных записей идите 8004 на контроллере домена, 8003 на рядовом сервере, затем 8001 на клиенте — и в конце дойдёте до имени приложения. Аутентификация с локальными учётными записями не даёт события 8004, поэтому выявляйте её по событиям сервера и клиента.³⁷
• Трафик через SMB всегда показывает PID 4 (SYSTEM). Сузьте круг до машины по журналам событий, затем идите по этой одной машине через ProcMon.³
• Большинство причин — это имена. Если разобрать только жёстко прописанные IP-адреса и незарегистрированные SPN, оставшихся исключений станет заметно меньше.³²
• NET USE \\server\share /BLOCKNTLM — самый безопасный способ перепроверить по одному соединению, не меняя политику.⁴
• В собственных приложениях замените явное указание NTLM на Negotiate и приведите запись адресов назначения к FQDN.⁵
• Список исключений — это отсрочка, а не решение. Метрикой должно быть то, уменьшается ли их количество с каждым годом.

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

• NTLM и Kerberos в рисунках — почему аутентификация «падает» до NTLM
• Подводные камни сетевых дисков и UNC-путей — практическая работа с файловым сервером (общими папками) из бизнес-приложения
• Практическое исследование журналов событий с Get-WinEvent — скорость фильтрации определяет время расследования
• Практическое руководство по Process Monitor (ProcMon) — как за 10 минут найти «настройки не применяются» и «ACCESS DENIED»
• Введение в PowerShell Remoting (WinRM) — управление несколькими машинами Windows сразу
• Безопасная работа с учётными данными в PowerShell — изгоняем пароли в открытом виде из сценариев
• Встраивание аутентификации Entra ID в приложения WinForms/WPF — практическая архитектура с MSAL.NET и брокером WAM
• Что такое TPM в Windows? — иллюстрированное руководство про «сейф, который не выпускает ключи наружу» и измеряемую загрузку

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

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

• Разработка приложений для Windows
• Исследование ошибок и анализ первопричин
• Повторное использование и перенос существующих активов
• Связаться с нами

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

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

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

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

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

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

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

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

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

Когда NTLM отменят, с какого момента бизнес встанет?

Само объявление об устаревании (deprecated) ничего не останавливает. Microsoft объявила устаревшими все версии NTLM в июне 2024 года, но в сопроводительных указаниях было сказано, что использование NTLM продолжит работать в следующем выпуске Windows Server и в следующем ежегодном выпуске Windows. Конкретное изменение, которое уже что-то сломало, — удаление NTLMv1 в Windows 11 версии 24H2 и Windows Server 2025. Опубликован план отключить сетевой NTLM по умолчанию в одном из будущих выпусков, но и тогда указано, что его можно снова включить политикой. Иными словами, это не тот случай, когда однажды встаёт вся компания; ограничения немного ужесточаются с каждой новой версией ОС. Именно поэтому единственная реалистичная подготовка — провести инвентаризацию зависимостей по журналам аудита, пока NTLM ещё работает, а не разбираться после того, как что-то сломалось.

Как составить список мест, где используется NTLM?

Переведите настройки семейства «Network security: Restrict NTLM» групповой политики в режим аудита и собирайте журнал NTLM/Operational. Задайте на контроллерах домена «Audit NTLM authentication in this domain», а на серверах и клиентах — «Audit Incoming NTLM Traffic» и «Outgoing NTLM traffic to remote servers = Audit all», и события будут записываться в «Просмотр событий» > «Журналы приложений и служб» > Microsoft > Windows > NTLM. При аутентификации с доменными учётными записями порядок такой: по событию 8004 на контроллере домена определите пользователя и сервер назначения (Secure Channel Name), затем посмотрите идентификатор процесса в событии 8003 на этом сервере и, наконец, по событию 8001 на клиенте установите, «какое приложение и по какому имени сервера» обратилось. В событии 8001 есть имя целевого сервера и имя клиентского процесса, так что, дойдя до этого места, вы узнаете виновное приложение. Учтите, что аутентификация с локальными учётными записями не проходит через контроллер домена, поэтому событие 8004 не появляется. Маршруты, где машина рабочей группы или локальная учётная запись на файловом сервере подключается к общей папке, приходится выявлять по 8003 на сервере и 8001 на клиенте. Не смотрите только журналы контроллера домена и не делайте вывод «у нас такого мало».

Включил аудит, а в событиях везде PID 4 (SYSTEM). Не могу понять, какое это приложение.

Это потому, что трафик идёт через SMB (общие папки). Аутентификацию SMB выполняет редиректор в режиме ядра, поэтому вызывающее приложение скрыто за пакетами SMB, и в событии всегда остаётся PID 4 (SYSTEM). Руководство Microsoft прямо описывает этот случай и рекомендует запустить Process Monitor (ProcMon) на клиенте, где появляются события, отфильтровать пути по имени компьютера и IP-адресу сервера-партнёра и сопоставить с отметками времени события 8003 на стороне сервера, чтобы определить вызывающий процесс. На практике быстрый путь — сначала сузить круг «какая это машина» по журналам событий, а затем искать только на этой машине через ProcMon.

Почему приложение, которое вроде бы поддерживает Kerberos, откатывается к NTLM?

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

Что исправлять в приложениях для Windows, которые мы разрабатываем сами?

Замените Negotiate везде, где NTLM указан как пакет аутентификации. Microsoft прямо указывает, что приложения не должны обращаться к пакету безопасности NTLM напрямую и должны использовать пакет Negotiate. Negotiate выбирает Kerberos или NTLM и выбирает Kerberos, если только его не может использовать одна из систем, участвующих в аутентификации. В .NET типичное исправление — изменить тип аутентификации, передаваемый в CredentialCache.Add, с "NTLM" на "Negotiate" (тип аутентификации указывается в CredentialCache.Add, а не в конструкторе NetworkCredential). Наряду с этим нужно задавать адреса назначения по FQDN, а не по IP-адресу или псевдониму, прописанному в hosts, и, если вы хотите, чтобы ваша служба принимала Kerberos, зарегистрировать SPN на учётной записи этой службы.

Об авторе

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

Го Комура

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

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