Disable NTLM Active Directory-Wide: 5 Safe Audit and Block Steps

To disable NTLM Active Directory-wide without breaking line-of-business applications, you audit every NTLM authentication first, fix the reasons Kerberos is not used, and only then block NTLM in stages with a short list of exceptions. This guide walks through that process on Windows Server 2016 to 2025 domain controllers and Windows 11 clients: the Restrict NTLM audit policies, the NTLM Operational events, how to find NTLMv1, the Kerberos fixes that remove most NTLM traffic, the blocking policies and a rollback you can apply in minutes.

Short answer: Enable “Network security: Restrict NTLM: Audit NTLM authentication in this domain” (Enable all) on domain controllers, “Audit Incoming NTLM Traffic” on servers and “Outgoing NTLM traffic to remote servers” = Audit all on clients. Collect events 8001 to 8004 from Microsoft-Windows-NTLM/Operational for several weeks, fix SPNs and IP-based access, set LAN Manager authentication level to refuse LM and NTLMv1, then move the Restrict NTLM policies from audit to deny one tier at a time, with server exceptions for what cannot move yet.

What Microsoft has announced

Only what Microsoft has published, as of September 2026:

• June 2024: all versions of NTLM, including LANMAN, NTLMv1 and NTLMv2, are deprecated: no new feature work. Applications should call Negotiate, which tries Kerberos first and falls back to NTLM only when needed.
• November 2024 update to that notice: NTLMv1 is removed starting in Windows 11 version 24H2 and Windows Server 2025.
• NTLMv1-derived credentials: a registry value BlockNtlmv1SSO under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 controls single sign-on with NTLMv1-derived credentials: 0 = audit (event 4024), 1 = enforce (event 4025). Microsoft’s published timeline changes the default to enforce in October 2026 on devices where it has not been set.
• January 2026 roadmap: phase 1 is enhanced NTLM auditing on Windows 11 24H2 and Windows Server 2025 (available now); phase 2, planned for the second half of 2026, adds IAKerb and a local KDC so Kerberos works in more places; phase 3, with the next major Windows Server release, blocks network NTLM by default, with a policy to re-enable it.

In other words, NTLMv2 still works today, but the direction is clear. Starting the plan to disable NTLM Active Directory-wide now gives you time to fix applications on your own schedule.

Which controls to use

No single setting will disable NTLM Active Directory-wide in one step. You combine audit policies, protocol hardening and blocking policies, each on the right tier of machines.

Control	Where	What it does	Risk
Restrict NTLM audit policies	DCs, servers, clients	Log NTLM use without blocking	None beyond log volume
Enhanced NTLM logging	Windows 11 24H2+, Server 2025	Richer events (4020 to 4033) including NTLMv1 use	None
LAN Manager authentication level	All machines	Refuse LM and NTLMv1	Low; breaks only very old devices
Protected Users group	Admin accounts	Members cannot use NTLM	Low for admins who use Kerberos
Restrict NTLM deny policies	Clients, servers, DCs	Block NTLM, with exception lists	High if skipped audit phase

Prerequisites

Check these before you try to disable NTLM Active Directory-wide; most failed projects skip the time, DNS or inventory work.

• Domain controllers on Windows Server 2016 or later (2025 adds enhanced logging). Healthy replication and DNS; check with dcdiag and repadmin.
• Accurate time on every machine, because Kerberos fails with clock skew over five minutes by default. See our PDC emulator time sync guide.
• A way to collect events from many machines: Windows Event Forwarding or a SIEM. The NTLM Operational log is local and can grow fast.
• An inventory of non-Windows systems that authenticate to AD: NAS devices, Linux servers, printers, VPN and Wi-Fi (RADIUS) servers, and web apps using Windows authentication.

Step 1: Turn on NTLM auditing

All Restrict NTLM policies are in Computer Configuration » Policies » Windows Settings » Security Settings » Local Policies » Security Options. Changes take effect without a restart.

Policy	Link to	Value	Registry value
“Network security: Restrict NTLM: Audit NTLM authentication in this domain”	Domain Controllers OU	Enable all	AuditNTLMInDomain (Netlogon\Parameters)
“Network security: Restrict NTLM: Audit Incoming NTLM Traffic”	Server OUs and DCs	Enable auditing for all accounts	AuditReceivingNTLMTraffic (Lsa\MSV1_0)
“Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers”	All computers	Audit all	RestrictSendingNTLMTraffic = 1 (Lsa\MSV1_0)

Put the DC setting in a separate GPO linked to the Domain Controllers OU rather than editing the Default Domain Controllers Policy.

On Windows 11 24H2 and Windows Server 2025 also enable enhanced logging: Administrative Templates » System » NTLM » "NTLM Enhanced Logging" on clients and servers, and Administrative Templates » System » Netlogon » "Log Enhanced Domain-wide NTLM Logs" on DCs. These add events 4020/4021 (client outgoing), 4022/4023 (server incoming) and 4030 to 4033 (DC), where Warning-level events flag security downgrades such as NTLMv1.

Read the NTLM events

Events go to Applications and Services Logs » Microsoft » Windows » NTLM » Operational.

Event	Logged on	What it tells you
8001	Client	Outgoing NTLM that would be blocked: Target server, Supplied user, Name of client process
8002	Server	Incoming NTLM that would be blocked by the incoming traffic policy, with the calling process
8003	Member server	NTLM for a domain account that the domain policy would block: user, workstation, process
8004	Domain controller	NTLM pass-through the DC would block: Secure Channel name (the server), user, workstation

Start at the DC. Event 8004 names the server that forwarded the logon; event 8003 on that server names the workstation and process; event 8001 on the workstation names the process and the exact target name it used. A process ID of 4 (System) means the call came through the SMB redirector, so look at which share or drive the user opened.

Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -MaxEvents 2000 |
  Where-Object Id -eq 8004 |
  ForEach-Object { if ($_.Message -match 'Secure Channel name:\s*(\S+)') { $Matches[1] } } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name -First 20

Run it on each DC. It lists the servers that forward the most NTLM logons, which is where you start fixing.

Step 2: Find and stop NTLMv1 and LM

NTLMv1 is the weakest part and the first thing to remove. On DCs and servers, successful logons (event 4624 in the Security log) show Authentication Package: NTLM and Package Name (NTLM only) as NTLM V1 or NTLM V2. List NTLMv1 logons:

$x = "*[System[EventID=4624]] and *[EventData[Data[@Name='LmPackageName']='NTLM V1']]"
Get-WinEvent -LogName Security -FilterXPath $x -MaxEvents 200 |
  Select-Object TimeCreated, @{n='User';e={$_.Properties[5].Value}}, @{n='Workstation';e={$_.Properties[11].Value}}, @{n='IP';e={$_.Properties[18].Value}}

Logon auditing must be on for this; see our AD audit policy guide. Once the list is empty or explained, set “Network security: LAN Manager authentication level” to “Send NTLMv2 response only. Refuse LM & NTLM” in a domain-wide GPO. It writes LmCompatibilityLevel = 5 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Windows 11 24H2 and Server 2025 no longer include NTLMv1, so this mainly protects older members and stops DCs accepting NTLMv1 from third-party devices.

Step 3: Fix why Kerberos is not used

This step is where the work to disable NTLM Active Directory-wide is really done. Most NTLM in a healthy domain comes from a handful of causes. Fixing them removes far more traffic than any exception list.

• Access by IP address. \\10.0.0.5\share falls back to NTLM. Use the DNS name. If an IP must be used, Windows 10 1507 and later and Server 2016 and later can use Kerberos when the client has TryIPSPN = 1 (REG_DWORD) under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters and the server account has an IP SPN, for example setspn -s host/10.0.0.5 FS01.
• Missing or duplicate SPNs. Web apps on service accounts, SQL Server and aliases (CNAMEs) need SPNs on the right account. Check with setspn -Q HTTP/intranet.contoso.com and find duplicates with setspn -X. Duplicate SPNs make Kerberos fail and Negotiate fall back to NTLM.
• Short names and aliases. A DNS alias with no matching SPN forces NTLM. Register the alias with setspn -S or use the real host name.
• Local accounts. Logons with local accounts, including remote management with a local administrator, always use NTLM. Use domain accounts, and Windows LAPS for break-glass access.
• Applications that call NTLM directly instead of Negotiate. Event 8001 shows the process name; ask the vendor for a Kerberos-capable version.
• No line of sight to a DC, for example remote users before the VPN connects. Kerberos needs a KDC; NTLM does not.
• Service accounts. Moving services to gMSAs is a good moment to register SPNs correctly.

Add administrative accounts to the Protected Users group as well. Members cannot authenticate with NTLM, so admin credentials are never exposed to relay, and any tool that still needs NTLM shows up quickly.

Step 4: Block NTLM in stages

Only block once the audit logs show a short, known list of NTLM users. Move one tier at a time, and leave at least a week between stages. Each blocking policy has an exception list that takes server names; the * wildcard is allowed.

Stage A: outgoing from a pilot group of clients

1. Set “Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers” to Deny all (RestrictSendingNTLMTraffic = 2) in a GPO filtered to a pilot group.
2. Add servers that still need NTLM to “Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication”, one per line, in the form the client uses (for example nas01, nas01.contoso.com, *.legacy.contoso.com).

Stage B: incoming on servers

On servers that no longer receive NTLM in the audit log, set “Network security: Restrict NTLM: Incoming NTLM traffic” to Deny all domain accounts, and later Deny all accounts, which also blocks local accounts.

Stage C: domain-wide on the DCs

1. Add the servers that still need NTLM pass-through to “Network security: Restrict NTLM: Add server exceptions in this domain” (NetBIOS names, one per line, * allowed).
2. Set “Network security: Restrict NTLM: NTLM authentication in this domain” to Deny for domain accounts to domain servers first, then to Deny all when the audit log is clean. Other steps between are Deny for domain accounts and Deny for domain servers.

Blocked attempts are logged in the same NTLM Operational log, so the audit queries above keep working after you disable NTLM Active Directory-wide.

Step 5: Handle exceptions properly

Exceptions are normal when you disable NTLM Active Directory-wide; unmanaged exceptions are what bring NTLM back over time.

• Keep the server exception lists short and reviewed. Each entry should have an owner and a date by which it moves to Kerberos or is retired.
• Use separate GPOs for the audit settings and the deny settings, so rollback is one change.
• Machines that must keep NTLM (for example a server that hosts a legacy app) can be excluded from the deny GPO with security filtering rather than by weakening the policy for everyone.
• Pair the work with SMB signing: signing protects the NTLM traffic you cannot remove yet from relay.

Verify it works

1. Confirm the values on a target machine:
   

   reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v RestrictSendingNTLMTraffic
   reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel
   gpresult /h C:\Temp\gp.html

2. Run klist after opening a share or web app. A ticket for cifs/fs01.contoso.com or HTTP/intranet.contoso.com means Kerberos was used.
3. On DCs, the count of event 8004 should fall week by week; on clients, 8001 should list only the servers in your exception list.
4. Check event 4624 on servers: Authentication Package should read Kerberos for domain logons.

If numbers stop falling, go back to Step 3: a single misconfigured SPN can generate thousands of events.

Troubleshooting

Symptom	Likely cause	Fix
Share opened by IP fails after blocking	IP access uses NTLM	Use the DNS name, or TryIPSPN plus an IP SPN
Intranet site prompts for credentials	Missing SPN for the site name or app pool account	setspn -S HTTP/name account; check duplicates with setspn -X
NAS or printer cannot authenticate	Device supports only NTLM	Add to the exception list; plan replacement
Admin cannot use a management tool	Account in Protected Users; tool uses NTLM	Use the FQDN, update the tool, or use a separate account
Kerberos errors after changes	Clock skew or DC not reachable	Fix time sync and DNS; check nltest /dsgetdc:contoso.com
Events 4024 or 4025	Something uses NTLMv1-derived credentials	Find the source; keep BlockNtlmv1SSO at 0 only while you fix it
No 8004 events at all	Audit policy not on DCs, or GPO not applied	Check the DC GPO with gpresult

Roll back

1. Set the deny policies back to their audit values: Outgoing NTLM traffic = Audit all, Incoming NTLM traffic = Allow all, NTLM authentication in this domain = Disable. These take effect without a restart after the next policy refresh; force it with gpupdate /force on DCs and affected servers.
2. If you only need to unblock one server, add it to the matching exception list instead of reverting the whole policy.
3. For LAN Manager authentication level, step back from 5 to 3 (“Send NTLMv2 response only”) if a device needs it, and keep investigating.
4. Remove accounts from Protected Users only after confirming NTLM is the cause, and sign them out and in again.

Keep the audit GPOs in place even after rollback. The logs are what let you disable NTLM Active Directory-wide the next time without surprises.

Microsoft’s NTLM phase-out plan (2026)

On 29 January 2026 Microsoft published a three-phase roadmap that takes NTLM from deprecated to disabled by default. Microsoft says the timelines may change, so treat the dates below as plans, not promises.

Phase	What changes	When	Applies to
1. Visibility and control	Enhanced NTLM auditing: who used NTLM, why, and from where, including NTLMv1 use	Available now	Windows Server 2025, Windows 11 24H2 and later
2. Remove the main blockers	IAKerb (Kerberos when the client cannot reach a DC), Local KDC (Kerberos for local accounts), core Windows components negotiating Kerberos first	Second half of 2026; IAKerb and LocalKDC entered Windows Insider (Canary) public preview in June 2026	Windows Server 2025, Windows 11 24H2 and later
3. Disabled by default	Network NTLM blocked by default; re-enabled only through new policy controls; built-in handling for unknown SPNs, IP-address targets and local accounts on domain-joined machines	Next major Windows Server release	That release and the associated Windows client releases

“Disabled by default” is not removal. In phase 3 NTLM stays in the operating system and can be switched back on by policy; Microsoft describes full removal as a later step. In the June 2026 preview, IAKerb is on by default and Local KDC is off by default, both controlled by registry values for now, with Group Policy and MDM settings promised later. Do not deploy the preview builds in production.

A separate change lands first: Microsoft’s timeline for NTLMv1-derived credentials switches the default of BlockNtlmv1SSO (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0) from audit (0) to enforce (1) in October 2026, on Windows 11 24H2 and Windows Server 2025 devices where the value has not been set. It does not apply where Credential Guard is enabled, and Microsoft marks the date as tentative.

What to do now

1. Turn on the right audit for each OS. On Windows Server 2016 to 2022 and older clients, use the Restrict NTLM audit policies from Step 1 and collect events 8001 (client), 8002 and 8003 (server) and 8004 (DC) from Microsoft-Windows-NTLM/Operational. On Windows Server 2025 and Windows 11 24H2 the enhanced events are on by default once Microsoft’s staged rollout has reached the device (policies NTLM Enhanced Logging under System » NTLM and Log Enhanced Domain-wide NTLM Logs under System » Netlogon): 4020/4021 on clients, 4022/4023 on servers, and 4030 to 4033 on DCs. The second ID in each pair is the Warning version, logged for downgrades such as NTLMv1 or a missing message integrity check.

2. Group client events by reason. Events 4020/4021 carry a Reason ID that says why Kerberos was not used. Count them on a pilot client:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-NTLM/Operational'; Id=4020,4021} -MaxEvents 5000 |
  ForEach-Object { if ($_.Message -match 'Reason ID:\s*(\d+)') { $Matches[1] } } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

Reason ID	Meaning (Microsoft)	Usual fix
1	The application called NTLM directly	Ask the vendor for Negotiate/Kerberos support
2	Authenticating a local account	Use domain accounts; Local KDC targets this case
5, 6	Target name missing, or could not be resolved by Kerberos	Register the SPN; use the FQDN
7	Target name contains an IP address	Use the DNS name, or TryIPSPN plus an IP SPN (Step 3)
8	Target name duplicated in Active Directory	Find and remove duplicates with setspn -X
9	No line of sight to a domain controller	Fix DC reachability; IAKerb targets this case

3. Decide BlockNtlmv1SSO yourself before the default flips. Look for event 4024 (audit) in the NTLM Operational log; after enforcement, blocked attempts log 4025. Find the source of any 4024 events, then set the value explicitly rather than inheriting the new default.

4. Map dependencies and owners. Every application or device that still needs NTLM should have an owner and a plan, which is the same list as your exception list in Step 5.

5. Test NTLM-off now. Apply the deny policies from Step 4 to a lab or pilot OU so you see what phase 3 will break before a new Windows Server release does it by default.

6. Track phase 2. When IAKerb and Local KDC reach general release for Windows Server 2025 and Windows 11 24H2, re-run the reason count above: reasons 2 and 9 should start to fall.

Disable NTLM Active Directory at a glance

Official documentation: Deprecated features for Windows client (NTLM), Network security: Restrict NTLM: Audit incoming NTLM traffic, Configuring Kerberos for IP addresses.

Related guides: SMB signing and disabling SMBv1 with Group Policy · AD audit policy: logons, account changes, lockouts · Group Managed Service Accounts (gMSA).

Frequently asked questions