NTLM
acronymStands for: NT LAN Manager
A legacy Microsoft challenge-response authentication protocol.
NT LAN Manager authenticates a user via a challenge-response exchange without sending the password. Still seen in Windows environments, it is weaker than Kerberos and a frequent relay-attack target. Microsoft's open specification MS-NLMP, at version 37.0 of 30 March 2026 on the day it was read, describes it as "a challenge-response style authentication protocol" in which "the server sends a challenge to the client. The client then sends back a response that is a function of the challenge, the user's password, and possibly other information." There are connection-oriented and connectionless variants, and "each of these variants has three versions: LM, NTLMv1, and NTLMv2", with the same message flow and different response functions. The three messages are NEGOTIATE, CHALLENGE and AUTHENTICATE, each beginning with the eight-byte signature NTLMSSP followed by a null, a MessageType (0x00000001 for NEGOTIATE), the NegotiateFlags, and offset-and-length fields pointing into a payload that carries the domain, workstation and, in the last message, the responses. Application protocols embed those messages, which is why NTLM appears inside HTTP, SMB and LDAP alike, and why disabling it is an inventory problem before it is a configuration one.
NTLM is the authentication protocol Windows used before Kerberos, and it survives because compatibility outlives design intent. It is a challenge-response scheme: the server sends a challenge, the client proves knowledge of the password hash without sending it, and no third party is consulted. Microsoft's own open specification, MS-NLMP, which on the day it was read stood at version 37.0 of 30 March 2026, puts the scope in one sentence: it "specifies the NT LAN Manager (NTLM) Authentication Protocol, used in Windows for authentication between clients and servers", and adds that "NTLM is used by application protocols to authenticate remote users and, optionally, to provide session security when requested by the application". That last clause is why NTLM is found inside so many other protocols: it is not a protocol you connect to but a sequence of messages that HTTP, SMB, LDAP and others carry in their own authentication headers.
The specification's overview describes the shape every version shares. NTLM "is a challenge-response style authentication protocol": "the server sends a challenge to the client. The client then sends back a response that is a function of the challenge, the user's password, and possibly other information." There are two variants, connection-oriented, in which a NEGOTIATE message from the client precedes the server's CHALLENGE and the client's AUTHENTICATE, and connectionless, which cannot send a NEGOTIATE_MESSAGE at all; and the document says that "each of these variants has three versions: LM, NTLMv1, and NTLMv2. The message flow for all three is the same; the only differences are the function used to compute various response fields from the challenge, and which response fields are set." LM is the LAN Manager response, NTLMv1 the first NT response and NTLMv2 the one still in use, and the first two are the ones a hardened domain refuses.
The messages themselves are plain structures, which is what makes NTLM easy to decode in a capture. The NEGOTIATE_MESSAGE of section 2.2.1.1 begins with a Signature, "an 8-byte character array that MUST contain the ASCII string ('N','T','L','M','S','S','P','\0')", followed by a MessageType of 0x00000001, the NegotiateFlags that advertise what the client supports, DomainNameFields and WorkstationFields, each a length, a maximum length and an offset into the payload, an optional Version structure present only when the NTLMSSP_NEGOTIATE_VERSION flag is set, and the Payload that the offsets point into. The CHALLENGE and AUTHENTICATE messages follow the same pattern with the server's challenge and the client's responses in place of the names. Anyone who has seen the string TlRMTVNTUAAB at the start of an HTTP Authorization header has seen a NEGOTIATE message: it is the Base64 of that signature and message type.
That last property, no third party consulted, is why it lingers. Kerberos needs a domain controller reachable at the moment of authentication; NTLM does not, so it remains the fallback when a machine connects by IP address rather than name, when the service principal name is missing or wrong, or when anything about the Kerberos path fails. Most surviving NTLM traffic in a modern domain is a Kerberos failure nobody diagnosed. Its weaknesses are structural rather than incidental. The password hash functions as the credential, so stealing it is as good as knowing the password, which is pass-the-hash. Relay attacks forward an authentication attempt to a different service, and the protocol offers no channel binding by default to stop them. The direction of travel is disabling it entirely, and the practical obstacle is always an inventory problem: finding what still depends on it before turning it off, which means auditing the authentication events on domain controllers and the application servers that still accept the NTLMSSP header. The NTLM article walks through the three messages and the versions, and the Active Directory and Kerberos entries describe the protocol that replaced it.
Also known as: ntlm, ntlmssp, ntlmv1, ntlmv2, lan manager authentication, ms-nlmp
Sources
- Microsoft NTLM documentation
- Microsoft Open Specifications, MS-NLMP, NT LAN Manager (NTLM) Authentication Protocol, version 37.0 of 30 March 2026 on the day read: the scope, the challenge-response overview, the connection-oriented and connectionless variants and the LM, NTLMv1 and NTLMv2 versions (read 2026-10-06)
- MS-NLMP section 2.2.1.1, NEGOTIATE_MESSAGE: the NTLMSSP signature, MessageType 0x00000001, NegotiateFlags, the domain and workstation fields, the optional Version and the Payload (read 2026-10-06)