Bidding Farewell to NTLM in favour of Kerberos

The NT LAN Manager (NTLM) is an authentication protocol encompassed in the Windows Msv1_0.dll. In this article, we shall discuss “Bidding Farewell to NTLM in favour of Kerberos”. The NTLM authentication protocols include LAN Manager versions 1 and 2, and NTLM versions 1 and 2. The NTLM authentication protocols authenticate users and computers based on a challenge/response mechanism that proves to a server or domain controller that a user knows the password associated with an account. Please see How to disable automatic Windows updates, and how to Clear Saved Email Address: How to stop Microsoft Edge from remembering your email ID.

At the time of writing this piece, NTLM authentication is still supported and must be used for Windows authentication with systems configured as a member of a workgroup. NTLM authentication can also be utilized for local logon authentication on non-domain controllers. Kerberos version 5 authentication is the preferred authentication method for Active Directory environments, but a non-Microsoft or Microsoft application might still use NTLM.

When NTLM protocol is utilized, a resource server must take one of the following actions to verify the identity of a PC or user whenever a new access token is required:

• Contact a domain authentication service on the domain controller for the computer’s or user’s account domain, if the account is a domain account.
• Look up the computer’s or user’s account in the local account database, if the account is a local account.

But Microsoft is shaking up the authentication game in its latest Windows 11 announcement. They’re saying goodbye to the old-timer “NTLM”, and embracing the Kerberos authentication protocol to its fullest.

It’s all in the name of amping up security and refining the user experience. Kindly take a look at the YouTube video from the Windows Authentication Platform team on Bidding Farewell to NTLM in favour of Kerberos.

NT LAN Manager (NTLM) – The End of an Era

NTLM, which debuted back in the ’90s. It offers a single sign-on magic with a sprinkle of challenge-response protocol. But as time went by, Kerberos took the centre stage since the entrance of Windows 2000.

Kerberos uses a two-step authentication process that leverages a ticket-granting service or key distribution centre. Want to read about “NTLM/Kerberos Authentication Extensions“?

With Kerberos, No more three-way handshakes between the client and server to authenticate a user as utilized in NTLM. Kerberos leverages encryption, while NTLM is still stuck in password-hashing.

Here is an excellent guide on how to Prevent NTLM credentials from being sent to remote servers. And Active Directory Authentication methods: How do Kerberos and NTLM work?

Security Makeover: Why the switch to Kerberos?

Outside NTLM’s security weaknesses. NTLM is vulnerable to relay attacks which enables intruders to eavesdrop on authentication attempts potentially allowing bad actors to gain unauthorized access to network resources. Kerberos promises a more secure, fortified authentication process.

Introducing IAKerb and KDC for Kerberos

As part of this grand transformation, Microsoft is introducing New features for Windows 11 including Initial and Pass Through Authentication Using Kerberos (IAKerb) and a local Key Distribution Center (KDC) for Kerberos thereby extending its superpowers of local accounts.

What’s Next for NTLM?

Now, you might be wondering, “What happens to NTLM?” Microsoft assures us that while they’re prepping for the grand farewell of NTLM in Windows 11, they’re also diligently addressing any hard-coded NTLM instances in its components in preparation for the shift to ultimately disable NTLM in Windows 11.

The aim is to enable users gently towards embracing Kerberos instead of holding on to NTLM.

Please see PetitPotam attack on Active Directory Certificate Services: How to mitigate NTLM Relay PetitPotam attack on AD CS, What to note when setting up Ansible to work with Kerberos, and Various Ansible Authentication Options.

Change Is Coming – Disable NTLM in Windows 11

Note: These changes are all set to be the new default, so no complex configurations are required for most situations. 

NTLM, though not as ostentatiously impressive as Kerberos, will still be hanging around as a fallback option as noted by Matthew Palko, Microsoft’s senior product management lead in Enterprise and Security, said. “NTLM will continue to be available as a fallback to maintain existing compatibility.

Reducing the use of NTLM will ultimately culminate in it being disabled in Windows 11. Microsoft is taking a data-driven approach and monitoring reductions in NTLM usage to determine when it will be safe to disable.

In the meantime, you can use the enhanced controls we are providing to get a head start. Once disabled by default, customers will also be able to use these controls to reenable NTLM for compatibility reasons

FAQ on NTLM and Kerberos?

The Core distinction between Kerberos and NTLM

The primary difference between NTLM and Kerberos is the need for connectivity to the domain controller. In Kerberos, the client must request a Kerberos ticket from the Key Distribution Center (KDC). Which is a process that resides on the domain controller. In NTLM, the server verifies the client’s NTLM credentials by contacting the domain controller.

This difference allows clients who do not have connectivity to the domain controller to authenticate with the server using NTLM authentication. This is the main reason for supporting NTLM in addition to the more secure and standard Kerberos authentication.

How would Kerberos resolve the above issue?

The “Initial and Pass Through Authentication Using Kerberos (IAKerb) and a local Key Distribution Center (KDC) for Kerberos” will be used to address these concerns.

IAKerb is a public extension to the industry standard Kerberos protocol that allows a client without line-of-sight to a Domain Controller to authenticate through a server that does have line-of-sight. This works through the Negotiate authentication extension and allows the Windows authentication stack to proxy Kerberos messages through the server on behalf of the client. IAKerb relies on the cryptographic security guarantees of Kerberos to protect the messages in transit through the server to prevent replay or relay attacks

The extensions to the Kerberos protocol and the GSS-API Kerberos mechanism enable a GSS-API Kerberos client to exchange messages with the KDC. It does this by using the GSS-API acceptor as a proxy, encapsulating the Kerberos messages inside GSS-API tokens.

With these extensions, a client can obtain Kerberos tickets for services where the KDC is not accessible to the client. But is accessible to the application server.

I hope you found this blog post helpful on Bidding Farewell to NTLM in favour of Kerberos. Please let me know in the comment session if you have any questions.