Reducing NTLM in Active Directory: a realistic six-step roadmap
Microsoft has made clear its intention to move away from NTLM in favour of Kerberos, and the protocol is now considered deprecated. Yet in most domains it is still used every day by applications, appliances and scripts. Turning it off overnight would be risky; reducing it methodically is within reach of any team.
Why NTLM is a problem
NTLM is a challenge-response protocol that does not authenticate the server and does not natively bind authentication to the session carrying it. That makes it vulnerable to relay: an attacker who triggers an authentication, for example through PetitPotam-style coercion or LLMNR poisoning, can replay it to LDAP, SMB or an AD CS web service. NTLMv1 and LM make things worse, since their responses are very easy to crack.
Step 1: measure before acting
Start with auditing. On domain controllers, the policy "Network security: Restrict NTLM: Audit NTLM authentication in this domain" generates events in the Microsoft-Windows-NTLM/Operational log, including event 8004, which records the account, the source machine and the target server. On servers, auditing incoming NTLM traffic produces similar events. Event 4624 also shows the authentication package and the NTLM version used. Plan several weeks of collection to cover monthly jobs.
Step 2: get rid of NTLMv1 and LM
Set "Network security: LAN Manager authentication level" to "Send NTLMv2 response only. Refuse LM & NTLM" (level 5), after identifying the few clients still using NTLMv1 through event 4624. Microsoft has announced the removal of NTLMv1 in Windows 11 24H2 and Windows Server 2025; check the exact behaviour on your versions.
Step 3: fix the reasons for falling back to NTLM
Most NTLM use is unintended. Common causes include:
- reaching a server by IP address instead of by name;
- missing or duplicate SPNs;
- applications that force NTLM instead of Negotiate;
- local accounts or non-domain machines;
- third-party devices (NAS, printers, appliances) with limited implementations.
Step 4: protect against relay
In parallel, limit the impact of relay: require SMB signing, LDAP signing and channel binding on domain controllers, Extended Protection for Authentication (EPA) on AD CS and IIS web services, and disable LLMNR and NBT-NS. These measures make NTLM far less exploitable, even before you reduce it.
Step 5: restrict gradually
The "Restrict NTLM" policies let you deny NTLM per server or per domain, with an exception list. Work in rings: privileged accounts first (the Protected Users group blocks NTLM for its members), then sensitive servers, then the rest of the estate.
Never block blind. Every restriction should follow an audit period on the same scope. A documented, temporary exception is better than an emergency rollback.
Step 6: monitor and maintain
Track NTLM authentication volume as a metric, review exceptions regularly and make Kerberos support a purchasing requirement for new applications. Microsoft is working on features intended to cover the remaining NTLM use cases; their availability will depend on Windows versions, so keep your timeline cautious.
What an audit checks
- the LAN Manager authentication level applied to domain controllers and members;
- whether NTLM auditing is enabled;
- anti-relay measures: SMB and LDAP signing, channel binding, EPA;
- use of the Protected Users group for privileged accounts.