NTLM (NT LAN Manager) – это старый протокол аутентификации Microsoft, который появился еще в Windows NT. Несмотря на то, что еще в Windows 2000 Майкрософт внедрила более безопасный протокол аутентификации Kerberos, NTLM (в основном это NTLMv2) широко используется для аутентификации в Windows сетях до сих пор. В этом статье мы рассмотрим, как отключить протоколы NTLMv1 и NTLMv2, и переключиться на Kerberos в домене Active Directory.
Содержание:
- Аудит событий NTLM аутентификации в домене
- Переключаемся на использование аутентфикации NTLMv2
- Полное отключение NTLM и перевод аутентфикации на 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, некоторые продукты требуют обновления или изменений конфигурации.
Потенциально проблемы при отключении NTLMv1 могут быть у небольших опенсорсных продуктов, различных старых моделей сетевых сканеров (который складывают сканы в сетевые папки), некоторых NAS устройств и другого устаревшего оборудования, ПО и ОС.
Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов (NetBIOS имена, IP адреса или FQDN), для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки
*
.
Для использования Kerberos аутентификации в приложении нужно указывать DNS имя сервера, а не IP адрес. Если вы указываете IP адрес при подключении к ресурсу, используется 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 запросы.
NTLMv2 может использоваться, если не сработал протокол Kerberos и при некоторых операциях (например, при управлении локальными учетными записями и группами на доменных компьютерах), или в рабочих группах.
Вы можете изменить значение политики на более безопасную 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 их придется обновлять или настраивать особым образом.
Если у вас в сети развернут сервер Remote Desktop Gateway, нужно внести дополнительную настройку, которая будет блокировать подключение клиентов с помощью NTLMv1. Создайте в реестре параметр:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core
Type: REG_DWORD
Name: EnforceChannelBinding
Value: 1 (Decimal)
Полное отключение 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).
Если после отключения NTLM вы столкнетесь с частыми событиями блокировки учетных записей пользователей, внимательно изучите события с EventID 4771 (
Kerberos pre-authentication failed
). Смотрите Failure Code в описании ошибки. Там будет указана причина и источник блокировки.
Для дальнейшего эшелонирования защиты в AD рекомендую познакомиться со статьями:
- Защита от извлечения пароля из памяти утилитами а-ля mimikatz
- Защита учетных записей администраторов
- Отключение LLMNR и NetBIOS over TCP/IP
In this post, we are going to discuss on “How to disable NTLM Authentication Windows 10”. You will be guided with easy steps to do so. Let’s starts the discussion.
NTLM Authentication in Windows 10: NTLM stands for New Technology LAN Manager. It is package for security protocols offered by Microsoft to authenticate users’ identity and protect the integrity and confidentiality of their activity. This technology relies on Challenge-response protocol to confirm the user without them to submit a password.
NTLM Authenticates users using a challenge-response mechanism. These process consists of three messages including Negotiation message from the client, Challenge message from the server and Authentication message from the client. However, due to known vulnerabilities, NTLM remains widely deployed even on new systems in order to maintain the compatibility with legacy clients and servers.
NLTM is still support by Microsoft, it has been replaced by ‘Kerberos’ as the default authentication protocol in Windows 2000 and subsequent Active Directory (AD) domains. If you are not aware, ‘Kerberos’ is authentication protocol replaced NTLM as the default/standard authentication tools on Windows version 2000 and later. The main difference between ‘Kerberos’ protocol and ‘NTLM’ protocol is whether passwords are hashed or encrypted. NTLM relies on ‘Password hashing’ – one-way function that produces a string of text on an input file while ‘Kerberos’ relies on encryption – two way functions that scrambles and unlocks information using encryption & decryption keys.
Also, NTLM relies on three-way handshake between client and server to authenticate user while Kerberos relies on two-way process that provides a ticket grating service or key distribution center. NTLM protocol was subject to several security risks and known security bugs or issues related to password hashing and salting.
NLTM protocol stores password on the server and domain controller are not ‘salted’. It means you can’t add any random string of characters to the hashed password to further prevent it from cracking techniques. This vulnerability could allow attackers or cybercriminals attempts to crack password through multiple login attempts, and due to weak or common password, they could successful in accessing the account.
Problem with NTLM protocol:
- Stored password Hash in memory of LSA service can easily be extracted using different tools like mimikatz, and then the hash password may be used for further attacks
- Weak or common passwords are another reason for NTLM protocol problem
- The absence of mutual authentication between server and client that results in data interception attacks and unauthorised access to the network resources.
- Other NTLM vulnerabilities or issues.
How to disable NTLM Authentication Windows 10 using Group Policy Management Editor?
First of all, the domain administrator requires to make sure that NTLM and LM protocols are not allowed to be used for authentication in domain. You can set the preferred authentication type using domain (or local) policy.
Step 1: Press ‘Windows + R’ keys on keyboard, type ‘gpmc.msc’ in the opened ‘Run’ dialog box and hit ‘Ok’ button to open ‘Group Policy Management Editor’
Step 2: Go to ‘Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options’
Step 3: Find ‘Network Security: LAN Manager authentication level’ policy, and double-click on it
Step 4: Select ‘Send NTLMv2 response only. Refuse LM & NTLM’ option under ‘Send LM & NTLM responses’ section/dropdown to reject all LM and NTLM requests.
How to disable NTLM Authentication Windows 10 using Registry Editor?
Step 1: Press ‘Windows + R’ keys on keyboard, type ‘regedit’ in the opened ‘Run’ dialog box and hit ‘Ok’ button to open ‘Registry Editor’
Step 2: Navigate to following path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Step 3: Now, right-click on empty space in right pane and select ‘New > DWORD’ and name it to ‘lmCompatibilityLevel’, set its value to ‘0 to 5’ and hit ‘Ok’ button to save
Step 4: Here, option 5 As value data correspond to ‘Send NTLM response only, refuse LM and NTLM’. Apply the changes.
How to enable NTLM Authentication Audit Logging?
You should make sure there are no apps left in the domain that require and use NTLM, before disabling NTLM completely in domain and switching to ‘Kerbeors’ protocol.
Step 1: Open ‘Group Policy Management Editor’ using above methods, and go to ‘Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options’ path
Step 2: Find and enable ‘Network Security: Restrict NTLM: Audit NTLM Authentication in this domain’ policy, and set its value to ‘Enable All’
Step 3: Repeat the same step to enable ‘Network Security: Restrict NTLM: Audit Incoming NTLM Traffic’ policy
How to check events of using NTLM Authentication?
You can see the NTLM Authentication appear in the application and services logs.
Step 1: Go to ‘Services Logs’ and go to ‘Microsoft > Windows’
Step 2: Take NTLM section of Event Viewer. Now, you can analyze the events on each server or collect them to central Windows Event Log Collector.
Step 3: Find out the applications that are using NTLM in domain, and you need to switch them to use ‘Kerberos’ possibly using SPN.
How to restrict NTLM in Active Directory Domain completely?
The authentication without NTLM will work differently for each applications in our domain, we can add user accounts to ‘protected users’ Doman group. Once verified, you can completely disable NTLM Authentication in your Windows domain.
Conclusion
I am sure this article helped you on How to disable NTLM Authentication Windows 10 with several easy steps/methods. You can read & follow our instructions to do so. If the article really helped you, then you can share the post with others to help them. That’s all. For any suggestions or queries, please write on comment box below.
In this tutorial, we will provide you with instructions on “How to disable NTLM Authentication in Windows 10“. You will be guided through simple steps to accomplish this task. Let’s get started.
What is the purpose of ‘NTLM Authentication’ in Windows 10?
NTLM1 Authentication in Windows 10: NTLM is a New Technology LAN Manager. It is a special package for security protocols provided by Microsoft to authenticate customers’ identity and safeguard the integrity and confidentiality of their actions. This technology is based on a Challenge-response protocol to confirm the customer without the need to provide a password.
NTLM authenticates customers through a challenge-response method. This process involves three messages: the Negotiation message from the customer, the Challenge message from the server, and the Authentication message from the user. Despite its known vulnerabilities, NTLM is still widely deployed, even on new systems, to ensure compatibility with legacy customers and servers.
NLTM is, nevertheless, supported by Microsoft, however, it has been substituted by ‘Kerberos’2 as the main authentication protocol in Windows 2000 and all further Active Directory (AD) domains. In case you haven’t heard about it, ‘Kerberos’ is authentication protocol that substituted NTLM as the main/common authentication utilities on Windows version 2000 and all further versions. The common difference between ‘Kerberos’ protocol and ‘NTLM’ protocol is whether passwords are hashed or encrypted. NTLM is grounded on ‘Password hashing’ – one-way feature that generates a string of text on an input file, however, ‘Kerberos’ rests on encryption – two way feature that scrambles and unlocks data by means of encryption & decryption keys.
Issues with NTLM protocol:
- Kept password Hash in memory of LSA service can be easily obtained by means of various utilities like mimikatz, and then the hash password may be applied for subsequent attacks.
- Weak or trivial passwords are another factor for NTLM protocol issues.
- The lack of mutual authentication between server and customer that leads to the data interception attacks and unauthorized access to the network data.
- Other NTLM leaks or troubles.
Furthermore, NTLM is grounded on three-way handshake between customer and server in order to authenticate customer while Kerberos rests on two-way procedure that is delivered by means of a ticket generating service or key distribution facility. NTLM protocol was exposed before certain security risks and known security leaks or problems related to password hashing and salting.
NLTM protocol, instead, makes sure that passwords on the server and domain controllers are not ‘salted’. It implies that you can’t add any random string of characters to the hashed password in order to eventually prevent it from cracking attempts. Such vulnerability could let attackers or online frauds crack password via multiple login attempts, and because of weak or trivial password, they could eventually manage to access the account.
Guide to deactivate NTLM Authentication Windows 10 by means of the Group Policy Management Editor.
In the first place, the domain administrator would like to be sure that NTLM and LM protocols are not permitted to be applied for authentication in domain. You can define the requested authentication method by means of the domain (or local) policy.
- Apply the ‘Windows + R’ hotkey on keyboard, specify ‘gpmc.msc’ in the opened ‘Run’ dialog box and click on the ‘Ok’ button to launch ‘Group Policy Management Editor’.
- Proceed to ‘Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options’.
- Locate ‘Network Security: LAN Manager authentication level’ policy, then double-click on it.
- Choose ‘Send NTLMv2 response only. Refuse LM & NTLM’ feature under ‘Send LM & NTLM responses’ area/dropdown to deny all LM and NTLM requests.
Guide to deactivate NTLM Authentication Windows 10 by means of the Registry Editor.
- Apply the ‘Windows + R’ hotkey on keyboard, specify ‘regedit’ in the revealed ‘Run’ dialog box and click on the ‘Ok’ button to launch ‘Registry Editor’ 3.
- Proceed to below-given destination
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
- At this point, right-click on empty area in right section and choose ‘New > DWORD’ and nominate it to ‘lmCompatibilityLevel’, define its parameter to ‘0 to 5’ and press ‘Ok’ to save your choice.
- At this point, option 5 As value data corresponds to ‘Send NTLM response only, refuse LM and NTLM’. Save all the amendments.
Pay attention to this guide: How do I remove Advanced Windows Manager?
Guide to activate NTLM Authentication Audit Logging.
You need to be convinced there are no programs left in the domain that demand application of the NTLM, before deactivating NTLM fully in domain and getting to ‘Kerbeors’ protocol.
- Start ‘Group Policy Management Editor’ by following the above-said recommendations, then proceed to ‘Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options’ path.
- Locate and activate ‘Network Security: Restrict NTLM: Audit NTLM Authentication in this domain’ policy, and define its value to ‘Enable All’.
- Repeat the same process to activate ‘Network Security: Restrict NTLM: Audit Incoming NTLM Traffic’ policy.
Guide to examine events of applying NTLM Authentication.
You can find the NTLM Authentication come up in the application and services logs.
- Proceed to ‘Services Logs’ and refer to ‘Microsoft > Windows’.
- Take NTLM area of Event Viewer. At this point, you may analyze the events on each server or bring them to central Windows Event Log Collector.
- Locate the apps that are using NTLM in domain, and you have to switch them to apply ‘Kerberos’ possibly by means of SPN.
Consider reading: Parental Controls in Windows 10. Guide to Establish.
Guide to restrict NTLM in Active Directory Domain fully.
The authentication without NTLM will operate differently for each program in our domain, we can add customer accounts to ‘protected users’ Domain group. As soon as the verification is over, you can fully deactivate NTLM Authentication in your Windows domain.
Summary
I am positive this tutorial helped you on How to deactivate NTLM Authentication Windows 10 with the range of simple solutions/approaches. You can read & follow our guidelines to make it possible. In case the tutorial definitely helped you, then you can share the article with other customers to assist them. In case you’ve got any proposals or questions, feel free to share them in the comments section below.
Brendan Smith
IT Security Expert
It is better to prevent, than repair and repent!
When we talk about the intrusion of unfamiliar programs into your computer’s work, the proverb «Forewarned is forearmed» describes the situation as accurately as possible. Gridinsoft Anti-Malware is exactly the tool that is always useful to have in your armory: fast, efficient, up-to-date. It is appropriate to use it as an emergency help at the slightest suspicion of infection.
References
- NT LAN Manager: https://en.wikipedia.org/wiki/NT_LAN_Manager
- Kerberos (protocol): https://en.wikipedia.org/wiki/Kerberos_(protocol)
- Windows Registry: https://en.wikipedia.org/wiki/Windows_Registry
Article
NTLM Authentication: How to Deactivate in Windows 10
Description
In this tutorial, we will give you instructions on “How to deactivate NTLM Authentication Windows 10”. You will be guided with simple recommendations to do so.
Author
Brendan Smith
Copyright
HowToFix.Guide
Japanese Spanish Chinese (Traditional)
About the author
Brendan Smith
I’m Brendan Smith, a passionate journalist, researcher, and web content developer. With a keen interest in computer technology and security, I specialize in delivering high-quality content that educates and empowers readers in navigating the digital landscape.
With a focus on computer technology and security, I am committed to sharing my knowledge and insights to help individuals and organizations protect themselves in the digital age. My expertise in cybersecurity principles, data privacy, and best practices allows me to provide practical tips and advice that readers can implement to enhance their online security.
Работая в среде Windows каждый системный администратор так или иначе сталкивается с системами аутентификации. Но для многих этот механизм представляет собой черный ящик, когда суть происходящих процессов остается неясна. В тоже время от правильной настройки аутентификации напрямую зависит безопасность сети, поэтому важно не только знать способы и протоколы, но и представлять их работу, хотя бы на общем уровне.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
В рамках данного материала мы будем рассматривать сознательно упрощенное представление процедур аутентификации, достаточное для понимания базового принципа работы, впоследствии данные знания могут быть углублены путем изучения специализированной литературы.
Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.
- Аутентификация — происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса — проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
- Авторизация — перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.
Чтобы проще представить себе этот процесс проведем простую аналогию. Вы находитесь за границей и вас останавливает полицейский, вы предъявляете свой паспорт. Полицейский проверяет данные в паспорте и сверяет фотографию — это процесс аутентификации. Убедившись, что вы это вы, полицейский просит показать визу — это процесс авторизации, т.е. вашего права здесь находиться.
Точно также, сотрудник полиции, остановив трудового мигранта и проверив его паспорт, просит разрешение на работу, если разрешения нет, то зарубежный гость успешно прошел аутентификацию, но провалил авторизацию. Если аутентификация не пройдена, то до авторизации дело не дойдет.
Для аутентификации в компьютерных системах традиционно используется сочетания имени пользователя и некой секретной фразы (пароля), позволяющей определить, что пользователь именно тот, за кого себя выдает. Существуют также и иные способы аутентификации, например, по смарт-карте, но в данной статье мы их касаться не будем.
Локальная аутентификация
Прежде всего начнем с локальной аутентификации, когда пользователь хочет войти непосредственно на рабочую станцию, не входящую в домен. Что происходит после того, как пользователь ввел свой логин и пароль? Сразу после этого введенные данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш, хэширование — это одностороннее криптографическое преобразование, делающее восстановление исходной последовательности невозможным. В открытом виде пароль нигде в системе не хранится и не фигурирует, пользователь — единственный кто его знает.
Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).
Затем LSA сравнивает хэш введенного пароля и хэш из базы SAM, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и находится там до окончания сеанса пользователя.
В случае входа пользователя в домен, для аутентификации используются иные механизмы, прежде всего протокол Kerberos, однако, если одна из сторон не может его использовать, по согласованию могут быть использованы протоколы NTLM и даже устаревший LM. Работу этих протоколов мы будем рассматривать ниже.
LAN Manager (LM)
Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.
Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:
- Пароль регистронезависимый и приводится к верхнему регистру.
- Длина пароля — 14 символов, более короткие пароли дополняются при создании хэша нулями.
- Пароль делится пополам и для каждой части создается свой хэш по алгоритму DES.
Исходя из современных требований к безопасности можно сказать, что LM-хэш практически не защищен и будучи перехвачен очень быстро расшифровывается. Сразу оговоримся, прямое восстановление хэша невозможно, однако в силу простоты алгоритма шифрования возможен подбор соответствующей паролю комбинации за предельно короткое время.
А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.
NT LAN Manager (NTLM)
Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.
Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.
Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.
Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:
Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер — к кому обращаются.
Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).
Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM. Если результаты совпадают, значит пользователь клиента действительно тот, за кого себя выдает, и аутентификация считается успешной.
В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.
В случае получения доступа к третьим ресурсам схема также немного изменяется:
Получив запрос от клиента, сервер точно также направит ему запрос сервера, но получив NTLM-ответ он не сможет вычислить значение для проверки на своей стороне, так как не располагает хэшем пароля доменного пользователя, поэтому он перенаправляет NTLM-ответ контроллеру домена и отправляет ему свой запрос сервера. Получив эти данные, контроллер домена извлекает хэш указанного пользователя и вычисляет на основе запроса сервера проверочную комбинацию, которую сравнивает с полученным NTLM-ответом, при совпадении серверу посылается сообщение, что аутентификация прошла успешно.
Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.
Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.
Но и перехваченного хэша может оказаться вполне достаточно, так как NTLM-ответ генерируется на базе пароля пользователя и подлинность клиента сервером никак не проверяется, то возможно использовать перехваченные данные для неавторизованного доступа к ресурсам сети. Отсутствие взаимной проверки подлинности также позволяет использовать атаки плана человек посередине, когда атакующий представляется клиенту сервером и наоборот, устанавливая при этом два канала и перехватывая передаваемые данные.
NTLMv2
Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.
Сразу рассмотрим схему с контроллером домена, в случае его отсутствия схема взаимодействия не меняется, только вычисления, производимые контроллером домена, выполняются непосредственно на сервере.
Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число — запрос сервера. В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента. Наличие метки времени позволяет избежать ситуации, когда атакующий первоначально накапливает перехваченные данные, а потом с их помощью осуществляет атаку.
Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.
Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.
Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.
При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.
Настройки безопасности
Теперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.
За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера — Конфигурация Windows — Политики безопасности — Локальные политики — Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.
В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.
В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.
Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:
| Наименование настройки | Клиентский компьютер | Контроллер домена | Lm Compatibility Level |
|---|---|---|---|
| Отправлять LM- и NTLM-ответы | Клиентские компьютеры используют LM и NTLM аутентификацию, и никогда не используют сеансовую безопасность NTLMv2. | Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. | 0 |
| Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2 | Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. | 1 |
| Отправлять только NTLM-ответ | Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. | 2 |
| Отправлять только NTLMv2-ответ | Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. | 3 |
| Отправлять только NTLMv2-ответ. Отказывать LM. | Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2. | 4 |
| Отправлять только NTLMv2-ответ. Отказывать LM и NTLM. | Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2. | 5 |
Внимательный читатель, изучая данную таблицу, обязательно обратит внимание на сеансовую безопасность NTLMv2. Данная возможность, как и вообще все взаимодействие по NTLMv2, довольно плохо документированы, поэтому многие понимают смысл этой возможности неправильно. Но на самом деле все довольно несложно.
После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.
Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
In an ever-evolving cybersecurity landscape, securing communications and data exchange is paramount. One such protocol that has been a focal point of discussion is NTLM (NT LAN Manager), which is used to authenticate users in Microsoft environments. With recent advancements and concerns about security, there’s been a shift from older NTLM versions to the more secure NTLMv2. Today, we’ll delve deep into a PowerShell script that helps manage NTLM authentication responses by setting the LmCompatibilityLevel in the Windows registry.
Background
Originally developed as an authentication protocol by Microsoft, NTLM has undergone several updates to tackle various security vulnerabilities. However, as more secure authentication mechanisms emerged, especially NTLMv2, the need to restrict or disable older versions became evident. This script aids IT professionals and Managed Service Providers (MSPs) in making this transition smoothly, without manually navigating through complex registry settings.
The Script
#Requires -Version 5.1
<#
.SYNOPSIS
Set the LM and NTLMv1 authentication responses via LmCompatibilityLevel in the registry
.DESCRIPTION
Set the LM and NTLMv1 authentication responses via LmCompatibilityLevel in the registry
.EXAMPLE
No parameters needed.
Sets LAN Manager auth level to 5, "Send NTLMv2 response only. Refuse LM & NTLM."
.EXAMPLE
-LmCompatibilityLevel 5
Sets LAN Manager auth level to 5, "Send NTLMv2 response only. Refuse LM & NTLM."
.EXAMPLE
-LmCompatibilityLevel 3
Sets LAN Manager auth level to 3, "Send NTLMv2 response only."
This is the default from Windows 7 and up.
.EXAMPLE
PS C:> Disable-LmNtlmV1.ps1 -LmCompatibilityLevel 5
Sets LAN Manager auth level to 5, "Send NTLMv2 response only. Refuse LM & NTLM."
.OUTPUTS
None
.NOTES
Minimum OS Architecture Supported: Windows 10, Windows Server 2016
Reference chart: https://ss64.com/nt/syntax-ntlm.html
Release Notes:
Initial Release
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms.
Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party.
Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider.
Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations.
Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks.
Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script.
EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
.COMPONENT
ProtocolSecurity
#>
[CmdletBinding()]
param (
[Parameter()]
[ValidateRange(0, 5)]
[int]
$LmCompatibilityLevel = 5
)
begin {
function Test-IsElevated {
$id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$p = New-Object System.Security.Principal.WindowsPrincipal($id)
if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
{ Write-Output $true }
else
{ Write-Output $false }
}
function Set-ItemProp {
param (
$Path,
$Name,
$Value,
[ValidateSet("DWord", "QWord", "String", "ExpandedString", "Binary", "MultiString", "Unknown")]
$PropertyType = "DWord"
)
New-Item -Path $Path -Force -ErrorAction SilentlyContinue | Out-Null
if ((Get-ItemProperty -Path $Path -Name $Name -ErrorAction SilentlyContinue)) {
Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false | Out-Null
}
else {
New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false | Out-Null
}
}
}
process {
if (-not (Test-IsElevated)) {
Write-Error -Message "Access Denied. Please run with Administrator privileges."
exit 1
}
$Path = @(
"HKLM:SYSTEMCurrentControlSetServicesLsa"
"HKLM:SYSTEMCurrentControlSetControlLSA"
)
$Name = "LmCompatibilityLevel"
# $Value = $LmCompatibilityLevel
# Sets LmCompatibilityLevel to $LmCompatibilityLevel
try {
$Path | ForEach-Object {
Set-ItemProp -Path $_ -Name $Name -Value $LmCompatibilityLevel
}
}
catch {
Write-Error $_
exit 1
}
$Path | ForEach-Object {
$Value = Get-ItemPropertyValue -Path $_ -Name $Name -ErrorAction SilentlyContinue
if ($null -eq $Value) {
Write-Host "$_$Name set to: OS's default value(3)."
}
else {
Write-Host "$_$Name set to: $Value"
}
}
}
end {}
Access 300+ scripts in the NinjaOne Dojo
Get Access
Detailed Breakdown
The script is essentially divided into three phases: begin, process, and end.
- Begin Phase: The script starts with defining two functions:
- Test-IsElevated: Checks if the script runs with Administrator privileges.
- Set-ItemProp: Creates or sets a registry key property.
- Process Phase: It verifies the user has elevated rights. If not, an error is flagged. Otherwise, it goes ahead to modify the LmCompatibilityLevel in two potential registry paths. Post modification, the script confirms the applied setting.
- End Phase: Not explicitly used, but it’s a placeholder for potential future updates or extensions to the script.
Potential Use Cases
Case Study: Imagine Jenny, an IT administrator in a mid-sized organization. They’ve recently undergone a security audit, revealing that certain systems still use outdated NTLM versions. With hundreds of machines to manage, manually updating each one isn’t feasible. Using this script, Jenny seamlessly updates all systems, ensuring they only accept NTLMv2 responses.
Comparisons
While Group Policy can also be used to manage NTLM settings across an organization, PowerShell scripts, like the one discussed, offer more granularity and automation. They can be integrated into larger automation tools or workflows, making the process streamlined and less prone to manual errors.
FAQs
- How does the script check for administrator privileges?
The script uses the Test-IsElevated function to determine if it’s running with admin rights. - What if I want to set a different LmCompatibilityLevel value?
You can do so by providing the -LmCompatibilityLevel parameter when running the script, e.g., Disable-LmNtlmV1.ps1 -LmCompatibilityLevel 3. - Is it backward compatible with older Windows versions?
The script supports Windows 10 and Windows Server 2016 and up.
Implications
By setting the LmCompatibilityLevel, IT professionals dictate how systems handle NTLM authentication. Restricting to NTLMv2 improves security, reducing risks associated with older, less secure versions. However, it’s crucial to ensure compatibility, as older systems or applications might face connectivity issues post changes.
Recommendations
- Always backup the current registry state before making changes.
- Initially, test the script in a controlled environment to understand its impact.
- Stay informed about the latest security best practices and integrate them into your routine audits.
Final Thoughts
While PowerShell scripts like these empower IT professionals to enhance security, monitoring and management tools like NinjaOne further elevate these capabilities. With integrated monitoring, automation, and reporting, platforms like NinjaOne ensure that your IT infrastructure remains robust, secure, and efficient, complementing scripts and manual interventions.
Remember, in the realm of IT, proactive measures, combined with the right tools, pave the way for enhanced security and efficient system management.