Disabling NTLM: Audit First, Then Enforce Domain-Wide

NTLM does not go away because a security team decides it should. It goes away when every account, service, and appliance that still negotiates it has been found, exempted or fixed, and the domain has been walked through audit, partial deny, and full deny without breaking a quarter-end batch job. This is the sequence that gets you there without a helpdesk incident, starting with why the protocol is worth removing in the first place.

Why NTLM Is Still a Live Relay and Pass-the-Hash Target

NTLM is a challenge-response protocol with no mutual authentication and no built-in protection against the response being forwarded somewhere else. An attacker who can coerce a machine account into authenticating, through PetitPotam, the print spooler bug, or a simple malicious file share, can relay that NTLM authentication attempt to LDAP, LDAPS, or an Active Directory Certificate Services web enrollment endpoint instead of the intended target. If LDAP signing and channel binding are not enforced, the relay lands as a privileged directory write. If AD CS is reachable and issuing certificates without Extended Protection, the relay lands as a certificate the attacker can use to authenticate as the coerced account, often a domain controller.

Pass-the-hash is the older half of the same problem. The NTLM hash is credential-equivalent: an attacker who dumps it from LSASS or a SAM database does not need to crack it, they can present it directly to authenticate. Neither issue is a bug in a specific Windows build. Both are structural properties of a protocol designed before Kerberos was the default, and both stay exploitable as long as NTLM is negotiable somewhere in the environment. Removing NTLM does not just close one CVE, it removes the transport that a whole family of coerce-and-relay chains depends on.

Turning On NTLM Auditing and Reading the Event Stream Without Drowning

Do not jump to a deny policy. Start with audit mode and let it run for at least one full billing or reporting cycle, ideally a month-end and a quarter-end, because periodic jobs that only fire once a quarter are exactly the ones a two-week audit window misses. Three Group Policy settings under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options do the work:

• Network security: Restrict NTLM: Audit NTLM authentication in this domain, set to Enable all, deployed to domain controllers. This produces event ID 8004 for every NTLM authentication the DC processes, with the client account, client computer name, and target server name in the event data.
• Network security: Restrict NTLM: Audit Incoming NTLM Traffic, set to Enable auditing for all accounts, deployed to member servers. This produces event ID 8003 on the server that accepted the NTLM logon.
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers, set to Audit all, deployed to workstations and servers acting as clients. This produces event ID 8002 for each outgoing NTLM attempt, and later, once you flip to a deny setting, event ID 8001 for each one that gets blocked.

These events land in Applications and Services Logs, Microsoft, Windows, NTLM, Operational, a log that is disabled by default and has to be enabled explicitly per host before anything is recorded. Forward it to your log pipeline rather than reading it in Event Viewer. Group by the triple of client account, source host, and target server name, drop anything that is clearly Kerberos already succeeding in parallel, and you have the actual inventory of what still depends on NTLM instead of a guess.

Building the Exception Inventory

The 8001 through 8004 data will cluster into a small number of predictable categories:

• Appliances and out-of-band management, such as backup software agents, print servers, and iLO or iDRAC consoles that authenticate to file shares by IP address rather than hostname.
• Vulnerability scanners configured with credentialed scan targets entered as raw IPs, which forces NTLM because Kerberos needs a service principal name that matches the name the client requested, and an IP address does not carry one by default.
• Hard-coded IP shares inside scripts, scheduled tasks, and mapped drives, often written years before anyone cared which authentication protocol negotiated underneath the UNC path.
• Old Linux and Samba hosts, and NAS appliances, that only implement NTLMv1 or NTLM without Kerberos support at all.
• Legacy multifunction printers with scan-to-folder or scan-to-email features authenticating against a share.

For the IP-literal cases, the fix is often cheaper than an exception: register a service principal name for the target host and switch the script or mapped drive to the hostname, and Kerberos becomes available without any policy change. For everything genuinely stuck on NTLM, such as the old Samba box that will be decommissioned next year, the exception goes into a maintained list, not into a mental note. A network reachability sweep that already fingerprints which hosts answer SMB without Kerberos, the kind of pass an attack surface management module runs as part of normal discovery, gives you this inventory before you even turn auditing on, which shortens the audit window considerably.

Interim Controls: SMB Signing, LDAP Channel Binding, EPA, and NTLM Blocking by Exception

While NTLM is still negotiable for the exception list, close the relay path itself so a coerced authentication attempt cannot be forwarded anywhere useful:

• SMB signing, enforced through “Microsoft network client: Digitally sign communications (always)” and the matching server-side policy. Confirm with Get-SmbServerConfiguration | Select RequireSecuritySignature rather than trusting the GPO applied silently.
• LDAP channel binding and signing, set on domain controllers through the LdapEnforceChannelBinding and LDAPServerIntegrity registry values. This is the single control that closes NTLM-relay-to-LDAP, the step of most PetitPotam-style chains, independent of whether NTLM itself is still allowed.
• Extended Protection for Authentication on AD CS web enrollment endpoints, LDAPS binds, and any IIS site accepting NTLM. EPA binds the authentication to the TLS channel it arrived on, so a relayed attempt over a different channel is rejected even when the credential itself is valid.
• NTLM blocking by exception, using “Restrict NTLM: Add server exceptions in this domain” and “Restrict NTLM: Add remote server exceptions for NTLM authentication” to name the specific hosts allowed to keep negotiating NTLM while the deny policy applies to everything else. This is the mechanism that turns your audit-derived exception inventory into an actual working state rather than a spreadsheet.

Staged Enforcement with Restrict NTLM Policies and Per-Server Exception Lists

Move from audit to deny in stages, and by organizational unit, not by flipping a domain-wide switch on a Friday:

1. Set “Restrict NTLM: NTLM authentication in this domain” to Deny for domain accounts to domain servers first. This forces client-to-domain-controller authentication onto Kerberos while leaving service accounts and application servers untouched, and it surfaces any client still hard-configured for NTLM against a DC quickly and safely.
2. Pick one low-risk OU, IT staff workstations are a reasonable start, and apply the outgoing policy “Restrict NTLM: Outgoing NTLM traffic to remote servers” set to Deny all except for the exception list you built. Watch for a full week before widening the scope.
3. Broaden by OU rather than domain-wide, expanding the exception list as new legitimate cases surface rather than reopening audit mode from scratch.
4. Only after outgoing traffic is denied cleanly across most of the domain, apply “Restrict NTLM: Deny all” as the domain-wide setting, with the accumulated server exception list carrying the remaining legitimate cases.

Keep the exception list itself under change control. Every entry should have an owner, a reason, and a planned removal date, otherwise the list becomes the new permanent attack surface instead of a temporary bridge.

Regression Watch: What Breaks Weeks Later, and How to Catch It First

The failures that show up two or three weeks after enforcement, not on day one, are almost always tied to something that runs on a cycle longer than your test window: a quarter-end reconciliation job, an annual license renewal script, a certificate auto-enrollment task using a legacy template, a backup job scheduled monthly instead of nightly, or a disaster-recovery failover test that only runs twice a year against a DR site nobody added to the exception list because it was never in scope during the audit month.

Two habits catch these before the helpdesk does. First, leave the audit GPOs running even after you move to deny, since a denied NTLM attempt still generates an 8001 event, and an alert on any 8001 from a host that should no longer be attempting NTLM is a much earlier signal than a ticket. Second, review the exception list against a calendar, not just against tickets, checking it before every fiscal quarter close and before any scheduled DR test. Re-testing a control after it is enforced, rather than trusting that the GPO applied and moving on, is the same discipline that closes out a vulnerability finding properly: an automated pipeline that re-checks a fix instead of trusting an exit code, the kind of behavior a retest and closure stage is built around, catches an NTLM exception that silently expanded back open the same way it would catch a patch that silently rolled back.

NTLM removal also has a paper trail worth keeping for its own sake. CIS benchmarks for Windows Server include explicit settings for the Restrict NTLM policy family, and PCI DSS and NIST 800-63B guidance both push away from password-equivalent credentials like the NTLM hash. Tying the specific finding, NTLMv1 still enabled on a named host, to the control it violates is what turns this project from an internal cleanup into evidence an auditor can read, which is the kind of link a compliance mapping view is meant to hold onto so it does not live only in someone’s memory of the project.

None of this is a one-quarter project on a domain of meaningful size. Budget for audit, one OU-by-OU enforcement pass, and a full seasonal cycle of regression watching before calling NTLM actually gone rather than merely discouraged.

About SITEY

SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.