Active Directory Hardening Series - Part 1 – Disabling NTLMv1
Hello everyone, Jerry Devore back again after to along break from blogging to talk about Active Directory hardening. In my role at Microsoft, I have found every organization has room to improve when it comes to hardening Active Directory. Many times, customers are aware of issues but are afraid of unintended impacts if they make a change. In other words, organizations are getting stuck in the "analysis paralysis" stage. In this series my goal is to help you understand how to move forward with confidence by better understanding the changes along with how to perform proper due diligence.
Before we jump into the first topic it’s worth discussing why it is important to invest effort into Active Directory security given Microsoft considers it a legacy technology. After all, it is very compelling to prioritize moving to modern features offered by Entra ID rather than spending time on Active Directory. The simple explanation is cyber adversaries are continuing to have much success accessing privileged credentials by targeting Active Directory. As a result, they are able to gain control of critical data and systems. From there they often pivot to cloud resources as a secondary target.
We are often asked why Microsoft cannot simply harden Active Directory with a security update. While it would be nice if an "easy button" was an option, the reality is nearly all Microsoft customers are carrying a significant amount of "technical debt", which has complex dependencies on Active Directory. Microsoft moves the needle with Active Directory security where possible, but for the most part this must be a joint effort to avoid significant impacts to production environments. While pursuing Active Directory hardening can be a time and resource intensive initiative, bear in mind the checklist to proactively secure your Active Directory is often similar to the one required for compromised recovery. Having witnessed it performed both ways I can assure you it is better to tackle this effort proactively rather than in the midst of a crisis.
Enforcing NTLMv2
For the first topic in this series, I would like to address is the enforcement of NTLMv2. NTLMv2 has been around since Windows NT 4.0 SP4 and we have been talking about enforcing its use for well over 10 years now. There has been plenty written on how NTLM works and why NTLMv1 is no longer secure. Rather than recreating that content I will just stress these key concepts.
Configuration settings
The setting used to control NTLM negotiation behavior is referred to as LmCompatibilityLevel. When managed by the policy setting Network security: LAN Manager authentication level the registry key HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel will be created and configured.
The table below describes a description of the various levels (0-5). A few concepts that help explain the levels are:
Setting |
Description |
Registry security level |
Send LM & NTLM responses |
Client devices use LM and NTLM authentication, and they never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
0 |
Send LM & NTLM – use NTLMv2 session security if negotiated |
Client devices use LM and NTLM authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
1 |
Send NTLM response only |
Client devices use NTLMv1 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
2 |
Send NTLMv2 response only |
Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
3 |
Send NTLMv2 response only. Refuse LM |
Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM authentication, and they'll accept only NTLM and NTLMv2 authentication. |
4 |
Send NTLMv2 response only. Refuse LM & NTLM |
Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM and NTLM authentication, and they'll accept only NTLMv2 authentication. |
5 |
The registry key HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel does not exist by default. When it is missing the OS version will determine the behavior. The table below shows the native behavior by OS.
OS |
Default LmCompatibilityLevel |
Sever 2000 \ XP |
1 - NTLMv1 |
Server 2003 |
2 - NTLMv1 with v2 Session Security |
Vista \ 2008 and higher |
3 - NTLMv2 |
There is one more key consideration when working with this setting. The registry key outside the typical path for group policies (HKLM\SOFTWARE\Policies). As a result, the registry will become tattooed if the policy has a value set and then configured to "not defined". In that situation it will be necessary to clear the registry key from every device that has processed the policy if you want to remove the tattoo. Some documentation indicates it is necessary to reboot a device after modifying LmCompatibilityLevel. That is not correct. A change via policy or registry modification will be effective immediately.
Auditing for NTLMv1
If your environment has no legacy devices or old GPOs downgrading LmCompatibilityLevel, you should be ready to configure a domain wide policy to level 5 and call this project done. Before you pull that trigger it is highly recommended that you use auditing to confirm there are no unexpected dependencies on NTLMv1. For that you will need to focus on the Package Name field in 4624 Events.
Keep in mind that when the authentication occurs against a member server, the 4624 event will be logged in the security log of that server. The validating domain controller will log a 4776 event (The computer attempted to validate the credentials for an account) which does not capture the NTLM version. Therefore, you will need to collect the events from all servers in order to have a comprehensive understanding of the environment. If you are concerned about endpoint devices hosting resources, you will need to collect their 4624 events as well.
Hopefully your organization already has a SEIM solution that centrally collects security events and can help filter and visualize the data. If that is not the case, you can leverage the Windows Event Forwarding feature to forward all 4624 events into a centralized log file. Once the events are in a central log you could use some PowerShell code like this which will read the security log and export key details about NTLMv1 authentications.
Get-WinEvent -FilterXml @"
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
[EventData[Data[@Name='AuthenticationPackageName'] and (Data='NTLM V1')]]
[EventData[Data[@Name='TargetUserName'] and (Data!='ANONYMOUS LOGON')]]
</Select>
</Query>
</QueryList>
"@ | Where-Object {$_.Properties[5].Value -ne "ANONYMOUS LOGON"} | Select-Object TimeCreated, @{Name='Account Name';Expression={$_.Properties[5].Value}}, @{Name='Account Domain';Expression={$_.Properties[6].Value}}, @{Name='Logon Type';Expression={$_.Properties[8].Value}}, @{Name='Workstation Name';Expression={$_.Properties[11].Value}}, @{Name='Source Network Address';Expression={$_.Properties[18].Value}} | Export-Csv -Path C:\NTLMv1Events.csv -NoTypeInformation
You may have noticed that my filter excludes Anonymous Logons. This is because they are not true NTLMv1 authentications as explained in this article.
Do's and Don'ts for disabling NTLMv1 in a domain
Hopefully this information will help give you confidence to take action in your environment. Just keep the following points in mind and you will be well on your way.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.