Prepare for the disappearance of Windows NT LAN Manager
Windows NT LAN Manager or NTLM is a protocol that has become insecure for authenticating access to the Windows network. The following steps explain how to start the migration to another protocol or to limit its use.
Old protocols are difficult to remove. Whether it’s consumer protocols like Server Message Block (SMBv1) or network protocols like Windows NT LAN Manager (NTLM), it usually takes time and a bit of planning to move away from previously trusted protocols. . Many still use NTLM to authenticate to their networks, and this has been especially true for remote access during the Covid-19 pandemic. This old, but well-used protocol was used as the default network authentication in the Windows NT 4.0 operating system. But it is less secure than more modern protocols like Kerberos.
Why is Windows NTLM a problem today?
In general, the older a protocol, the more likely it is to depend on older ciphers. NTML v1 uses the DES block cipher algorithm with an MD4 hash. It is possible to break it by brute force, mainly because it does not use a full 128-bit key. NTLM v2 uses a stronger hashing algorithm and encryption. It can nevertheless be exploited by techniques of the “pass-the-hash” or “man-in-the-middle” type. Therefore, it has become preferable to do without NTLM. At a minimum, it is important to know exactly when and where the NTLM is still being used on the network.
Audit the use of NT Lan Manager
To see if NTLM v1 is used, you have to perform an audit of your networks. By activating “Audit connection events” on the domain controller it is possible to find the applications which use the NTLMv1. Then, by searching for “Search for successful events ID 4624”, you can get information on the NTLM version used.
This research brings up many events and it can be difficult to find if the NTLM is still in use. An easier way to determine if disabling NTLM is possible is to enable a setting to see if it can be restricted. To do this, you must define a group policy on your domain controller by editing the group policy management console:
– Go to “Forest”.
– Go to “Domains”.
– Navigate to “Default domain policy” and click on it with the right mouse button.
– Select “Edit”.
– Scroll down and select “Computer configuration”.
– Select “Policies”.
– Select “Windows settings”.
– Select “Security parameters”.
– Select “Local policies”.
– Select “Security options”.
– Select “Network security: Restrict NTLM: Audit NTLM authentication in this domain.
Once the policy is active, NTLM authentication requests are recorded in the organization log located in “Application and Services”, then in “Microsoft”, then in “Windows”, then in the NTLM log on each server where the Group Policy Object (GPO) is defined.
First select policies that only audit rather than “Network Security: Incoming NTLM Traffic”. This feature is supported on Server 2008 R2 and above. There are two policies. First, after “Network Security: Restrict NTLM: Audit incoming NTLM traffic” is enabled, select “Enable auditing for domain accounts” or “Enable auditing for all accounts”.
Enable auditing for all accounts. (Credit: Susan Bradley)
Then activate “Network security: Restrict NTLM: audit NTLM authentication in this domain”. For this setting, you can choose “Activate domain accounts to domain servers”, “Activate for domain accounts”, “Activate for domain servers” or Activate all “.
Audit of NTLM authentication on domain servers. (Credit: Susan Bradley)
Now go back to the organization logs and examine which processes in your domain use this protocol for authentication and access. You may find that the remote access processes use the NTLM because they do not require a direct connection to the domain controller. Processes like Remote Desktop Protocol (RDP) that authenticate through a Remote Desktop Gateway are likely to use NTLM to pass authentication to the server.
Check whether you can set the Group Policy “Send NTLMv2 responses only.” Refuse LM & NTLM ”for“ Network security: LAN Manager authentication level ”.
Disable NTLM when using Azure Active Directory
Microsoft recommends that you do not rely on NTLM when using Azure for domain services. Microsoft recommends the following procedures to strengthen its 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.
– Activate Kerberos armoring or “Kerberos armoring”.
To perform these actions, sign in to Azure AD domain services and choose your domain. On the left side, select “Security settings” and disable the following settings:
– TLS 1.2 mode only
– NTLM authentication
– NTLM password synchronization from on-site installation
– RC4 encryption
Enable Kerberos security
Remember that Azure AD is different from Active Directory (AD). It adds single sign-on to the existing AD. Unless you’re using Office 365 and nothing else, the authority for user identities still resides in AD. AD provides key functions to a domain, such as storing information about users, computers, and groups, or tracking 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. More importantly, AD enables fine control and management of computers, users and servers.
Azure AD provides Microsoft’s cloud-based identity and access management services and enables 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. By taking an inventory of your network, whether it’s on-premises or in the cloud, you can determine the most secure authentication setting for your domain. Often times, with older applications, NTLM is the best that can be done. However, it is best to limit the use of NTLM v1 and know exactly where NTLM v2 is used. No need to wait to plan to abandon this setting. It is also necessary to verify which applications and which providers continue to use Windows NT LAN Manager.