NTLM is a simple and straightforward authentication method for connecting to applications on enterprise servers, but it’s also outdated and insecure. Despite that, NLTM is still widely used, partly because of inertia but also because the preferred replacement Kerberos doesn’t currently cope with some important scenarios.
Now Microsoft plans to extend Kerberos in the versions of Windows and Windows Server that will ship in the next two years to help organizations move off NTLM. Here’s what will change and how to prepare.
Jump to:
What is NTLM?
NTLM is an authentication protocol that lets a client connect to a server with a username and password. It’s easy to implement and use, and it doesn’t need a connection to the domain controller or a central database of accounts and permissions.
The name gives away just how old NTLM is: The New Technology LAN Manager arrived in Windows NT 3.1 in 1993 – 30 years ago. Even the slightly more secure NTLM v2 dates back to Windows 2000.
What’s wrong with NTLM?
The NTLM username and password are encrypted, and the NTLM protocol makes sure the server checks that the username and password match. But although the response to the server is sent using fairly secure MD5 encryption, passwords are stored in the security account manager or NTDS file on the domain controller using much weaker MD4 cryptography, and password hashes aren’t salted (adding random data to passwords makes it harder to spot duplicate passwords).
There is no server authentication in NTLM, so the client can’t be sure it’s connecting to the server it expects rather than a malicious imitation. Plus, there have been bugs in the way Windows uses NTLM.
That all makes NTLM vulnerable to a range of attacks, from intercepting and reusing credentials to attack other servers (man-in-the-middle, relay and pass-the-hash attacks) to simply cracking passwords. Eight-character NTLM passwords, which is the standard in many organizations, can be brute forced in just three minutes using consumer-grade hardware. And NTLM doesn’t have the option to use modern credentials like biometrics, multifactor authentication or FIDO keys; you’re stuck with passwords.
Why is NTLM still used?
Kerberos, which has better cryptography and server authentication, lets you use those modern credentials like Windows Hello for Business, instead of sticking with passwords; officially, it should already be the primary authentication option in Windows.
However, despite its age, insecurity, design flaws and general poor performance compared to Kerberos, NTLM is still widely used, with trillions of authentication messages sent on Windows systems every day. Sometimes that’s because of legacy applications that haven’t been updated or just the complexity of dealing with Kerberos. But more often, it’s because there are common enterprise network situations that Kerberos doesn’t currently handle.
For years, Microsoft’s official guidance has been to use SPNEGO, an IETF-standard mechanism in Windows for negotiating what authentication protocol to use that’s often just called Negotiate and always tries to use Kerberos first – but that can still mean falling back to NTLM in some cases. For example, if you have workgroups with local user accounts, where the user is authenticated directly by the application server, Kerberos won’t work.
Local user accounts are very common in enterprises – many environments rely on them, like the Windows Local Administrator Password Solution for managing local administrator account passwords Microsoft shipped last year. In a recent online technical session, principal developer Steve Syfuhs from Microsoft’s Windows Cryptography, Identity and Authentication team said local users make up almost a third of all NTLM usage.
Other common issues are machine-to-machine authentication, like SMB or RDP and legacy domains.
With Kerberos, the client that’s connecting to an application server needs to be able to first connect to the Kerberos Key Distribution Center, a service that runs on the Active Directory domain controller. If you’re accessing an SMB server from outside the enterprise network, the firewall or the topology of a complex internal network may mean you can’t connect to the KDC and have to fall back to NTLM. VPNs don’t help here, because the VPN still needs to connect to the domain controller.
Similarly, although all the Remote Desktop services in Windows Server 2019 and above already support Kerberos, the way Remote Desktop Services is usually set up can also force it to fall back to NTLM. That’s because the quite sensible focus on securing remote access can mean the domain controller isn’t visible to RDS, so it can’t use Kerberos for authentication. Older RDP clients, especially on devices that aren’t running Windows, may also need to fall back to NTLM.
If you use Microsoft Entra ID, which Azure Active Directory is now called, that doesn’t use NTLM. But if you use Microsoft Entra Connect or Entra Connect cloud sync to access on-premises resources, and Kerberos can’t be negotiated because of network topology or a misconfiguration, you will be falling back to NTLM.
How is Microsoft extending Kerberos to fully replace NTLM?
This “line of sight” problem is only responsible for about 5% of NTLM usage, but Microsoft is introducing an extension to the Kerberos protocol called Initial and Pass Through Authentication Using Kerberos that will address it without organizations needing to reconfigure networks.
The client that wants to authenticate to the server application may not be able to reach the KDC on the network, but the server can because it needs to connect to the domain controller to do NTLM. IAKerb takes the Kerberos message that would normally go directly to the KDC over port 88, wraps it in the Negotiate protocol and sends it to the application server to forward to the KDC and then wraps the response in the same way and sends it back to the client.
IAKerb doesn’t help with local users, because when the application server does the authentication itself, it’s not written to hand that over to a backend service like KDC. But you can have the application server handle the Kerberos messages itself by running the KDC code that’s usually only on your domain controller running on other Windows Server systems (and Windows clients), using the local SAM and AeS encryption.
Microsoft calls this local KDC, and you don’t need to open new ports or worry about running DNS, netlogon or DCLocator to make it work.
Kerberos also fails with domains that are misconfigured, and around 14% of NLTM usage is, but that’s a problem you’ll have to solve yourself, not least because if you’re connecting to an unknown server, then you’re connecting to a server without knowing if you can trust it.
How can I get ready to move off NTLM?
Just over half of NTLM usage is for applications that hardcode in using NTLM. If you’ve done that in your own applications, you’ll need to update the application: There aren’t any shims or workarounds that Microsoft can do in Windows. But it turns out that some services in Windows, especially ones using RPC, also hardcode using NTLM: Microsoft will change those to use Negotiate instead, getting rid of a substantial amount of NTLM usage by default.
Both IAKerb and local KDC will be part of the Negotiate protocol inside Windows, so Windows will always try to use Kerberos first, relying on IAKerb as necessary. If that doesn’t work, it will fall back to the local KDC. If that doesn’t work either, NTLM will still be there as the ultimate fallback for compatibility – at least for this first phase.
If you’re already using Negotiate, you won’t need to make any changes to take advantage of IAKerb and local KDC when you upgrade to versions of Windows that include them. If you’re not using Negotiate, updating applications to use Negotiate instead of NTLM is relatively straightforward and doing that before the new features ship will show you whether you need to rely on them.
You may find systems that don’t work with Kerberos because they aren’t configured with Service Principal Names or that use IP addresses instead of DNS names. Kerberos doesn’t work with IP addresses by default because these are so likely to change over time, but you can already set a policy to allow IP addresses to be used for Kerberos.
If you find compatibility issues with IAKerb and local KDC in your environment, there will be policies to turn them off or configure which applications, services and individual servers can continue to use NTLM and which you want to block NTLM on.
In the long run, Microsoft wants to phase out NTLM completely, and that will include the password hashes currently stored in SAM and NTDS on the domain controller. But like the deprecation of SMB1 in Windows, you can expect this to take multiple years, with lots of warning and opportunities for feedback. As with SMB1, you can expect NTLM to move through stages of being deprecated, being disabled by default but with Group Policy to turn it back on, not being installed by default and finally being fully removed and only available as a feature on demand.
Find out where you’re using NTLM
Making authentication more secure in Windows starts with finding out where you use NTLM to prepare for shifting to Kerberos. This will be particularly important if you have non-Windows devices that authenticate to applications running on Windows Server or if you use open source software like Samba. Like Negotiate, IAKerb is being standardised through the IETF so other software vendors can work with it and with local KDC; but they may need time to add support and you need to know if that work is relevant to you because it could mean you will continue to see NTLM in your network.
In fact, tools and settings for blocking NTLM were introduced in Windows 7 and Windows Server 2008 R2 in 2012, but given how widely NTLM is used, few organizations will have been able to remove it entirely. You can use the Network Security: Restrict NTLM: Audit incoming NTLM traffic security policy (look in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options in Group Policy) to audit your NTLM use – make sure the event viewer logs are large enough because there’s probably enough traffic to fill them up more quickly than you expect.
Although you can turn on NTLM auditing in Group Policy now, Microsoft is extending the information that will be included to make it easier to tell which applications are using NTLM. At the moment, you get the process ID, but in the future, it will show the specific EXE that’s associated with it, because that may not be visible in the log.
Once you have the detailed information about which applications, services and servers are using NTLM, you can start creating granular policies to control that and gradually replace it with Kerberos.
When will the Kerberos extensions be available?
As usual, the changes will roll out in new versions of Windows 11 and Windows Server first in 2024 and 2025 respectively, and server applications like IIS will be updated to support IAKerb once the feature ships.
The option to block Windows from allowing NTLM authentication for SMB is also coming to Windows 11, starting with Windows 11 Insider Preview Build 25951, which shipped to the Canary channel this September.
Once those new releases come out, Microsoft may or may not backport these features to versions of the OS that are already shipping. It’s not clear whether IAKerb and Local KDC will come to Windows 10, due to the amount of work involved and the end of support for Windows 10 in 2025. Making major changes like this always runs the risk of compatibility issues for older applications.
That makes it even more important to take advantage of the NTLM auditing tools to discover how and where you’re using NTLM and how quickly you can move away from it.
