Active Directory: Disabling NTLMv1 & Enforcing NTLMv2 Authentication

When it comes to securing your Active Directory environment, disabling NTLMv1 and enforcing NTLMv2 should be a top priority. While NTLMv2 has been available since the days of Windows NT 4.0 SP4, many environments still fall back on the older, less secure NTLMv1 protocol, either due to legacy systems or misconfigured group policies.

In this post, we’ll walk through the importance of moving away from NTLMv1, how to enforce NTLMv2, how to audit for NTLMv1 use, and what to look out for during implementation.

Why NTLMv1 is No Longer Safe?

NTLM authentication works using a challenge-response mechanism. The server sends a random value (called a nonce), and the client responds with an encrypted version using a hash of the user’s password.

The issue? NTLMv1 uses outdated encryption (DES), which makes it vulnerable to modern attacks, including brute force, replay, and man-in-the-middle scenarios. NTLMv2, while still not perfect, uses stronger encryption with additional inputs (HMAC-MD5), offering significantly better security.

Understanding the Compatibility Levels

Windows controls the behavior of NTLM authentication via a setting called LmCompatibilityLevel, found in the registry under:

HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

This value can be set through Group Policy using the "Network security: LAN Manager authentication level" setting.

Level	Description
0	Use LM and NTLM responses; never use NTLMv2 session security
1	Use LM and NTLM; use NTLMv2 session security if supported
2	Use NTLM only; NTLMv2 session security if supported
3	Use NTLMv2 only; if supported, use session security
4	NTLMv2 only; reject LM
5	NTLMv2 only; reject both LM and NTLMv1

Important. Once domain controllers are set to level 5, they will outright reject NTLMv1 requests. If legacy systems are still using NTLMv1, this could cause login failures or even mass account lockouts due to repeated failed attempts.

How to Audit NTLMv1 Use in Your Domain?

Before enforcing stricter NTLM settings, it’s critical to identify which systems are still using NTLMv1. You can do this by auditing Event ID 4624 (successful logons) and filtering for NTLMv1 connections.

Here's a PowerShell snippet to help extract NTLMv1 login events from the Security log:

Get-WinEvent -FilterXml @"
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]] 
[EventData[Data[@Name='LmPackageName'] and (Data='NTLM V1')]]
</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

Note. These events will appear on the server where the logon occurred, not necessarily the domain controller. So ensure you collect logs from all potential sources—including workstations and file servers.

Best Practices for Migration

Here’s a phased approach to implementing NTLMv2 safely:

Phase 1. Set All Clients to Level 3 or Higher

Ensure all domain-joined machines are configured to request only NTLMv2. This can be done using Group Policy.

Phase 2. Audit Thoroughly

Use the PowerShell audit script to identify NTLMv1 usage. Pay special attention to legacy applications, 3rd-party devices, and embedded systems.

Phase 3. Spot-Check for Policy "Tattooing"

Older Group Policies can sometimes leave values in the registry even after being removed. These are called “tattooed” values. Use a script or GPO inventory tool to detect them.

Phase 4. Push Domain Controllers to Level 5

Once you’ve confirmed that no systems are using NTLMv1, update your DCs to only accept NTLMv2. This ensures maximum protection against downgrade attacks.

Dos and Don’ts

Do	Don’t
Ensure all clients are at compatibility level 3+	Jump directly to level 5 on DCs without auditing
Audit all systems for NTLMv1 usage	Forget to check 3rd-party appliances and embedded systems
Use centralized policy management (GPO, Intune)	Let registry values get out of sync across devices
Monitor event logs centrally via SIEM or Event Forwarding	Assume newer OS versions are immune to NTLMv1 usage
Consider enabling Credential Guard	Leave outdated applications unpatched

Final Thoughts

NTLMv1 may still be lurking in your environment without you even knowing it. Enforcing NTLMv2 is one of the easiest wins for improving Active Directory security. With proper planning, auditing, and policy enforcement, you can retire NTLMv1 and reduce your exposure to credential relay and brute-force attacks.