NTLM (NT LAN Manager) – это довольно старый протокол аутентификации Microsoft, который появился еще в Windows NT. Несмотря на то, что еще в Windows 2000 Майкрософт внедрила более безопасный протокол аутентификации Kerberos, NTLM (в основном это NTLMv2) широко используется для аутентификации в Windows сетях до сих пор. В этом статье мы рассмотрим особенности процесс отключения протокола NTLMv1 и NTLMv2, и перехода на Kerberos в домене Active Directory.
Основные проблема NTLMv1 – слабое шифрование, хранение хэша пароля в оперативной памяти в службе LSA, который может извлечь различными утилитами (типа mimikatz) и использовать хэш для дальнейших атак, отсутствие взаимной проверки подлинности клиента и сервера, что делает вполне реальными атаки перехвата данных и неавторизованного доступа к ресурсам сети (утилиты типа Responder могут перехватывать данные NTLM, передаваемые по сети и использовать их для доступа к сетевым ресурсам) и ряд других уязвимостей.
Часть этих недостатков исправлена в более новой версии NTLMv2, который использует более криптостойкие алгоритмы шифрования и позволяет предотвратить популярные атаки на NTLM. Начиная с Windows 7 / Windows Server 2008 R2 использование NTLMv1 и LM для авторизации по умолчанию выключено.
Переключаемся на использование NTLMv2
Если вы задумались полностью отказаться от NTLM в своем домене, сначала нужно убедиться, что у вас не используется его более уязвимая версия- NTLMv1. Вероятно в вашей сети имеется ряд устаревших устройств или служб, которые все еще используют аутентификацию NTLMv1 вместо NTLMv2 (или Kerberos). Поэтому прежде, чем прибегнуть к его полному отключению прочитайте раздел этой статьи по аудиту событий авторизации с помощью NTLM.
В первую очередь администратору домена нужно убедиться, что в его сети запрещено использовать NTLM или LM для авторизации, т.к. в некоторых случаях атакующий может с помощью специальных запросов получить ответ на NTLM/LM запрос.
Тип аутентификации можно задать с помощью доменной (или локальной) политики. Откройте консоль управления доменными политиками и отредактируйте Default Domain 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\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel и значением от 0 до 5. Значение 5 соответствует значению политики «Отправлять только NTLMv2-ответ. Отказывать LM и NTLM».

Не забудьте применить эту политику для контроллеров домена.
Если вы убедились, что у вас не используется NTLMv1, вы можете пойти дальше и попытаться отказаться от NTLMv2. NTLMv2 хотя и более защищенный протокол аутентификации, но все равно существенно проигрывает Kerberos в плане безопасности (хотя уязвимостей в NTLMv2 намного меньше, чем в первой версии протокола, все-таки существуют возможности перехвата и повторного использования данных, и отсутствует взаимная аутентификации).
Главная риск отключения NTLM – возможное использование в домене устаревших или некорректно настроенных приложений, которые все еще могут использовать проверку подлинности NTLM, и для перехода на Kerberos их придется обновлять или настраивать особым образом.
Аудит событий NTLM аутентификации в домене
Перед полным отключением NTLM в домене и переходе на Kerberos желательно убедиться, что в домене не осталось приложений, которые требуют и используют NTLM авторизацию.
Для отслеживания учетных записей и приложение, которые используют NTLM аутентификацию, вы можете включить политики аудита на всех компьютерах с помощью GPO. В разделе Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options найдите и включите политику Network Security: Restrict NTLM: Audit NTLM authentication in this domain, установив ее значение на Enable all.
Аналогичным образом включите политику Network Security: Restrict NTLM: Audit Incoming NTLM Traffic, установив ее значение на Enable auditing for domain accounts.
После включения данных политик события использования NTLM аутентификации записываться в журнал событий Event Viewer в секцию Application and Services Logs-> Microsoft -> Windows -> NTLM.
Можно проанализировать события на каждом сервере, или собрать все события в центральный Event Log.
Вам нужно собрать события от Microsoft-Windows-Security-Auditing c Event ID 4624 – An Account was successfully logged on. Обратите внимание на информацию в секции “Detailed Authentication Information”. Если в строке Authentication Package указано NTLM, значит для аутентификации этого пользователя использовался протокол NTLM.
Теперь обратите внимание на значение Package Name (NTLM only). Здесь должно быть указано какой протокол (LM, NTLMv1 или NTLMv2) использовался для аутентификации. Таким образом вам нужно идентифицировать все сервера/приложения, которые используют устаревший протокол.
Например, для поиска всех событий аутентификации по NTLMv1 по всем контроллерам домена можно использовать такой PowerShell скрипт:
$ADDCs = Get-ADDomainController -filter * -Server 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 "*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 авторизация в браузерах). Из личного опыта: даже действительно большие коммерческие продукты иногда еще не перешли с использования NTLM на Kerberos, некоторые продукты требуют обновления или изменений конфигурации. Все сводится к определению того, какие приложения используют проверку подлинности NTLM, и теперь у вас есть способ для выяснения этого софта и устройств.
Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов, для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки *.
Полное отключение NTLM в домене 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 для всех серверов и учетных записей.
Для дальнейшего эшелонирования защиты в AD рекомендую познакомиться со статьями «Защита от извлечения пароля из памяти утилитами а-ля mimikatz», «Защита учетных записей администраторов», отключение LLMNR и NetBIOS over TCP/IP.
Спасибо большое за статью! Как всегда по делу, доходчиво и без лишней воды.
Вставлю свои пять копеек. Если я всё правильно помню, то Kerberos аутентификация не возможна с машин не членов домена. Это например значит, что прощай удалённая работа по RDP. Том числе и удалённая работа сисадмина.
В теории можно решить вопрос через Always On VPN (DirectAccess ) или за счет утилиты ksetup из resource kit (_https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/ksetup, _https://www.garyhawkins.me.uk/non-domain-mit-kerberos-logins-on-windows-10/)
С VPN не понял. Вы предлагаете ввести удалённые машины в домен (поддерживая связь через VPN)? Ну это так себе вариант конечно. Очень ограниченное применение может иметь.
Про ksetup не знал, спасибо. Но это тоже костыли. Если сисадмин дома себе это еще развернуть может, то вот что делать с обычными удалённым работниками не понятно. Если VPN+RDP (а кто-то довольствуется и вовсе RDP через проброс портов) настраивать на домашних машинах еще можно, то ставить им туда какие-то тулзы это уже другое. Я уже молчу про всякие мобильные платформы, Mac OS и тд.
Это всё не ради того что бы поспорить. Это для того, что бы читающие эту статью заранее оценили последствия, дабы не получить неприятных сюрпризов.
Например я, в своё время, взвесив все плюсы и минусы остановился на варианте «Send NTLMv2 response only. Refuse LM& NTLM».
В принципе да, опция «Send NTLMv2 response only. Refuse LM& NTLM» должна использоваться как минимум для домена. Я и сам пока остановился на нем. Слишком много унаследованных систем.
По поводу DirectAcсess VPN — компьютер в этой технологии находится в домене (есть способы даже ofline domain join для DirectAcess). PS. Я с DirectAcсess знаком в теории, на практике не использовал, поэтому некоторых нюансов могу не знать.
Либо другой вариант — добавить VPN сервер в исключения политики, как это описано в статье. Также придется развернуть терминальный сервер (можно и совместить с VPN/Radisu) с разрешенным ntlmv2, с которого вы можете ходить внутрь сети.
Здравствуйте!
Имхо у Вас последний скриншот не оттуда.
Параметр :Network Security: Restrict NTLM: NTLM authentication in this domain.
Скриншот: Network Security: Restrict NTLM: Audit NTLM authentication in this domain
Да, верно. Скриншот не оттуда 🙂
в скрипте не совсем корректный поиск через «*V1*», ищет много лишнего, включая например, имена ПК, содержащие «V1». если уж искать через тело сообщения, то лучше «*NTLM V1*».
Здравствуйте! Я так полагаю эту политику нужно применять на контролер домена? Или можно использовать на клиентскую машину и посмотреть как она будет себя вести?
Эту настройки можно включать на уровне Default Domain Policy. Но если вы тестируете на предмет работы прикладухи без NTLM, начинайте с отдельной GPO для тестовых декстопов, потом серверов, и только после этого переходите к DC
И как я могу проверить что использую протокол Kerberos
Если вы отключили NTLM, самый простой вариант — попробовать зайти на любой сервер или DC по IP:
\\192.168.1.100. При отключенном NTLM, вы не сможете зайти на такую шару (Kerberos использует только FQDN имена, или нужна SPN запись для IP адреса ). А по полному имени доступ должен работать \\server1.domain.com
Большое спасибо)