How NTLM works in Active Directory

Foreword

In this entry I would like to explain how NTLM works in an Active Directory environment. It's the counterpart to my article about how Kerberos works. Kerberos has been the default for more than 20 years, but NTLM is still in almost every domain I see. Before you can get rid of it, you have to understand what it does.

NTLM Authentication

All NTLM protocols use a challenge-response mechanism to authenticate users and computers. The user proves to the server that they know their account password, without sending the password over the network.

NTLM was introduced in 1993 with Windows NT 3.1 and replaced the older LM hash method, which had significant security flaws. NTLM had vulnerabilities as well, so Microsoft released NTLMv2 with Windows NT 4.0 SP4. From then on, the original version was called NTLMv1.

With Windows 2000, Kerberos became the default authentication protocol for Active Directory domains.

NTLM is still supported for backward compatibility, and you still see it in a lot of places. It's used with local accounts and in workgroups, when someone connects to a server by IP address instead of its name, and by older applications and devices that don't speak Kerberos.

NTLM doesn't have its own port. It travels inside the protocol you are using anyway, for example SMB, HTTP, LDAP or RPC.

The three messages

An NTLM authentication always consists of three messages between client and server. Microsoft calls them NEGOTIATE, CHALLENGE and AUTHENTICATE in the protocol specification. In older documentation and in Wireshark you also see them as Type 1, Type 2 and Type 3.

Let's take the user Lukas again. He sits at PC01 and opens a share on the file server SRV-FILE-01:

1. NEGOTIATE (client to server)

The client tells the server that it wants to authenticate with NTLM. The message contains a list of flags with the features the client supports, for example NTLMv2 and message signing. There is no username and no password in it yet.

The client only talks to the server. The domain controller doesn't know about this logon yet.

2. CHALLENGE (server to client)

The server answers with a challenge. This is a randomly generated 8-byte number, sometimes called a nonce. Because every logon gets a new random number, an attacker can't simply replay a response they captured earlier.

The message also contains target information: the name of the server and its domain, and on newer systems a timestamp.

3. AUTHENTICATE (client to server)

Now the client sends the username, the domain, the name of its own computer and the response. The client calculates the response from the challenge and the NT hash of the password. How exactly depends on the NTLM version, more about this below.

Newer clients also add a MIC (Message Integrity Code). It's an HMAC over all three messages, so nobody in between can change the messages without the server noticing.

The password never crosses the network, and neither does the NT hash. Whoever has the NT hash can still calculate a valid response for any challenge without knowing the password. That's what a pass-the-hash attack does.

4. Verification

Local Authentication

If the account is a local account on the server, the server takes the stored NT hash of the user from its local SAM (Security Account Manager) database. It calculates the response itself and compares it with the one from the client.

Domain-Based Authentication

For a domain account the server can't check the response. It doesn't know the NT hash of the user, only the domain controller does. So the server forwards the username, the challenge and the response to a domain controller. This is called pass-through authentication.

The server uses the Netlogon secure channel for this, the connection that the computer account of the server has to its domain. The domain controller takes the NT hash of the user from the Active Directory database, calculates the expected response and compares it with the one from the client.

If they match, the domain controller tells the server that the logon is valid. It also sends the SID of the user, the groups and a session key. With this information the server builds the access token for Lukas, and he gets access to the share.

This has two consequences. Every NTLM logon to a domain account needs a domain controller, while with Kerberos the server checks the ticket itself. And if the server has a broken secure channel to its domain, NTLM logons of domain users fail on that server.

How the response is calculated

The NT hash

The NT hash is the MD4 hash of the password. MD4 is fast and there is no salt. The same password therefore always gives the same NT hash, on every machine and in every domain.

NTLMv1

In NTLMv1 the client takes the 16 bytes of the NT hash, fills them up to 21 bytes and splits them into three DES keys with 7 bytes each. With each of these keys it encrypts the 8-byte challenge of the server. The three results together are the 24-byte response.

DES is old and the keys are short. Only the server adds randomness. And whoever captures an NTLMv1 response can recover the NT hash from it with a reasonable amount of effort. The NT hash is as good as the password.

NTLMv2

NTLMv2 does this in two steps and adds a second source of randomness from the client:

1. The client calculates the NTLMv2 hash. This is an HMAC-MD5 with the NT hash as key, over the username in capitals and the domain name.
2. The client builds a blob. It contains a timestamp, 8 random bytes of its own (the client challenge) and the target information from the CHALLENGE message.
3. The client calculates the NTProofStr. This is an HMAC-MD5 with the NTLMv2 hash as key, over the server challenge and the blob.

The response is the NTProofStr followed by the blob. The server, or the domain controller, does the same calculation and compares the result.

NTLMv2 is a lot better than NTLMv1. But someone who captures a complete NTLMv2 handshake can still try passwords offline. With a weak password that doesn't take long.

NTLMv1 and NTLMv2 compared

Which version a machine sends and accepts is controlled by the GPO setting "Network security: LAN Manager authentication level", in the registry LmCompatibilityLevel. Set it to "Send NTLMv2 response only. Refuse LM & NTLM" (level 5) on all machines, including the domain controllers. Then NTLMv1 is refused on both sides.

Why NTLM is a problem

• The server is never authenticated. The client proves who it is, the server doesn't. Kerberos authenticates both sides.
• Relay. The client calculates a response for every challenge it gets. Someone who sits between client and server can pass the challenge of a real server to the client and its response back to that server. Then they are logged on there as the client. SMB signing, LDAP signing with channel binding and Extended Protection for Authentication (EPA) on web servers break this. More about LDAP in my article about LDAP, LDAPS and Active Directory.
• Pass-the-hash. The NT hash is enough to log on. Whoever gets it from the memory or the disk of a machine doesn't need the password anymore.
• Offline cracking. NTLMv1 responses give away the NT hash, NTLMv2 responses can be used to guess the password.
• Old cryptography. MD4, HMAC-MD5 and with NTLMv1 also DES.

When Windows still uses NTLM

Applications normally don't ask for NTLM directly. They ask for Negotiate, and Negotiate tries Kerberos first. NTLM is the fallback when Kerberos doesn't work:

The most common reasons:

• An IP address instead of a name. Kerberos needs a Service Principal Name (SPN) for the target, and normally there is no SPN for an IP address. A script that maps \\10.0.0.5\share uses NTLM.
• A missing or duplicate SPN, for example when a service runs under a service account and nobody registered its SPN.
• Local accounts and workgroups. There is no domain controller that could issue a Kerberos ticket.
• No connection to a domain controller, for example because the VPN isn't up yet or the server is in a DMZ.
• Some older applications and appliances ask for NTLM directly.

To find out who still uses NTLM in your domain, you first have to collect the NTLM audit events from all machines and put them together. I built a tool for that: NTLM-Analyzer.

How to reduce NTLM

1. Audit first. Enable the "Restrict NTLM: Audit" policies on clients, servers and domain controllers. Event 4624 in the Security log also shows the NTLM version under "Package Name (NTLM only)".
2. Switch off NTLMv1 with LmCompatibilityLevel 5.
3. Fix the reasons for the fallback. Names instead of IP addresses, correct SPNs.
4. Protect against relay with SMB signing, LDAP signing and channel binding, and EPA.
5. Put admins into the Protected Users group. Members of this group can't authenticate with NTLM at all.
6. Enable Credential Guard. It protects the NT hashes in memory on the machine.
7. Restrict NTLM step by step. Clients and member servers first, domain controllers last.

Where Microsoft is going

• In June 2024 Microsoft declared all versions of NTLM, including LANMAN, NTLMv1 and NTLMv2, as deprecated. They are no longer under active feature development.
• NTLMv1 has been removed in Windows 11 24H2 and Windows Server 2025.
• From October 2026, Windows 11 24H2 and Server 2025 block NTLMv1-derived credentials for single sign-on by default (KB5066470). This affects for example MS-CHAPv2 for Wi-Fi and VPN.
• Microsoft has announced a plan in three phases. First better auditing, which is already available in Windows 11 24H2 and Server 2025. Then, in the second half of 2026, IAKerb and a local KDC, so Kerberos also works where NTLM was needed until now, for example for local accounts. And in the next major Windows Server release, network NTLM will be disabled by default.

Until then, the earlier you know where NTLM is still used in your domain, the less it hurts when Microsoft switches it off.