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_x000D_Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

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

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

$ADDCs = Get-ADDomainController -filter * -Server dc01.remontka.com
$Now = Get-Date
$Yesterday = $Now.AddDays(-1)
$NewOutputFile = "c:psEvents$($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_MACHINESYSTEMCurrentControlSetControlLsa нужно создать параметр 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 с этим сервером._x000D_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._x000D_NTLM is a weaker authentication mechanism. Please check:_x000D_Which applications are using NTLM authentication?_x000D_Are there configuration issues preventing the use of stronger authentication such as Kerberos authentication?_x000D_If NTLM must be supported, is Extended Protection configured?_x000D_

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

klist sessions

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

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

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