Active Directory Hardening Series - Part 8 – Disabling NTLM

Hi All.  Jerry Devore back again to continue talking about hardening Active Directory.  This time I want to discuss disabling NTLM or more likely how to minimize its use in a domain until all dependencies have been removed.  Technically it has been possible to block NTLM since Windows Server 2008 R2 but implementing those policies has proven to be too daunting for most organizations.  However, in recent years there has been a renewed effort to sunset NTLM given the inherit vulnerabilities not to mention the regularly used exploits that take advantage of those weaknesses.  If you are expecting to find an "easy button" in this article I will save you time by saying this is not going to be easy.  However, I hope to provide a framework you can follow to get the process started.

Baselining

Business theorist Peter Drucker is credited with saying "You can't manage what you can't measure".  That sentiment is a perfect way to frame up this effort.  Since it was introduced, Active Directory's primary and preferred authentication protocol has been Kerberos, but NTLM has always been ready to step in and help if Kerberos fails.  While most understand that concept, I find many don't realize just how much NTLM fallback is really occurring with their domains, devices and applications.   A logical first step in the effort is to establish a baseline of the daily volume of NTLM authentications occurring in a domain. A simple way to do that would be to leverage 4776 events from domain controller security logs.  Assuming you are auditing for Account Logon\Credential Validation, each time an NTLM authentication is forwarded to a domain controller for validation, a 4776 event will be logged which will capture the name of the authenticating account along with the client (source workstation) of the authentication request.  Unfortunately, it does not capture the name of the device where the account was logging on.

On the device where the logon occurred a 4624 event will be logged.  Those events can be very helpful because they capture the authenticating user, the client device (Workstation Name) and the device that was accessed.  As a bonus it will also tell you the version of NTLM that was negotiated.

Another way to understand the volume of NTLM authentications is to leverage Performance Monitor.  The counter Security System-Wide Statistics \ NTLM Authentications will reflect both NTLM credential validations performed along with direct NTLM authenticated connections to the domain controller.

Regardless of how you record the volume, reporting daily totals via a dashboard will allow you and your management to track the progress of your efforts.  If you are going to implement such a dashboard, I recommend you also represent Kerberos authentications and highlight the percentage of authentications using NTLM versus the number of Kerberos service tickets issued.  Given service tickets by default have a maximum lifetime of 10 hours, it will not be an apples-to-apples comparison but seeing the shift will help confirm you are moving in the right direction.

Enabling Auditing  

While the 4776 and 4624 events provide a good start, they really provide no information regarding the process that is using NTLM.  To get that level of detail we need to up our auditing game using the following policy settings located in Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.

 

 

Once that auditing is configured the following events will be logged to Applications and Services Logs\ Microsoft \ Windows \ NTLM \ Operational.  In reviewing the table keep in mind:

• Client refers to the device that originated the authentication.  It does not reflect the OS or its role in the domain.
• Server refers to the devices being authenticated to.  It does not reflect the OS or its role in the domain.

 

 

Now that we know what to look for let’s test it out.  Here is an example where Joe_User on CONTOSO-PC1 used Edge to connect to IIS on CONTOSO-FS2 using NTLM. 

Event 8001 on CONTOSO-PC1 captured:

• The target server of the authentication (HTTP/contoso-fs2.contoso.local)
• The name of the process used for the authentication (msedge.exe)
• The name of identity for the authentication. (joe_user)

Event 8003 on CONTOSO-F2 captured:

• The identity of authenticating account (joe_user)
• The name of the client (CONTOSO-PC1)
• The name of the process that was accessed (w3wp.exe)

Event 8004 on CONTOSO-DC3 captured:

• The name of the authenticating account (joe_user)
• Name of the client device (CONTOSO-PC1)
• The name of the server being authenticated to (Secure channel name – CONTOSO-FS2)

But wait there is more!

Microsoft developers have been busy working on new features to make it more feasible to audit NTLM and restrict NTLM.  One such feature is the new enhanced audit events which captures much richer detail related to NTLM use.  Here are some examples of the goodness that will soon be available on Windows 11 24H2 and Server 2025.

Event 4020 on the clients contains all the same information as the 8001 events but it also captures the reason NTLM was selected along with other useful information like the NTLM version, Service Principal Name and the negotiation flags.

 

Event 4022 logged on the server being accessed captured more details than 8002 / 8003 events such as the SPN being accessed and the NTLM version negotiated

Event 4032 logged on the domain controller is a game changer because it finally provides a way to detect the version of NTLM negotiated using only the domain controller log.  Previously it was necessary to collect the 4624 events from all domain joined devices in order to detect NTLMv1 use.

In addition to these examples there are a few other new events related to detecting NTLM authentications to a domain controller and cross domain authentication using NTLM.  There currently are no plans to backport this auditing to early operating systems.  If you want to begin evaluating the events you can sign up for the Windows Insider program.

 

Is your head spinning from all the event IDs mentioned so far?  To help keep them straight here is a table that provides a summary of the different options for hunting down NTLM use.

Remediation

Now that we know where NTLM is being used we can start to investigate why it is being selected over Kerberos.  Performing that analysis involves attributing the failures to one of the following categories.

1.  Domain Controller Connectivity

Authenticating with Kerberos requires the client to acquire a service ticket directly from a domain controller in the resource’s domain.  In contrast NTLM only requires the client to have connectivity to the resource since credential validation is handled by the resource (secure channel path back to the user’s domain).  Such failures are more common in multi-domain environments with network segmentation or when an application is hosted by another trust organization.  Currently KDC Proxy is the only native solution to help with such line of sight issues but it’s list of supported applications is pretty limited.  A similar feature named IAKerb is currently in development which will allow the resource server to act as a proxy and enable the client to acquire service tickets without direct connectivity to the resource domain controller.  Unlike KDC Proxy, IAKerb will not be application dependent.

2.  Local Accounts

Accessing a resource using a local account is rarely a good idea but sometimes it is necessary (e.g. workgroup scenarios).  Local account authentications have been limited to using NTLM but that will change when a feature named LocalKDC becomes available.  LocalKDC will allow member servers to emulate a domain controller and begin supporting Kerberos for local accounts.  Like IAKerb, LocalKDC is not ready for primetime, but you can find components of it starting to show up in Windows Server 2025.

3.  Service Principal Name (SPN) issues

Kerberos Service Tickets are requested by specifying a Service Principal Name in the TSG-REQ.  In response the KDC will determine which account has that SPN then uses the account’s credential (AES key or NTLM hash depending on msds-SupportEncryptionTypes attribute) to encrypt the ticket.  Service Ticket requests can fail if:

• There are two accounts with the same SPN set (not unique)
• The SPN is not set on any account in the domain
• The client is connecting the resource by IP address instead of a DNS name

Since 2008 setspn has had the ability to prevent setting duplicate SPN which helps but setspn is not the only way a SPN can be set.  The good news is that you can easily determine if your domain has any duplicate SPNs by running setspn -x.  If any are discovered, you simply need to determine which account to remove the SPN from.

Identifying missing SPNs is not as easy but they can be detected using 4769 events when ticket request failures occur.  However, there is a catch.  Given the volume of SPN related issues can be very high, such errors are not logged unless the domain controller has the Kerberos event logging setting LogLevel set to 1.  Like other verbose logging, use caution when enabling it and when you are done with your assessment you will likely want to turn it back off.  On the bright side, enabling and disabling is effective immediately and does not require a reboot.

The same diagnostic logging setting can be used on the client side to capture the failure in its System log.  The event 3 logged on clients can be used to identify Kerberos failures beyond bad SPNs.

I would be remiss if I did not point out that a common reason for a missing SPN is load balancer VIP names and other uses of alias names.  If the account used for the loaded balanced solution is unique per target server, Kerberos is not going to be a supportable option.

By default, Windows will not attempt Kerberos if an IP address was used to access the resource.  As a result, 4769 events are not a dependable way to detect NTLM fallback due to IP address use.   The best solution to audit NTLM fallback due to IP address use the new 4020 events previously mentioned which are only supported on Windows 11 25H2 and Server 2025.

It is worth pointing out that Windows 10 / Server 2016 (and newer) supports configuring the TryIPSPN registry setting to override the default behavior of not requesting a service ticket for a SPN that uses an IP.  Of course, in order for such a request to be successful you would need to define the IP address as SPN on the account for the resource.

4.  Application is configured for NTLM

Telemetry data indicates that slightly more than half of all NTLM use is the result of application configuration.  In some cases it possible to reconfigure the application to use Negotiate which will result in Kerberos being selected over NTLM.  In other cases, the application is simply hardcoded to use NTLM which is going to require vendor / developer assistance to remediate.

This would be a good time to mention a few ways Windows natively defaults to NTLM which are:

• RPC Endpoint Mapper – Back in the Windows 95 days there was a concern that that unauthenticated calls related to RPC Endpoint Mapper (EPM) may be exploitable. As result the policy settings Enable RPC Endpoint Mapper Client Authentication and Restrict Unauthenticated RPC clients (Administrative Templates\System\Remote Procedure Call) were introduced which forces RPC EPM to authenticate with NTLM.  Nearly 30 years later the feared RPC mapper exploit never came to fruition, but many hardening baselines (e.g. CIS / STIG) still recommend enabling both settings.  As result there is a good chance an auditor is going to ding you for not enabling a policy that forces the use of NTLM.  If that happens, please explain to the auditor that disabling these settings does not allow RPC services to be accessed anonymously because each RPC service has its own security descriptor to restrict access.

• Loopback authentication -This occurs when the system account connects to itself for various services. To be clear, this type of connection never touches the network and often defaults to NTLM.  If you are auditing for inbound NTLM for all accounts (Network security: Restrict NTLM: Audit Incoming NTLM Traffic) these local connections can trigger 8001 events with the calling identity being the computer account or System.  If you configure the policy to block NTLM (NTLM server blocked: Incoming NTLM traffic to servers that are blocked), a 4002 event will be logged instead.  Configuring blocking for outbound NTLM does not appear impact loopback authentications.

 If you configure the inbound policy to block all accounts and start to log 4002 events like this one, there is a good chance it is due to loopback authentication for RPC EPM.  Disabling the RPC policies mentioned above prevents the inbound blocking policy from impacting those connections.

• MS-CHAPv2 – When a solution leverages CHAPv2 (RADIUS, 802.11x, NPS, etc) NTLM is not used in the traditional sense, but the password is hashed and used for a challenge/response credential validation with the domain controller. If the domain controller has been configured to block NTLM the MS-CHAPv2 authentication will be rejected (response error 0xc0000418) and a 4004 event will be logged on the domain controller.  Because MS-CHAPv2 is not a straight up NTLM authentication, disabling NTLM on the client will not break MS-CHAPv2.  However, enabling Credential Guard or adding the user to Protected Users Group will given the weak credential is no longer available.  If you are still using MS-CHAPv2 look for an alternative like EAP-TLS then flip your wall calendar forward to 2026.
• Print Spooler connections making bad SPN requests when using Named Pipes – This issue, referred to as a Print Nightmare Artifact, can result in NTLM fallback when the Kerberos AS-REQ for krbtgt/NT Authority fails. The preferred solution is to configure the Print Spooler to use RPC over TCP via the administrative template settings:

o   Printers\Configure RPC connection settings

o   Printers\Configure RPC listener settings

These settings were added to the Windows Security Baseline starting with Windows 11 22H2, but are supported on patched versions of Windows 10/11 and Windows Server 2016 or later. If RPC over Named Pipes is required, it may be necessary to configure HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\RPC\RpcNamedPipeAuthentication = 0x2 as explained in this Directory Services blog post.

• Performance Monitor remote connections – Ryan Ries recently wrote about this issue on his personal blog site. In it he explains Perfmon has an issue with formulating a valid SPN when making remote connections.  The good news is that his post explains a workaround to trick it into requesting a valid SPN.
• Domain Based DFS Namespace Referral for non-domain joined and 3^rd party devices – When accessing a domain based DFS share the client must first contact a domain controller in order to be redirected to a “root” server. Given that no object has a SPN for CIFS/CONTOSO.LOCAL it is not possible to request a service ticket for \\contoso.local\Data.  While you may see a domain joined Windows client perform a TSG-REQ for CIFS/CONTOSO.LOCAL, it will immediately fall back and request a CIFS ticket for a domain controller (CIFS/CONTOSO-DC1.CONTOSO.LOCAL).  Doing that will allow DFS referrals to continue to work even when the domain controller no longer supports NTLM.  Non domain joined Windows and 3^rd party devices accessing domain based DFS namespace do not know how to fall back when the TSG-REQ fails.  As a result, disabling NTLM on the domain controllers will most likely prevent them from accessing domain based DFS shares.

Let the blocking begin

 Once you have remediated NTLM dependencies you can begin implementing blocking policies where it is not required.  Like the auditing policies, the blocking settings are located in Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.

 

 

As you can see from the table it is possible to block NTLM on the client side (Outgoing NTLM traffic), on the server side (Incoming NTLM traffic) or on the domain controller (NTLM authentication in this domain). I suggest you break up the effort into small projects rather than taking a big bang approach.  Some ways to get started are:

• Place privileged administrator accounts in Protected User Group. Members of that group are prevented from using NTLM and don’t even retain the hash in LSASS.  This is a great way to target accounts separate from device configuration.  Just remember that service accounts and devices should not be added to Protected Users.  I recommend adding admin accounts to the group incrementally so you can find and address any compatibility issues before entire is impacted.
• Prioritize Tier 0 devices such as PAW and management servers when implementing outbound and inbound restrictions for NTLM. Given only highly privileged accounts should be logging on to them, it makes sense to address them first.
• Attempt to block NTLM on new application servers before they go into production. Taking that step might help catch configuration issues before it is too late.
• Target a small pilot group of endpoint devices for the first pass. Narrowing your focus in that manner will make it more manageable to collect and assess the data.  Additionally, it will minimize user interruption as you implement the restrictions.
• Consider enabling NTLM blocking on the SMB client if all outbound NTLM cannot be blocked but is not required for SMB connections. That restriction is currently only supported on Server 2025 and Windows 11 24H2 (and higher).  To be clear this restriction is only supported by the SMB client and not on the SMB server service.

There is a good chance you will discover a few key applications that are unable to support Kerberos.  Rather than allow them to sideline your project you can simply give them an exception until a long-term solution can be implemented.  Such exceptions can be created for outbound authentications and for the domain wide restrictions.  As the documentation explains, it is possible to utilize a wildcard when defining the exclusions.   Additionally, it is possible to use the SPN format when editing the policy as shown in this example.

As you begin blocking NTLM you will want to start collecting the blocking events mentioned in the table above so you are aware of functionality that may be impacted.  In addition to those events, make sure your support teams are aware of the following clues that NTLM is being blocked

• Failed SMB connections will often return the error “Network path not found” or “The operation being requested was not performed because the user has not been authenticated”
• Failed RPC connection will trigger the error “The RPC server is unavailable” (RPC_S_SERVER_UNAVAILABLE)
• Netlogon.log (if enabled) will log 0xC0000418 which corresponds to STATUS_INVALID_DOMAIN_STATE
• The user is repeatedly prompted for credentials
• 4625 events (failed logon) with SubStatus 0xC0000418

Hopefully this information will help jumpstart your project to begin disabling NTLM.  Here are a few final Do’s and Don’ts to keep in mind as you start your journey.

Don’t think you are powerless to address NTLM in your environment.  While total NTLM disablement in a domain is extremely challenging, there are plenty of incremental gains that will provide tangible benefits and get the process started.

Do invest in developing dashboards in your SIEM to make it possible to analyze NTLM authentications at scale.  If your SIEM does not have capacity to collect the NTLM events you could use Azure Log Analytics or Windows Event Forwarding (WEF) to get the data into a central location.

Do prioritize Tier 0 devices and accounts when assessing and blocking NTLM.

Don’t give up on Protected Users Group if you encounter issues.  The benefits for privileged accounts are considerable so to take the time to resolve problems rather than remove your admins from the group.

Do understand that processes running in Kernel Mode will be logged as the System account (PID 4).  The two processes you are most likely to encounter are SMB (client and server) and HTTP.sys.  For more information on SMB see this blog post by Ned.  When it comes to HTTP.sys keep in mind that we are not just talking about IIS but other services that leverages HTTP.sys like WinRM, Active Directory Web Services (ADWS), SQL Server Reporting Services (SSRS) and Remote Desktop Gateway.  To be clear these solutions do not require NTLM but if they fall back you will have to dig deeper to determine why the logs show the System account performing NTLM. 

Do upgrade your domain controllers to Server 2025.  Aside from the new NTLM events, 2025 has other enhanced auditing to help with enforcing SMB Signing and LDAP Channel Binding.  Those are all on top of the other new domain controller features introduced with 2025.

Don’t avoid deploying 2025 domain controllers because you haven’t enforced NTLMv2 yet.  While Server 2025 no longer supports requesting NTLMv1, 2025 domain controllers will still accept NTLMv1 when performing credential validation (same functionality as lmcompatibility =4).  For more information on the new enhanced NTLMv1 auditing on 2025 domain controllers check out this article.

Do be aware that vulnerability scanners sometime attempt to authenticate with NTLM just to probe how the device will respond.  It is not necessary an indication that NTLM is required for an authenticated scan.

Don’t prioritize disabling NTLM over addressing NTLMv1, SMBv1 and enforcing SMB signing.  You should address those more exploitable items first.

Do know that authentication over external trusts generally defaults to NTLM.  If you have any external trusts, you should consider changing them to forest trusts before imposing restriction on cross domain NTLM authentication.

Do send a message to ntlm@microsoft.com if you have worked through the remediations in this article and still have devices or application that are using NTLM.  We might not be able to give you individual assistance, but it will help identify items that still need work.

Do check out these other resources

• Windows IT Pro Blog - The evolution of Windows authentication
• YouTube Video - The Evolution of Windows Authentication
• Ask the Directory Services Team blog - NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7
• Microsoft Learn - Auditing and restricting NTLM usage guide
• Storage at Microsoft blog - SMB NTLM blocking now supported in Windows Insider
• Overview of NTLM auditing enhancements in Windows 11, version 24H2 and Windows Server 2025
• RunAsRadio - The End of NTLM with Steve Syfuhs (provides a deep dive on IAKerb and LocalKDC)