Блокировка NTLM и миграция на Kerberos в Windows 11 и Server 2025

Microsoft последовательно отказывается от протокола NTLM. В Windows 11 24H2 и Windows Server 2025 появились встроенные инструменты блокировки NTLM-аутентификации для SMB-подключений. NTLMv1 уже официально deprecated, а NTLMv2 движется к тому же статусу. Как спросил читатель Сергей в комментариях к статье на WinITPro: «Как теперь предлагается подключаться по RDP удалённым сотрудникам?» — и это ключевой практический вопрос. В этом руководстве разберём полный цикл: аудит текущего использования NTLM, пошаговую блокировку и миграцию на Kerberos с решением проблем совместимости.

Почему NTLM нужно отключать

NTLM (NT LAN Manager) — протокол аутентификации, разработанный в 1990-х годах. Его уязвимости хорошо изучены:

• Pass-the-Hash — перехваченный NTLM-хеш можно использовать для аутентификации без знания пароля
• NTLM Relay — перенаправление аутентификационных запросов на другой сервер
• Brute Force — NTLMv1 хеши ломаются за секунды на современном GPU
• Отсутствие взаимной аутентификации — в отличие от Kerberos, клиент не проверяет подлинность сервера
• Нет поддержки MFA — NTLM не поддерживает многофакторную аутентификацию

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

Этап 1: Аудит использования NTLM

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

Включение NTLM-аудита через GPO

Откройте Group Policy Management Console и создайте новую политику:

Computer Configuration → Policies → Windows Settings → Security Settings
→ Local Policies → Security Options

# Включить аудит NTLM в домене
Network Security: Restrict NTLM: Audit NTLM authentication in this domain
  → Enable all

# Аудит входящего NTLM-трафика
Network Security: Restrict NTLM: Audit Incoming NTLM Traffic
  → Enable auditing for all accounts

# Расширенное логирование NTLM
Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers
  → Audit all

Сбор событий NTLM

После включения аудита собирайте данные минимум 2-4 недели. Ищите события:

# PowerShell — поиск NTLM-событий на контроллере домена
# Event ID 8004 — NTLM-аутентификация в домене
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
  Where-Object {$_.Id -eq 8004} |
  Select-Object TimeCreated,
    @{N='User';E={$_.Properties[0].Value}},
    @{N='Domain';E={$_.Properties[2].Value}},
    @{N='Workstation';E={$_.Properties[1].Value}},
    @{N='Server';E={$_.Properties[3].Value}} |
  Export-Csv "C:\Logs\ntlm-audit.csv" -NoTypeInformation -Encoding UTF8

# Статистика по серверам, использующим NTLM
Import-Csv "C:\Logs\ntlm-audit.csv" |
  Group-Object Server |
  Sort-Object Count -Descending |
  Select-Object Count, Name |
  Format-Table -AutoSize

Типичные источники NTLM-трафика

• Обращения по IP-адресу вместо FQDN (Kerberos требует имя хоста)
• Старые принтеры и МФУ со встроенным SMBv1
• Legacy-приложения (1С старых версий, самописное ПО)
• NAS-устройства без поддержки Kerberos
• Скрипты и задачи, использующие IP вместо hostname
• Удалённые пользователи без VPN (без доступа к контроллеру домена)

Этап 2: Блокировка NTLMv1

Начните с блокировки устаревшего NTLMv1, оставив NTLMv2 для переходного периода.

GPO-политика для отключения NTLMv1

Computer Configuration → Windows Settings → Security Settings
→ Local Policies → Security Options

Network security: LAN Manager authentication level
  → Send NTLMv2 response only. Refuse LM & NTLM

Эта политика указывает Windows отправлять только NTLMv2 ответы и отклонять LM и NTLMv1. Это безопасный первый шаг — подавляющее большинство систем уже используют NTLMv2.

Проверка через PowerShell

# Текущий уровень LM-аутентификации
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel" |
  Select-Object LmCompatibilityLevel

# Значения:
# 0 = Send LM & NTLM responses
# 1 = Send LM & NTLM — use NTLMv2 if negotiated
# 2 = Send NTLM response only
# 3 = Send NTLMv2 response only
# 4 = Send NTLMv2 response only. Refuse LM
# 5 = Send NTLMv2 response only. Refuse LM & NTLM  ← цель

Этап 3: Блокировка NTLM для SMB

Windows 11 24H2 и Server 2025 добавили встроенную поддержку блокировки NTLM на уровне SMB-клиента.

PowerShell-команды для SMB-клиента

# Глобальная блокировка NTLM для SMB
Set-SmbClientConfiguration -BlockNTLM $true

# Проверка статуса
Get-SmbClientConfiguration | Select-Object BlockNTLM

# Блокировка NTLM для конкретного сетевого ресурса
New-SmbMapping -RemotePath \\fileserver\share -BlockNTLM $true

# Или через NET USE
NET USE \\fileserver\share /BLOCKNTLM

# Список исключений (серверы, которым разрешён NTLM)
Set-SmbClientConfiguration -BlockNTLMServerExceptionList "192.168.15.21,oldprinter.contoso.com,*.legacy.local"

# Проверка исключений
Get-SmbClientConfiguration | Select-Object BlockNTLMServerExceptionList

GPO-политики для SMB

Computer Configuration → Administrative Templates → Network → Lanman Workstation

# Включить блокировку NTLM
Block NTLM (LM, NTLM, NTLMv2) = Enabled

# Список исключений
Block NTLM Server Exception List = "oldnas.company.local,192.168.1.100"

Computer Configuration → Administrative Templates → Network → Lanman Server

# Ограничитель частоты аутентификации (защита от brute force)
Enable authentication rate limiter = Enabled

Этап 4: Настройка Kerberos для замены NTLM

Обращение по FQDN вместо IP

Kerberos работает только с именами хостов, не с IP. Это самый частый источник «отката на NTLM»:

# НЕПРАВИЛЬНО — вызовет NTLM
\\192.168.1.10\share
NET USE Z: \\192.168.1.10\share

# ПРАВИЛЬНО — использует Kerberos
\\fileserver.company.local\share
NET USE Z: \\fileserver.company.local\share

Проверьте все скрипты, задания планировщика и ярлыки на использование IP — замените на FQDN.

SPN (Service Principal Names)

Для корректной работы Kerberos у каждого сервиса должен быть зарегистрирован SPN:

# Проверка SPN для сервера
setspn -L fileserver

# Проверка SPN для учётной записи
setspn -L company\svc_sql

# Поиск дубликатов SPN (частая проблема!)
setspn -X

# Регистрация SPN для SQL Server
setspn -S MSSQLSvc/sqlserver.company.local:1433 company\svc_sql
setspn -S MSSQLSvc/sqlserver.company.local company\svc_sql

KDC Proxy для удалённых пользователей

Ответ на вопрос Сергея из комментариев: «как подключаться по RDP удалённым сотрудникам?» — через KDC Proxy.

KDC Proxy позволяет получать Kerberos-тикеты через HTTPS, не требуя прямого доступа к контроллеру домена:

# Настройка KDC Proxy на сервере (Windows Server 2025)
# 1. Установите роль Web Application Proxy или используйте IIS

# 2. Настройте реестр на клиенте
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" `
  -Name "KdcProxyServer" -Value "https://kdcproxy.company.com/KdcProxy" -PropertyType String

# 3. Или через GPO
# Computer Configuration → Administrative Templates → System → Kerberos
# Specify KDC proxy servers for Kerberos clients
# Value: company.local = https://kdcproxy.company.com/KdcProxy

Этап 5: Полная блокировка NTLM в домене

После того как аудит показал нулевой или минимальный NTLM-трафик, можно включить полную блокировку:

GPO для полной блокировки

Computer Configuration → Windows Settings → Security Settings
→ Local Policies → Security Options

# Блокировка NTLM-аутентификации в домене
Network Security: Restrict NTLM: NTLM authentication in this domain
  → Deny all

# Исключения (если необходимо)
Network Security: Restrict NTLM: Add server exceptions in this domain
  → oldserver.company.local,legacyapp.company.local

Мониторинг после блокировки

# Скрипт мониторинга отклонённых NTLM-запросов
$events = Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 100 |
  Where-Object {$_.Id -eq 8004 -or $_.Id -eq 4004}

if ($events.Count -gt 0) {
    $report = $events | Select-Object TimeCreated, Id, Message |
      ConvertTo-Html -Title "NTLM Blocked Events"
    Send-MailMessage -To "admin@company.ru" `
      -From "monitoring@company.ru" `
      -Subject "NTLM Events Detected: $($events.Count)" `
      -Body ($report | Out-String) `
      -SmtpServer "mail.company.ru" `
      -BodyAsHtml
}

# Добавьте в Task Scheduler — каждый час

Решение типичных проблем

Проблема: RDP перестал работать

# Ошибка: An authentication error has occurred.
# Причина: клиент не может получить Kerberos-тикет

# Решение 1: Проверить DNS
nslookup rdpserver.company.local
# Должен разрешаться корректно

# Решение 2: Проверить Kerberos-тикеты
klist
# Если тикетов нет — klist purge и войти заново

# Решение 3: Для удалённых — настроить KDC Proxy (см. выше)

# Решение 4: Временно — исключение для RDP-сервера
Set-SmbClientConfiguration -BlockNTLMServerExceptionList "rdpserver.company.local"

Проблема: Старый принтер / NAS не работает

# Добавить в исключения
Set-SmbClientConfiguration -BlockNTLMServerExceptionList "192.168.1.200,oldprinter.company.local"

# Долгосрочное решение: замена оборудования или настройка print server
# с Kerberos-аутентификацией как промежуточного звена

Проблема: Legacy-приложение требует NTLM

# Временное решение: исключение для конкретного сервера
# GPO → Network Security: Restrict NTLM: Add server exceptions

# Долгосрочное решение:
# 1. Обновить приложение до версии с поддержкой Kerberos
# 2. Настроить SPN для учётной записи сервиса
# 3. Использовать Kerberos Constrained Delegation

Дорожная карта миграции

Рекомендуемый план на 3-6 месяцев:

1. Неделя 1-2: Включить аудит NTLM во всём домене
2. Неделя 3-6: Собрать статистику, составить список NTLM-зависимых систем
3. Неделя 7-8: Заменить IP на FQDN в скриптах, задачах, ярлыках
4. Неделя 9-10: Отключить NTLMv1 (оставить NTLMv2)
5. Неделя 11-12: Включить блокировку NTLM для SMB с исключениями
6. Неделя 13-16: Настроить KDC Proxy для удалённых пользователей
7. Неделя 17-20: Тестирование полной блокировки NTLM в тестовом OU
8. Неделя 21-24: Развёртывание на весь домен, мониторинг

Часто задаваемые вопросы (FAQ)