How to Disable NTLM Authentication in Windows Domain?

NTLM (NT LAN Manager) has been used as the basic Microsoft authentication protocol for quite a long time: since Windows NT. Although Microsoft introduced a more secure Kerberos authentication protocol in Windows 2000, the NTLM (generally, it is NTLMv2) is still widely used for authentication on Windows domain networks. In this article, we’ll consider how to disable NTLMv1 and NTLMv2 protocols and start using Kerberos in your Active Directory domain.

The main NTLMv1 problems:

• weak encryption;
• storing password hash in the memory of the LSA service that can be extracted using different tools (like mimikatz) and then the hash may be used for further attacks;
• the absence of mutual authentication between a server and a client that results in data interception attacks and unauthorized access to network resources (some tools such as Responder can capture NTLM data sent over the network and use them to access the network resources);
• and other vulnerabilities.

Some of them were fixed in the next version NTLMv2 which uses more secure encryption algorithms and allows to prevent popular NTLM attacks. NTLMv1 and LM authentification protocols are disabled by default starting with Windows 7 / Windows Server 2008 R2.

Configuring GPO to Force NTLMv2

If you have thought about stopping the use of NTLM in your domain, first of all, you must make sure that you are not using its more vulnerable version – NTLMv1. Your network may have a number of legacy devices or services that are still using NTLMv1 authentication instead of NTLMv2 (or Kerberos). So, prior to disabling it completely, read the NTLM authentication event audit section in this article.

First of all, the domain administrator needs to make sure that the NTLM and LM protocols are prohibited to be used for authentication in domain, since in some cases an attacker can use special requests to receive a response to an NTLM/LM request.

You can set the preffered authentication type using the domain (or local) policy. Open the Group Policy Management Editor (gpmc.msc) and edit the Default Domain Policy. Go to the GPO section Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options and find the policy Network Security: LAN Manager authentication level.

There are 6 options in the policy settings:

1. Send LM & NTLM responses;
2. Send LM & NTLM responses – use NTLMv2 session security if negotiated;
3. Send NTLM response only;
4. Send NTLMv2 response only;
5. Send NTLMv2 response only. Refuse LM;
6. Send NTLMv2 response only. Refuse LM& NTLM.

The policies of using NTLM authentication are given in the order of their security improvement. By default, Windows 7 and newer OSs use the option Send NTLMv2 response only. If this option is enabled, client computers use NTLMv2 authentication, but AD domain controllers accept LM, NTLM and NTLMv2 requests.

You can change the policy value to the most secure 6 option : “Send NTLMv2 response only. Refuse LM & NTLM”. If you configure this setting on a domain controllers, they will reject all LM and NTLMv1 requests.

You can also disable NTLMv1 through the registry. To do it, create a DWORD parameter with the name LmCompatibilityLevel and the value 0-5 in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa. Value 5 corresponds to the policy option “Send NTLMv2 response only. Refuse LM NTLM”.

Don’t forget to apply this policy to your domain controllers.

If you have made sure that you are not using NTLMv1, you can go further and try to disable the NTLMv2. NTLMv2 is a more secure authentication protocol, but it is much behind Kerberos in terms of security (although there are fewer vulnerabilities in NTLMv2 than in the NTLMv1, but there is still a chance of capturing and reusing data, as well as it doesn’t support mutual authentication).

The main risk of disabling NTLM is the potential usage of legacy or incorrectly configured applications that can still use NTLM authentication. In this case, you will have to update or configure them in a special way to switch to Kerberos.

How to Enable NTLM Authentication Audit Logging?

Before you can completely disable NTLM in your domain and switching to Kerberos, make sure that there are no apps left in the domain that require and use NTLM authentication.

To track accounts or apps that are using NTLM authentication, you can enable audit logging policies on all computers using GPO. In the Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options section, find and enable the Network Security: Restrict NTLM: Audit NTLM authentication in this domain policy and set its value to Enable all.

In the same way enable the policy Network Security: Restrict NTLM: Audit Incoming NTLM Traffic and set its value to Enable auditing for domain accounts.

After enabling these policies, the events of using NTLM authentication appear in the Application and Services Logs-> Microsoft -> Windows -> NTLM section of the Event Viewer.

You can analyze the events on each server or collect them to the central Windows Event Log Collector.

You need to search for the events from the source Microsoft-Windows-Security-Auditing with the Event ID 4624 – “An Account was successfully logged on“. Please note the information in the “Detailed Authentication Information” section. If there is NTLM in the Authentication Package value, than the NTLM protocol has been used to authenticate this user.

Look at the value of Package Name (NTLM only). This line shows, which protocol (LM, NTLMv1 or NTLMv2) has been used for authentication. Thus, you have to detect all servers/applications that are using the legacy protocol.

For example, to search for all NTLMv1 authentication events on all domain controllers, you can use the following PowerShell script:

$ADDCs = Get-ADDomainController -filter
$Now = Get-Date
$Yesterday = $Now.AddDays(-1)
$NewOutputFile = "c:\Events\$($Yesterday.ToString('yyyyddMM'))_AD_NTLMv1_events.log"
function GetEvents($DC){
Write-Host "Searching log on " $DC.HostName
$Events = Get-EventLog "Security" -After $Yesterday.Date -Before $Now.Date -ComputerName $DC.HostName -Message "*V1*" -instanceid 4624
foreach($Event in $Events){
Write-Host $DC.HostName $Event.EventID $Event.TimeGenerated
Out-File -FilePath $NewOutputFile -InputObject "$($Event.EventID), $($Event.MachineName), $($Event.TimeGenerated), $($Event.ReplacementStrings),($Event.message)" -Append
}
}
foreach($DC in $ADDCs){GetEvents($DC)}

After you have found users and applications that are using NTLM in your domain, try switching them to using Kerberos (possibly using SPN). Some applications require to be slightly reconfigured to use Kerberos authentication (see the articles Kerberos Authentication in IIS, How to configure different browsers for Kerberos authentication?). From my own experience, I see that even large commercial products are still using NTLM instead of Kerberos, some products require updates or configuration changes. It is all about detecting what apps are using NTLM authentication, and now you have the relevant method to identify this software and devices.

Those apps that cannot use Kerberos may be added to the exceptions. This will allow them to use NTLM authentication, even if it is disabled at the domain level. To do it, the Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain policy is used. Add the names of the servers, on which NTLM authentication can be used, to the list of exceptions as well. Ideally, this exception list should be empty. You can use the wildcard *.

How to Completely Restrict NTLM in Active Directory Domain?

To check how the authentication without NTLM will work for different apps in your domain, you can add user accounts to the “Protected Users” domain group (it is available since Windows Server 2012 R2). Members of this security group can authenticate only using Kerberos (NTLM, Digest Authentication or CredSSP are not allowed). Thus, you can verify if Kerberos user authentication works correctly in different apps.

Then you can completely disable NTLM on the Active Directory domain using the Network Security: Restrict NTLM: NTLM authentication in this domain policy.

The policy has 5 options:

• Disable: the policy is disabled (NTLM authentication is allowed in the domain);
• Deny for domain accounts to domain servers: the domain controllers deny NTLM authentication attempts for all servers under the domain accounts, and the “NTLM is blocked” error appears;
• Deny for domain accounts: the domain controllers prevent NTLM authentication attempts for all domain accounts, and the “NTLM is blocked” error appears;
• Deny for domain servers: NTLM authentication requests are forbidden for all servers unless the server name is on the exception list in the “Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain” policy;
• Deny all: the domain controllers block all NTLM requests for all domain servers and accounts.

To further improve the Active Directory security, I recommend to read these articles: Mitigations against Mimikatz Style Attacks, Securing of Priveleged Administrator Accounts, How to Disable LLMNR and NetBIOS over TCP/IP.