How to disable NTLM authentication in Windows domain? , Ranjan.info

ntlm (NT LAN Manager) is a legacy Microsoft authentication protocol dating back to Windows NT. Although Microsoft introduced a more secure kerberos Authentication protocols dating back to Windows 2000, NTLM (mostly NTLMv2) are still widely used for authentication on Windows domain networks. In this article, we’ll look at how to disable the NTLMv1 and NTLMv2 protocols, and how to switch to Kerberos in an Active Directory domain.

Key ntlmv1 Problem:

• weak encryption;
• storing password hashes in the memory of the LSA service, which can be extracted from Windows memory in plain text using various tools (such as Mimikatz) and used for further attacks using pass-the-scripts;
• lack of mutual authentication between server and client, leading to data interception and unauthorized access to resources (some tools such as Responder can capture NTLM data sent over the network and use them to access network resources) ;
• and other vulnerabilities.

some of these are in the next version ntlmv2 Which uses more secure encryption algorithms and allows preventing common NTLM attacks. The NTLMv1 and LM authentication protocols are disabled by default with Windows 7 and Windows Server 2008 R2.

How to enable NTLM authentication audit logging?

Before completely disabling NTLM in a domain and switching to Kerberos, it’s a good idea to make sure there are no applications in the domain that require and use NTLM auth. You may have legacy devices or services on your network that still use NTLMv1 authentication instead of NTLMv2 (or Kerberos).

To track accounts or apps that use NTLM authentication, you can enable audit logging policies on all computers that use the GPO. open Default Domain Controller PolicyNavigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options section, find and enable Network Security: Restrict NTLM: Audit NTLM authentication in this domain Determine the policy and its value enable all.

Similarly, enable the following policies in the Default Domain Policy:

• Network Security: Restrict NTLM: Audit incoming NTLM traffic – set its value Enable auditing for domain accounts
• Network Security: Restrict NTLM: Outgoing NTLM traffic on remote servers: set audit all

After these policies are enabled, events related to the use of NTLM authentication will appear in Applications and Services Logs -> Microsoft -> Windows -> NTLM section of event viewer.

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

You need to find the event from source Microsoft-Windows-Security-Auditing with Event ID 4624 ,An Account was successfully logged onNote the information in “. “Detailed Authentication Information” section. If there was ntlm In certification package value, then the NTLM protocol was used to authenticate this user.

see the value of package name (NTLM only), This line shows which protocol (LM, NTLMv1, or NTLMv2) was used for authentication. Therefore you need to identify any servers/applications that use the old protocol.

Additionally, if NTLM is used instead of Kerberos for authentication, the event ID 4776 Will appear in the log:

The computer attempted to validate the credentials for an account
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

For example, to find 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 "*NTLM 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)}

Once you’ve identified the users and applications in your domain that use NTLM, try switching them to use Kerberos (possibly using an SPN). In order to use Kerberos authentication, some applications require a bit of reconfiguration (Kerberos authentication in IIS, Configure various browsers for Kerberos authentication, Create a Keytab file using Kerberos Auth). From my own experience, I see that with large commercial products still using NTLM instead of Kerberos, some products require updates or configuration changes. The idea is to identify which applications use NTLM authentication, and now you have a way to identify that software and devices.

Small open-source products, older models of various network scanners (which store scans in shared network folders), some NAS devices, and other older hardware, legacy software, and operating systems are prone to authentication problems when NTLMv1 is disabled Is.

Apps that cannot use Kerberos can be added to exceptions. This allows them to use NTLM authentication even when it is disabled at the domain level. To do this, Network Security: Restrict NTLM: Add server exception for NTLM authentication in this domain policy is used. Also add the server names (NetBIOS names, IP addresses, or FQDNs) on which NTLM authentication can be used to the list of exceptions. Ideally, this exception list should be empty. You can use wildcard character *,

To use Kerberos authentication in an application, you must specify the DNS name of the server instead of its IP address. If you specify an IP address when connecting to your resources, NTLM authentication will be used.

Configuring Active Directory to force NTLMv2 via GPO

Before completely disabling NTLM in an AD domain, it is recommended that you first disable its more insecure version, ntlmv1, Domain administrators need to ensure that their network does not allow the use of NTLM or LM for authentication, as in some cases an attacker can use special requests to obtain a response to an NTLM/LM request.

You can set the preferred authentication type using a Domain GPO. Open the Group Policy Management Editor (gpmc.msc) and edit the Default Domain Controllers policy. Go to GPO section Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options Find more policy Network Security: LAN Manager Authentication Level,

Policy Settings has 6 options to choose from::

• send lm and ntlm responses;
• send LM and NTLM responses – use NTLMv2 session security when negotiated;
• send only NTLM responses;
• send only NTLMv2 responses;
• Send only NTLMv2 responses. refuse lm;
• Send only NTLMv2 responses. Refuse LM and NTLM.

NTLM authentication options are listed in order of their security improvement. By default, Windows 7 and later operating systems 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 safest option 6 ,Send only NTLMv2 responses. deny lm and ntlm, This policy causes domain controllers to reject LM and NTLM requests as well.

You can also disable NTLMv1 through the registry. To do this, create a DWORD parameter with the name lm compatibility level Registry key with a value between 0 and 5 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, The value 5 corresponds to the “Send NTLMv2 responses only” policy option. Refuse lm ntlm”.

Once you’re sure you’re not using NTLMv1, you can go ahead and try disabling NTLMv2. ntlmv2 is a more secure authentication protocol, but loses significantly to Kerberos in terms of security (although NTLMv2 has fewer vulnerabilities than NTLMv1, but there is still a chance of data capture and reuse, with only it does not support mutual authentication).

The main risk of disabling NTLM is the potential use of legacy or misconfigured applications that are still using NTLM authentication. If this is the case, they will need to be updated or specially configured to switch to Kerberos.

Ban NTLM altogether and use Kerberos authentication in AD

To test how authentication works in different applications in a domain without using NTLM, you can add the required users’ accounts to protected user Domain Groups (this is available since the Windows Server 2012 R2 release). Members of this security group can only authenticate using Kerberos (NTLM, Digest Authentication, or CredSSP are not allowed). This allows you to verify that Kerberos user authentication is working properly in various apps.

Then you can completely disable NTLM on the Active Directory domain Network Security: Restrict NTLM: NTLM Authentication in this domain Policy.

The policy has 5 options:

• Disabling: The policy is disabled (NTLM authentication is allowed in the domain);
• Deny domain accounts for domain servers: Domain controllers reject NTLM authentication attempts for all servers under domain accounts, and the “NTLM is blocked” error message is displayed;
• Deny for domain accounts: Domain controllers are blocking NTLM authentication attempts for all domain accounts, and the error “NTLM is blocked” appears;
• Deny for domain server: NTLM authentication requests are denied for all servers unless the server name is in the exceptions list in the “Network Security: Prohibit NTLM: Add server exceptions for NTLM authentication in this domain” policy;
• Reject All: Domain controllers block all NTLM requests for all domain servers and accounts.

Although NTLM is now disabled on the domain, it is still used to process local logins to computers (NTLM has always been used for local user logons).

You can also disable incoming and outgoing NTLM traffic on domain computers separately by using default domain policy Option:

• Network Security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts
• Network Security: Restrict NTLM: Outgoing NTLM traffic on remote servers = reject all

After enabling auditing, the Event Viewer will also display the EventID 6038 From the LsaSRV source when using NTLM for authentication:

Microsoft Windows Server has detected that NTLM authentication is presently being used between clients and this server. This event occurs once per boot of the server on the first time a client uses NTLM with this server.
NTLM is a weaker authentication mechanism. Please check:
Which applications are using NTLM authentication?
Are there configuration issues preventing the use of stronger authentication such as Kerberos authentication?
If NTLM must be supported, is Extended Protection configured?

You can check that Kerberos is used for user authentication with the command:

klist sessions

This command shows that all users are Kerberos-authenticated (except the built-in local administrator, which is always authenticated using NTLM).

To further improve Active Directory security, I recommend reading these articles: