Microsoft transitions NTLM to Kerberos in Windows to boost security 

Windows authentication is a process that’s been around for decades. Unsurprisingly, attackers often target this authentication mechanism, preying upon weaknesses and vulnerabilities as they crop up. To help secure Windows authentication, Microsoft recently announced it was deprecating reliance on NT Lan Manager (NTLM) in Windows and further expanding Kerberos instead. So what changes are coming, and what do organizations need to consider now? 

What is NTLM (NT LAN Manager)? 

NTLMv2 has been around since Windows NT 4.0 SP2 and supported as part of the operating system since Windows 2000. It’s a challenge-response authentication protocol that relies on a three-way handshake to validate users. However, it’s known for being weak from a security standpoint since it does not support modern encryption algorithms like AES or SHA-256.  

NTLM (NT LAN Manager) vs Kerberos 

On the other hand, Kerberos is a much more secure authentication protocol and is recommended as the default by Microsoft. It uses a “ticketing” system to authenticate users to network resources, and, more importantly, it uses symmetric and asymmetric encryption, unlike NTLM. Kerberos also enables single sign-on (SSO), allowing end users to access many different resources without re-entering their user credentials. Aside from the security benefits, it also has greater performance than NTLM. 

Microsoft is showing NTLM the exit 

Due to its weak security implementations, Microsoft has recently announced that NTLM is being deprecated in favor of Kerberos authentication. The end goal of Microsoft is to completely turn off NTLM authentication across the board and bolster the Kerberos protocol, which they’re already doing in Windows 11.  

In the meantime, Microsoft aims to provide better tools to audit NTLM authentication. It will help IT teams gain more insights into NTLM usage in their organizations, identify which applications and clients may use it, and gain more control over removing it from the network. 

Despite this change most likely requiring the auditing and rewriting of legacy applications, the end result will be a more secure environment with much better security around authentication – plus the additional performance benefits provided by Kerberos. 

What improvements are coming to Kerberos 

Previously, Kerberos was lacking in a couple of areas that necessitated the use of NTLM. Microsoft has mentioned they are improving Kerberos to help eliminate the need for NTLM and make the transition smoother. When Kerberos authentication wasn’t possible in the past, clients fell back to using NTLM when they didn’t have line-of-sight access to a domain controller.  

Because of this, Microsoft is extending the Kerberos protocol to include a new public extension called IAKerb. It will allow clients that don’t have line-of-sight access to a DC to authenticate through another server that does. Servers will then be able to proxy Kerberos requests on behalf of clients. 

A local KDC in Windows 11 will add Kerberos support to local accounts. The new local KDC uses AES encryption out of the box to improve the security of local authentication. In addition, Microsoft is also removing hard-coded NTLM references in existing Windows components. 

What does this mean for organizations? 

Many organizations have developed or are using legacy hard-coded applications with NTLM authentication baked in. Businesses need to start auditing applications to discover those using NTLM. After this discovery phase, they can begin migrating to Kerberos to improve security and keep in line with the changes coming to Windows authentication. Microsoft suggests that organizations use existing policies and logs to identify where NTLM is being used and determine which applications may pose issues deactivating NTLM.  

Currently, in Active Directory Group Policy, there are a couple of settings you can enable, the Network security: Restrict NTLM: Audit NTLM authentication policy, and Network security: Restrict NTLM: Audit Incoming NTLM Traffic, under the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options node. Enabling this policy setting will create log entries related to NTLM use in the environment. In addition, other policies will allow the restriction of NTLM use altogether. These policy settings provide excellent tools for helping organizations get control of their NTLM use. 

Application developers also need to review code for any hardcoded NTLM implementations. Specifically, Microsoft calls out the use of the AcquireCredentialsHandle function with the string ntlm and recommends this be changed to negotiate instead. Additionally, replace instances of “RPC_C_AUTHN_DEFAULT” in calls to the RpcBindingSetAuthInfo function with “RPC_C_AUTHN_GSS_NEGOTIATE.”  

In the meantime, you can also consider the documentation from Microsoft on the use of NTLM in your environment.  

Specops uReset: We’re fully Kerberos ready 

Users directly interact with Windows authentication processes during logon and when changing passwords. For organizations looking to implement self-service password reset (SSPR) and enable end users to reset their Active Directory passwords securely, you’ll need a solution that works with Kerberos, like Specops uReset.

Specops uReset includes security features like multi-factor authentication (MFA), geo-blocking, and trusted network locations that help ease the burden on the helpdesk and bolster security. If you’re already using or considering Specops uReset to implement self-service password resets in your environment, rest assured it already supports the latest Kerberos features and will be fully compliant with changes coming from Microsoft. Learn how Specops uReset can fit in with your organization.