# NTLM explained: three messages, three versions, and why it is still on your network > What NT LAN Manager actually is, from Microsoft's own specification: a challenge-response carried inside other protocols, in NEGOTIATE, CHALLENGE and AUTHENTICATE messages that begin with the signature NTLMSSP; the connection-oriented and connectionless variants; the LM, NTLMv1 and NTLMv2 versions that share one flow and differ in the response function; how to recognise it in an HTTP header; why it survives wherever Kerberos cannot reach; what pass-the-hash and relay mean for it; and how to find what still depends on it before turning it off. Source: https://ronutz.com/en/learn/ntlm-explained Updated: 2026-10-06 --- ## A protocol you never connect to NTLM is not something a client opens a connection to. It is a sequence of messages that other protocols carry in their own authentication slots: an HTTP Authorization header, an SMB session setup, an LDAP (Lightweight Directory Access Protocol) bind. Microsoft's open specification, MS-NLMP, which on the day it was read stood at version 37.0 of 30 March 2026, defines its 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". Microsoft's Windows Server overview places it in the operating system: "NTLM authentication is a family of authentication protocols that are encompassed in the Windows Msv1_0.dll. The NTLM authentication protocols include LAN Manager version 1 and 2, and NTLM version 1 and 2." ## The shape every version shares The overview section of MS-NLMP describes the mechanism: NTLM "is 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." Nothing containing the password crosses the wire; what crosses is a value that only a holder of the password, or of the hash derived from it, could have computed, and the server, or the domain controller it consults, computes the same value and compares. No ticket is issued and no third party need be reachable at the moment of authentication, which is both NTLM's weakness and the reason it is still here. The specification defines two variants. The connection-oriented variant has three messages: the client sends a NEGOTIATE_MESSAGE announcing what it supports, the server replies with a CHALLENGE_MESSAGE carrying the challenge, and the client sends an AUTHENTICATE_MESSAGE carrying the responses. The connectionless variant, used where there is no prior exchange to carry the first message, "cannot send a NEGOTIATE_MESSAGE" and starts at the challenge. And across both, MS-NLMP says, "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; the first two are what a hardened domain is configured to refuse. ## The messages, byte by byte The messages are plain structures, which is why NTLM is easy to recognise in a capture and why a decoder for it is a small program. Section 2.2.1.1 of MS-NLMP defines the NEGOTIATE_MESSAGE as: a Signature, "an 8-byte character array that MUST contain the ASCII string ('N','T','L','M','S','S','P','\0')"; a MessageType of 0x00000001; the NegotiateFlags, a 32-bit field in which the client advertises the features it supports; DomainNameFields and WorkstationFields, each a length, a maximum length and an offset into the message's payload; a Version structure, present only when the NTLMSSP_NEGOTIATE_VERSION flag is set; and the Payload, the variable-length area the offsets point into. The CHALLENGE_MESSAGE and AUTHENTICATE_MESSAGE follow the same pattern, with the server's challenge and the client's LM and NT responses in place of the names, and the AUTHENTICATE_MESSAGE is where the version shows, since it is the response fields that differ. The practical consequence is a signature anyone can learn to spot. An HTTP client authenticating with NTLM sends an Authorization header whose value begins with the Base64 of the first bytes of a NEGOTIATE_MESSAGE, and the Base64 of the signature NTLMSSP, its terminating null and the message type 1 is TlRMTVNTUAAB. A header beginning with those twelve characters is an NTLM negotiation; one beginning with TlRMTVNTUAAC is the server's challenge and TlRMTVNTUAAD the client's authenticate, by the same arithmetic on message types 2 and 3. SMB and LDAP carry the same structures in their own framing. ## Why it is still on the network Microsoft's overview is explicit about the preferred alternative and the remaining uses. "Kerberos version 5 authentication is the preferred authentication method for Active Directory environments, but a non-Microsoft or Microsoft application might still use NTLM." And: "NTLM authentication is still supported and must be used for Windows authentication with systems configured as a member of a workgroup. NTLM authentication is also used for local logon authentication on non-domain controllers." Kerberos needs a domain controller reachable at the moment of authentication and a service principal name registered for the thing being reached; NTLM needs neither. So NTLM is what happens when a machine connects to a server by IP address rather than name, when the service principal name is missing or duplicated, when a client is not domain-joined, when an application was written to ask for it, or when anything in the Kerberos path fails. Most of the NTLM traffic in a modern domain is a Kerberos failure nobody has diagnosed, which is good news in one sense: fixing the failure removes the traffic. ## What the weaknesses are Two structural problems follow from the design, and both are familiar to anyone who has read an incident report. The password hash functions as the credential. The response is a function of the challenge and the hash, so a party who holds the hash can compute responses without ever knowing the password; stealing the hash from a machine's memory or a credential store is as good as stealing the password, which is pass-the-hash. And an authentication can be relayed. Because the response is computed for a challenge and the challenge can come from anyone the client is willing to talk to, an attacker positioned between a client and a server can take the client's authentication and present it to a different service, and the protocol offers no channel binding by default to stop that. Neither weakness is a bug in an implementation; both are properties of a challenge-response designed before relay attacks were in anyone's threat model, and both are why the direction of travel for every domain is to restrict NTLM and then remove it. ## Finding it before turning it off The obstacle to removal is never the switch; it is knowing what will break. Microsoft's overview points to the tooling: "New tools and settings have been added to help you discover how NTLM is used in order to selectively restrict NTLM traffic." The method is the one the overview implies. Audit NTLM authentication events on domain controllers and member servers first, for months rather than days, because some dependents authenticate quarterly. For each source, find the reason: an IP-address connection string, a missing service principal name, a non-joined device, an application that hard-codes the method. Fix the reasons that are Kerberos failures, which removes most of the volume at no cost to anyone. Then restrict NTLM with exceptions for the dependents that remain, and shrink the exception list on a schedule. The companion article on Kerberos and SPNEGO describes the protocol that should be answering instead, and the short list of ways it breaks is the same list that generates NTLM fallbacks. ## Where NTLM meets the rest of this series The MS-CHAP-V2 challenge-response that PEAP carries over Wi-Fi is a relative of NTLM's, computed from the same NT hash of the password, which is why a RADIUS (Remote Authentication Dial-In User Service) server can verify PEAP-MSCHAPv2 logins against a domain and why the directory must hold that hash; the 802.1X article covers the method and its tunnel. Active Directory holds the hashes, issues the Kerberos tickets that are supposed to replace NTLM, and answers the LDAP queries that map a login to a person; its entry and the LDAP fundamentals article carry that side. ## Sources - [Microsoft Open Specifications, MS-NLMP, NT LAN Manager (NTLM) Authentication Protocol, version 37.0 of 30 March 2026: the scope statement and the overview of the challenge-response, the connection-oriented and connectionless variants, the LM, NTLMv1 and NTLMv2 versions (read 2026-10-06)](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4) - [MS-NLMP, section 2.2.1.1 NEGOTIATE_MESSAGE: the Signature, MessageType, NegotiateFlags, the domain and workstation fields, the Version structure and the Payload (read 2026-10-06)](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b34032e5-3aae-4bc6-84c3-c6d80eadf7f2) - [Microsoft Learn, NTLM Overview (Windows Server): the Msv1_0.dll family, workgroup and local logon uses, Kerberos as the preferred method, the tools for discovering and restricting NTLM (read 2026-10-06)](https://learn.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview) - [RFC 2759, Microsoft PPP CHAP Extensions, Version 2, Zorn, January 2000: the MS-CHAP-V2 response computed from an MD4 hash of the password, the relative that PEAP carries (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc2759)