Отключить NTLM аутентификацию в домене Windows

NTLM (NT LAN Manager) – это старый протокол аутентификации Microsoft, который появился еще в Windows NT. Несмотря на то, что еще в Windows 2000 Майкрософт внедрила более безопасный протокол аутентификации Kerberos, NTLM (в основном это NTLMv2) широко используется для аутентификации в Windows сетях до сих пор. В этом статье мы рассмотрим, как отключить протоколы NTLMv1 и NTLMv2, и переключиться на Kerberos в домене Active Directory.

Основные проблемы NTLMv1 – слабое шифрование, хранение хэша пароля в оперативной памяти в службе LSA (можно извлечь пароли из памяти Windows в открытом виде с помощью утилит типа mimikatz и использовать хэш для дальнейших атак с помощью сценариев Pass-The-Hash), отсутствие взаимной проверки подлинности клиента и сервера, что делает вполне реальными атаки перехвата данных и неавторизованного доступа к ресурсам сети (утилиты типа Responder могут перехватывать данные NTLM, передаваемые по сети и использовать их для доступа к сетевым ресурсам) и ряд других уязвимостей.

Часть этих недостатков исправлена в более новой версии NTLMv2, который использует более криптостойкие алгоритмы шифрования и позволяет предотвратить популярные атаки на NTLM. Начиная с Windows 7 / Windows Server 2008 R2 протоколы аутентфикации NTLMv1 и LM по умолчанию отключены.

Аудит событий NTLM аутентификации в домене

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

Для отслеживания учетных записей и приложение, которые используют NTLM аутентификацию, вы можете включить политики аудита на всех компьютерах с помощью GPO. Откройте Default Domain Controller Policy, перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options найдите и включите политику Network Security: Restrict NTLM: Audit NTLM authentication in this domain, установив ее значение на Enable all.

Аналогичным образом включите следующие политики в Default Domain Policy:

• Network Security: Restrict NTLM: Audit Incoming NTLM Traffic – задайте значение Enable auditing for domain accounts
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers: задайте Audit all

После включения данных политик события использования NTLM аутентификации записываться в журнал событий Event Viewer в секцию Application and Services Logs-> Microsoft -> Windows -> NTLM -> Operation.

Можно проанализировать события на каждом сервере, или собрать все события в центральный Event Log.

Вам нужно собрать события от Microsoft-Windows-Security-Auditing c Event ID 4624 – An Account was successfully logged on. Обратите внимание на информацию в секции “Detailed Authentication Information”. Если в строке Authentication Package указано NTLM, значит для аутентификации этого пользователя использовался протокол NTLM.

Также, если для аутентификации используется NTLM вместо Kerberos, в журнале появится событие Event ID 4776:

The computer attempted to validate the credentials for an account
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Теперь обратите внимание на значение Package Name (NTLM only). Здесь должно быть указано какой протокол (LM, NTLMv1 или NTLMv2) использовался для аутентификации. Таким образом вам нужно идентифицировать все сервера/приложения, которые используют устаревший протокол.

Например, для поиска всех событий аутентификации по NTLMv1 по всем контроллерам домена можно использовать такой PowerShell скрипт:

$ADDCs = Get-ADDomainController -filter * -Server dc01.winitpro.ru
$Now = Get-Date
$Yesterday = $Now.AddDays(-1)
$NewOutputFile = "c:\ps\Events\$($Yesterday.ToString('yyyyMMdd'))_AD_NTLMv1_events.log"
function GetEvents($DC){
Write-Host "Searching log on " $DC.HostName
$Events = Get-EventLog "Security" -After $Yesterday.Date -Before $Now.Date -ComputerName $DC.HostName -Message "*NTLM V1*" -instanceid 4624
foreach($Event in $Events){
Write-Host $DC.HostName $Event.EventID $Event.TimeGenerated
Out-File -FilePath $NewOutputFile -InputObject "$($Event.EventID), $($Event.MachineName), $($Event.TimeGenerated), $($Event.ReplacementStrings),($Event.message)" -Append
}
}
foreach($DC in $ADDCs){GetEvents($DC)}


После того, как вы идентифицировали пользователей и приложения, использующие NTLM в вашем домене, попробуйте перевести их на использование Kerberos (возможно с использованием SPN). Некоторые приложения достаточно донастроить для использования Kerberos (см. статьи Kerberos авторизация в IIS, использование Kerberos авторизация в браузерах, использования keytab файла Kerberos для аутентификации в AD). Из личного опыта: некоторые действительно большие коммерческие продукты до сих пор используют проверку подлинности NTLM и не поддерживают Kerberos, некоторые продукты требуют обновления или изменений конфигурации.

Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов (NetBIOS имена, IP адреса или FQDN), для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки * .

Переключаемся на использование аутентфикации NTLMv2

Прежде чем полностью отказаться от NTLM в домене AD, сначала рекомендуется отключить его более уязвимая версия NTLMv1. Администратору домена нужно убедиться, что в его сети запрещено использовать NTLM или LM для авторизации, т.к. в некоторых случаях атакующий может с помощью специальных запросов получить ответ на NTLM/LM запрос.

Тип аутентификации можно задать с помощью доменной политики. Откройте консоль управления доменными политиками GPMC.msc и отредактируйте Default Domain Controllers Policy. Перейдите в раздел Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options и найдите политику Network Security: LAN Manager authentication level (Сетевая безопасность: уровень проверки подлинности LAN Manager).

В настройках политики есть 6 опций:

• Send LM & NTLM responses;
• Send LM & NTLM responses – use NTLMv2 session security if negotiated;
• Send NTLM response only;
• Send NTLMv2 response only;
• Send NTLMv2 response only. Refuse LM;
• Send NTLMv2 response only. Refuse LM& NTLM.

Политики использования NTLM аутентификации расположены в порядке возрастания их безопасности. По умолчанию в Windows 7 и выше используется настройка Send NTLMv2 response only (Отправлять только NTLMv2-ответ). При этой настройке клиентские компьютеры используют NTLMv2 аутентификацию, но контролеры домены принимают LM, NTLM, и NTLMv2 запросы.

Вы можете изменить значение политики на более безопасную 6 опцию — “Send NTLMv2 response only. Refuse LM & NTLM”. При этой политике контролеры домена также будут отвергать запросы LM и NTLM.

Также вы можете отключить NTLMv1 через реестр. Для этого в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel и значением от 0 до 5. Значение 5 соответствует значению политики «Отправлять только NTLMv2-ответ. Отказывать LM и NTLM».

В этом же разделе GPO убедитесь, что у вас включена политика Network security: Do mot store Lan Manager hash value on next password change (Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля). Эта политика включена по умолчанию, начиная с Windows Vista / Windows Server 2008 и запрещает создание LM-хэша.

Если вы убедились, что ваш домен и службы корректно работают без NTLMv1, вы можете пойти дальше и попытаться отказаться от NTLMv2. NTLMv2 хотя и более защищенный протокол аутентификации, но все равно существенно проигрывает Kerberos в плане безопасности (хотя уязвимостей в NTLMv2 намного меньше, чем в первой версии протокола, все-таки существуют возможности перехвата и повторного использования данных, и отсутствует взаимная mutual аутентификации).

Главная риск отключения NTLM – возможное использование в домене устаревших или некорректно настроенных приложений, которые все еще могут использовать проверку подлинности NTLM, и для перехода на Kerberos их придется обновлять или настраивать особым образом.

Полное отключение NTLM и перевод аутентфикации на Kerberos в домене Active Directory

Чтобы проверить, как будет работать аутентификация в различных приложениях в домене без использования NTLM, вы можете добавить учетные записи необходимых пользователей в доменную группу Protected Users (группа доступна, начиная с Windows Server 2012 R2), членам которой можно аутентифицироваться только по протоколу Kerberos (нельзя использовать NTLM, Digest Authentication или CredSSP). Так вы можете проверить корректность Kerberos аутентификации пользователя в различных приложениях.

Теперь вы можете полностью отключить NTLM в домене с помощью групповой политики Network Security: Restrict NTLM: NTLM authentication in this domain.

В этой политике доступно 5 опций:

• Disable: политика отключена (NTLM аутентификация в домене разрешена);
• Deny for domain accounts to domain servers: контролеры домена запрещают попытки аутентификации NTLM для всех серверов под доменными аккаунтами, возвращается ошибка «NTLM заблокирован»;
• Deny for domain accounts: контролеры домена запрещают попытки NTLM аутентификации для всех учетных записей домена, возвращается ошибка «NTLM заблокирован»;
• Deny for domain servers: запрещены запросы NTLM аутентификации для всех серверов;
• Deny all: контроллеры домена блокируют все запросы NTLM для всех серверов и учетных записей.

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

Также с помощью отдельных параметров Default Domain Policy вы можете запретить входящий и исходящий NTLM трафик на компьютерах домена:

• Network security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny all

После включения аудита, при использовании NTLM для аутентификации в Event Viewer также будет появляться событие EventID 6038 от LsaSRV с предупреждением:

Microsoft Windows Server обнаружил, что в настоящее время между клиентами и этим сервером используется проверка подлинности ntlm. это событие возникает один раз при каждой загрузке, когда клиент первый раз использует ntlm с этим сервером.
Microsoft Windows Server has detected that NTLM authentication is presently being used between clients and this server. This event occurs once per boot of the server on the first time a client uses NTLM with this server.
NTLM is a weaker authentication mechanism. Please check:
Which applications are using NTLM authentication?
Are there configuration issues preventing the use of stronger authentication such as Kerberos authentication?
If NTLM must be supported, is Extended Protection configured?

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

klist sessions

Данная команда показывает, что для аутентификации всех пользователей используется Kerberos (кроме встроенного локального пользователя Administrator, для которого всегда используется NTLM).

Для дальнейшего эшелонирования защиты в AD рекомендую познакомиться со статьями:

• Защита от извлечения пароля из памяти утилитами а-ля mimikatz
• Защита учетных записей администраторов
• Отключение LLMNR и NetBIOS over TCP/IP