How to prepare for the demise of Windows NT LAN Manager

Older protocols are hard to kill. From consumer-based protocols like SMBv1 to network-based protocols like Windows NT LAN Manager (NTLM), we typically need time and planning to move off protocols that we rely on. Many of us are still using NTLM to authenticate to our networks especially for remote access during the pandemic. This old but well-used protocol was the default for network authentication in the Windows NT 4.0 operating system. It is less secure than more modern protocols such as Kerberos.

Why is NTLM a concern? Generally speaking, the older a protocol is the more likely it is to depend on older ciphers. NTML v1 uses the DES block cipher algorithm using an MD4 hash. It’s possible to break it by brute force mainly because a full 128-bit key is not used. NTLM v2 uses a stronger hash algorithm and encryption. Still, it can be exploited using pass-the-hash or man-in-the-middle techniques.

If possible, wean yourself off using NTLM. At a minimum, you should know exactly when and where NTLM is still being used in your network.

How to audit for NTLM use

First start by auditing networks to see if NTLM v1 is being used. To find applications that use NTLMv1, enable “Logon Success Auditing” on the domain controller and then look for “Success auditing Event 4624”, which contains information about the version of NTLM being used.

You’ll see many events and it might be difficult to find if NTLM is still being used. An easier means to determine if you can disable NTLM is to enable a setting to audit whether you can restrict it. To do this, set a group policy on your domain controller by editing your Group Policy management console:

• Go to “Forest”.
• Go to “Domains”.
• Browse to the “Default domain policy” and right-click on it.
• Select “Edit”.
• Scroll and select “Computer Configuration”.
• Select “Policies”.
• Select “Windows Settings”.
• Select “Security Settings”.
• Select “Local Policies”.
• Select “Security Options”.
• Select “Enable Network Security: Restrict NTLM: Audit NTLM authentication” in this domain.

Once the policy is active, the NTLM authentication requests are logged to the operational log located in “Application and Services”, then in “Microsoft”, then in “Windows” then in the NTLM log on every server where the Group Policy Object (GPO) is set.

Select the policies that just audits first rather than “Network Security: Incoming NTLM traffic”. This is supported on Server 2008 R2 and above. There are two policies. First, once you enable “Network Security: Restrict NTLM: Audit incoming NTLM Traffic”, select either “Enable auditing for domain accounts” or “Enable auditing for all accounts”.

Susan Bradley

Second, enable “Network security: Restrict NTLM: Audit NTLM authentication in this domain”. For this setting you can choose “Enable for domain accounts to domain servers”, “Enable for domain accounts”, “Enable for domain servers”, or “Enable all”.

Susan Bradley

Now go back to the operational logs and review what processes in your domain are using this protocol for authentication and access. You might find remote access processes are using NTLM because it doesn’t require a direct connection to the domain controller. Processes such as Remote Desktop Protocol (RDP) authenticating through a remote desktop gateway are apt to use NTLM as the means for passing along the authentication to the server.

Review if you can set the group policy of “Send NTLMv2 response Only/Refuse LM &NTLM” for “Network Security: LAN Manager Authentication”.

Disable NTLM when using Azure Active Directory

Microsoft recommends that you do not rely on NTLM once you use Azure for domain services. Microsoft recommends the following procedures to harden your Azure Active Directory (Azure AD) domain services:

• Disable NTLM v1 and TLS v1 ciphers.
• Disable NTLM password hash synchronization.
• Disable the ability to change passwords with RC4 encryption.
• Enable Kerberos armoring.

To perform these actions, sign into Azure AD Domain Services and choose your domain. On the left side, select “Security settings” and disable the following settings:

• TLS 1.2 only mode
• NTLM authentication
• NTLM password synchronization from on-premises
• RC4 encryption

Enable the “Kerberos armoring” setting.

Keep in mind that Azure AD is not the same thing as Active Directory (AD). It adds single sign-on to existing AD. Unless you are using Office 365 and nothing else, the authority for user identities still resides with AD. AD provides key functions to a domain such as storing information about users, computers, and groups or keeping track of objects such as organizational units, domains, and forests. It also provides common authentication providers for the domain as well as LDAP, NTLM, and Kerberos to ensure secure authentication between domain joined devices. Most importantly, AD allows fine-grained control and management of computers, users, and servers.

Azure AD provides Microsoft’s cloud-based identity and access management services and allows for access to Microsoft 365, Azure resources, and other software-as-a-service applications. Azure AD provides identity as a service for applications across different cloud services.

Inventory your network, both on-premises and cloud services, to determine the most secure authentication setting you can choose for your domain. Often with legacy applications the best you can do is NTLM. However, limit the use of NTLM v1 and know exactly where NTLM v2 is being used. Start planning now to move away from it and check with those applications and vendors that are still mandating NTLM.