NTLM
NTLM, or NT LAN Manager, is a suite of challenge-response authentication protocols developed by Microsoft for use in Windows operating systems and networks, providing mechanisms for user and computer authentication, message integrity, and session confidentiality without transmitting passwords in clear text.[1] It authenticates clients to servers by having the server issue a random challenge, which the client encrypts using a hash of the user's password, allowing verification against a domain controller or local account database.[2] Originally introduced with Windows NT, NTLM has evolved through multiple versions but remains a legacy protocol, with Kerberos preferred for modern Active Directory environments due to its stronger security features.[3]
The protocol family includes earlier variants like LAN Manager (LM) v1 and v2, which used weaker DES-based encryption, and the more secure NTLM v1 and v2, with NTLMv2 incorporating enhanced hashing and mutual authentication to mitigate vulnerabilities such as pass-the-hash attacks.[2] NTLM operates within the Security Support Provider Interface (SSPI) framework, implemented via the MSV1_0.dll library, and is invoked when applications request the "Negotiate" package, which falls back to NTLM if Kerberos fails.[3] It supports both local logons on standalone systems and network authentication in workgroups or domains, particularly for legacy or non-Microsoft applications that do not support Kerberos.[2]
Despite its widespread historical use, NTLM has known security weaknesses, including susceptibility to offline cracking and relay attacks, prompting Microsoft to recommend auditing and restricting its usage through tools like NTLM audit policies and Extended Protection for Authentication.[2] In recent developments, Microsoft has deprecated NTLM, with NTLMv1 fully removed in Windows 11 version 24H2 and Windows Server 2025, while NTLMv2 is no longer under active development but continues to function for backward compatibility.[4] Administrators are encouraged to transition to Kerberos or other modern protocols to enhance security, with ongoing support for NTLM limited to essential legacy scenarios.[5]
Overview
Introduction
NTLM, or NT LAN Manager, is a suite of challenge-response authentication protocols developed by Microsoft for securing communications within Windows-based networks. It enables the authentication of users and computers without transmitting passwords directly over the network, instead relying on encrypted responses to server-generated challenges derived from password hashes.[1] As a security package, NTLM provides core functions of authentication to verify identities, integrity to ensure data has not been tampered with, and confidentiality through optional session encryption.[1]
In Microsoft ecosystems, NTLM plays a key role in facilitating secure access to resources, particularly in workgroup scenarios or on non-domain-joined systems where more modern protocols like Kerberos may not apply. It is commonly integrated with protocols such as Server Message Block (SMB) for file sharing, Remote Procedure Call (RPC) for distributed services, and HTTP for web-based authentication, allowing seamless verification in heterogeneous or legacy setups.[2] This integration supports remote user logons and protects network communications in environments like local area networks.[1]
Originating as an enhancement to the earlier LAN Manager authentication system, NTLM has evolved into versions including NTLMv1 and NTLMv2 to address security limitations. As of November 2025, it is a deprecated legacy protocol, with NTLMv1 removed in Windows 11 version 24H2 and Windows Server 2025, and NTLMv2 no longer under active development but functional for backward compatibility.[2][4] Despite recommendations to minimize its use in favor of Kerberos, NTLM continues to authenticate in specific legacy contexts.[2]
History and Development
The NTLM authentication protocol originated from the LAN Manager (LM) authentication mechanism developed by Microsoft in the late 1980s. LAN Manager, released in version 1.0 in 1987, was designed to provide network authentication for MS-DOS and OS/2-based systems using the Server Message Block (SMB) protocol over NetBEUI.[6] This early protocol relied on weak challenge-response methods to secure file sharing and printer access in local area networks, but its design prioritized compatibility over robust security.[7]
Microsoft introduced NTLM with the release of Windows NT 3.1 in July 1993, positioning it as a significant upgrade to address the vulnerabilities in LM hashing, such as the use of a simplified DES-based encryption that limited passwords to 14 characters and upper-case only, making them susceptible to brute-force attacks.[8] NTLM adopted stronger cryptographic elements, including the MD4 hashing algorithm for password storage and DES for key derivation in its challenge-response process, enabling better protection for domain and workgroup authentication in enterprise environments.[9] These influences from DES and MD4 were chosen for their availability and performance on the hardware of the era, though they later contributed to ongoing security concerns.[10]
NTLM version 1 (NTLMv1) was introduced with Windows NT 3.1 and continued in subsequent versions. Optional support for NTLM version 2 (NTLMv2) was added in Windows NT 4.0 Service Pack 4 in 1998, incorporating enhanced session security features while maintaining backward compatibility with earlier NT systems.[11] To further bolster resistance against replay and offline attacks, NTLMv2 was introduced natively in Windows 2000 in February 2000, replacing weaker DES operations with HMAC-MD5 for key generation and adding timestamping and mutual authentication elements.[12]
Microsoft's support for NTLM has evolved toward deprecation amid recommendations for more secure alternatives like Kerberos. Beginning in the early 2010s, Microsoft advised developers to avoid NTLM in new applications, citing its cryptographic weaknesses, and by 2018, official guidance urged the retirement of legacy variants like NTLMv1 through auditing and policy enforcement.[13] Partial deprecation announcements continued into the 2020s, with tools introduced to block NTLM usage in Windows 7 and Server 2008 R2. In October 2023, Microsoft announced plans to deprecate all NTLM variants, followed by official deprecation in June 2024. As of November 2025, NTLMv1 is removed from Windows 11 version 24H2 and Windows Server 2025, while NTLMv2 remains available only for essential legacy compatibility but is no longer under active development.[4][14]
Protocol Fundamentals
Message Types and Structure
The NTLM authentication protocol employs three primary message types exchanged between the client and server to establish a secure session: the Type 1 Negotiate message, the Type 2 Challenge message, and the Type 3 Authenticate message. These messages form the core of the protocol's handshake, with each type building upon the previous to negotiate capabilities and verify identity. The protocol specifies a binary format for all messages, using little-endian byte order for multi-byte values and supporting either OEM (ANSI) or Unicode (UTF-16LE) character encoding based on negotiation flags.[15]
All NTLM messages share a common fixed-length header consisting of an 8-byte ASCII signature "NTLMSSP\0" followed by a 4-byte message type identifier. This header is immediately followed by variable-length payload sections, which include security buffers for strings (such as domain and username) and other fields like flags and challenges. Security buffers are structured as 8-byte descriptors containing length, maximum length, and offset to the actual data, allowing flexible positioning of payload elements to optimize message size and alignment. The payload may also include optional fields like version information if negotiated.[15][16]
The Type 1 Negotiate message (message type 0x00000001), sent from the client to the server, initiates the authentication process by advertising the client's supported features. Its payload includes a 4-byte NegotiateFlags field specifying protocol options, followed by optional security buffers for the client's domain name and workstation name (in OEM encoding by default). If the NTLMSSP_NEGOTIATE_VERSION flag is set, an 8-byte Version structure is appended, containing the protocol version, but this is typically zeroed otherwise. This message lacks any response data, focusing solely on capability negotiation.[16][17]
The Type 2 Challenge message (message type 0x00000002), sent from the server to the client, responds to the negotiation by confirming supported features and providing a challenge for authentication. Its payload begins with an optional TargetName security buffer (8 bytes descriptor plus variable data) representing the server's authentication realm, such as a domain or server name, encoded in the negotiated character set. This is followed by the 4-byte NegotiateFlags, an 8-byte ServerChallenge (a random 64-bit nonce generated by the server to prevent replay attacks), an 8-byte Reserved field (set to zero), and an optional TargetInfo security buffer. The TargetInfo block contains a sequence of attribute-value (AV) pairs, each prefixed by a 2-byte type identifier and 2-byte length, terminated by an MsvAvEOL (type 0x00) entry; these pairs may include details like channel bindings or timestamps for enhanced security context. A Version structure may follow if negotiated.[18][19][17]
The Type 3 Authenticate message (message type 0x00000003), sent from the client to the server, completes the handshake by supplying proof of identity in response to the challenge. Its payload includes security buffers for the LM and NT challenge responses (each 8-byte descriptors plus 8- to 16-byte opaque response fields), domain name, username, and workstation name (encoded per negotiation), followed by an optional SessionKey buffer (for key exchange if requested), the 4-byte NegotiateFlags, an optional TargetInfo buffer (echoing or extending the server's), and a Version structure if applicable. This message encapsulates the client's credentials indirectly through challenge-response mechanisms without transmitting plaintext passwords.[20][17]
Central to all messages are the NegotiateFlags, a 32-bit bitfield that dictates protocol behavior, such as character encoding, security features, and target types. Key flags include NTLMSSP_NEGOTIATE_UNICODE (bit 0, 0x00000001), which requests UTF-16LE encoding for strings if set (mutually exclusive with NTLMSSP_NEGOTIATE_OEM, bit 1, 0x00000002); NTLMSSP_REQUEST_TARGET (bit 2, 0x00000004), requesting the server's target name; NTLMSSP_NEGOTIATE_SIGN (bit 4, 0x00000010) and NTLMSSP_NEGOTIATE_SEAL (bit 5, 0x00000020) for message signing and sealing; NTLMSSP_NEGOTIATE_KEY_EXCH (bit 26, 0x4000000), enabling explicit session key exchange in the Type 3 message; and NTLMSSP_NEGOTIATE_TARGET_INFO (bit 29, 0x20000000), indicating the presence of the TargetInfo block. Other flags specify target types (e.g., NTLMSSP_TARGET_TYPE_DOMAIN, bit 22, 0x00400000) or request version negotiation (NTLMSSP_NEGOTIATE_VERSION, bit 30, 0x40000000). Unused or reserved bits must be zero. The flags in Type 2 reflect the intersection of client requests and server capabilities.[17]
| Flag Name | Bit Position | Value | Description |
|---|
| NTLMSSP_NEGOTIATE_UNICODE | 0 | 0x00000001 | If set, strings use Unicode (UTF-16LE); otherwise, OEM encoding. |
| NTLMSSP_REQUEST_TARGET | 2 | 0x00000004 | Requests the server to include a TargetName in the Type 2 message. |
| NTLMSSP_NEGOTIATE_SIGN | 4 | 0x00000010 | Requests message integrity via signing. |
| NTLMSSP_NEGOTIATE_SEAL | 5 | 0x00000020 | Requests message confidentiality via sealing. |
| NTLMSSP_NEGOTIATE_KEY_EXCH | 26 | 0x4000000 | Requests the client to provide an encrypted session key in Type 3. |
| NTLMSSP_NEGOTIATE_TARGET_INFO | 29 | 0x20000000 | Indicates the TargetInfo block is present and populated. |
| NTLMSSP_NEGOTIATE_VERSION | 30 | 0x40000000 | Requests inclusion of the Version structure for protocol identification. |
Authentication Mechanism
The NTLM authentication mechanism follows a three-phase challenge-response exchange consisting of the Type 1 Negotiate message from the client, the Type 2 Challenge message from the server, and the Type 3 Authenticate message from the client.[15] The client initiates the process by sending the Type 1 message, which specifies negotiation flags for supported protocol features, including character encoding preferences and security capabilities, using the OEM character set by default.[15] The server then responds with the Type 2 message, which includes a random 8-byte nonce (the challenge) and its supported flags, enabling the client to compute an appropriate response.[15] Finally, the client transmits the Type 3 message containing the challenge responses, domain name, username, and workstation details, allowing the server to validate the authentication attempt.[15]
At its core, the challenge-response principle ensures secure authentication without exposing the user's password in plaintext. The server generates and sends the nonce to uniquely identify the session and resist replay attacks, while the client proves possession of the password by computing a response value based on the nonce and a function of the password-derived secret.[21] The server independently computes the expected response using its copy of the user's credentials and compares it to the client's submission; a match confirms authenticity.[21] This approach embeds NTLM messages within the packets of an underlying application protocol, such as SMB or HTTP, for transport.[21]
Following successful authentication, both parties derive a shared session key from the password-based secret and elements exchanged during negotiation, including the challenge nonce.[21] This key enables optional session security features, such as message signing for integrity and encryption (sealing) for confidentiality in follow-on communications.[21]
Negotiation flags in the Type 1 and Type 2 messages dictate the character encoding for all string fields across the exchange; mutual support for the Unicode flag results in UTF-16 little-endian encoding, enhancing internationalization, whereas absence of this flag defaults to the OEM character set.[15] The OEM fallback assumes an out-of-band agreement on the specific code page between client and server to ensure compatibility.[15]
Error handling in NTLM negotiation primarily involves fallback mechanisms for mismatched flags, with the protocol defaulting to conservative options like OEM encoding when Unicode is not supported, rather than explicit error codes within the messages themselves.[15] Any negotiation failures or invalid responses are typically propagated as errors by the hosting application protocol, prompting retries or alternative authentication paths if configured.[2]
Protocol Versions
NTLMv1
NTLMv1, the original version of the NTLM authentication protocol, was introduced as the default mechanism in Windows NT 3.1 through Windows Server 2003, relying on DES-based LAN Manager (LM) hashes and NT hashes for challenge-response authentication.[2] It employs weak cryptographic primitives, including DES for LM operations and MD4 for NT password hashing, which form the baseline for subsequent enhancements in later versions.[9]
In NTLMv1, the client computes two responses to the server's 8-byte random challenge: the LM response and the NT response. The LM response is derived from the LM one-way function (LMOWF), which processes the uppercase password (truncated to 14 characters, padded if shorter) by splitting it into two 7-byte halves. Each half is used as a DES key (with odd parity adjustment) to encrypt the fixed 8-byte magic string "KGS!@#$%", producing two 8-byte outputs that are concatenated to form the 16-byte ResponseKeyLM. To generate the 24-byte LM response, this key is padded with five zero bytes to 21 bytes, split into three 7-byte segments (each adjusted for odd parity), and each segment encrypts the 8-byte server challenge using DES, with the results concatenated.[9]
The NT response uses the NT one-way function (NTOWF), computed as the MD4 hash of the Unicode representation of the full password, yielding a 16-byte ResponseKeyNT. Similar to the LM response, the 24-byte NT response is produced by padding ResponseKeyNT to 21 bytes with zeros, splitting into three 7-byte DES keys (with parity), and encrypting the server challenge three times, concatenating the outputs. If the NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set (indicating NTLMv1 with session security), the NT response instead encrypts the first 8 bytes of an MD5 hash of the concatenated server challenge and an 8-byte client challenge. The LM response may be replaced with the client challenge padded to 24 bytes in this mode.[9]
The session base key in NTLMv1 is derived directly from the NTOWF by applying MD4 again, resulting in an 16-byte key used as the foundation for message signing and sealing operations. Signing employs this key (or a derived version) with DES or RC4 for integrity checks, while sealing uses RC4 encryption based on the key exchange key (typically the ResponseKeyNT or ResponseKeyLM, depending on available responses) to provide confidentiality. These derivations enable limited session security but expose the protocol to key compromise if responses are intercepted.[9]
NTLMv1 has inherent limitations that undermine its security, including a fixed 8-byte challenge size that limits entropy and facilitates precomputation attacks. It lacks mutual authentication, allowing servers to impersonate clients without verification, and omits timestamps or nonces, making it susceptible to replay attacks where captured responses can be reused. Additionally, the LM component's 14-character limit and DES usage severely weaken resistance to brute-force and rainbow table attacks.[2]
NTLMv2
NTLMv2, an enhanced version of the NTLM authentication protocol, was first made available via Windows NT 4.0 Service Pack 4 in 1997 and received native support in Windows 2000.[1] It requires the client to set the NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag (0x00080000) in the NEGOTIATE_MESSAGE to indicate support, which the server echoes back in the CHALLENGE_MESSAGE if compatible.[17] This version addresses vulnerabilities in NTLMv1 by incorporating stronger cryptographic primitives, including HMAC-MD5 for key derivation and response generation, replacing the weaker DES-based computations.[12]
The core of NTLMv2 authentication lies in its response structure, computed during the AUTHENTICATE_MESSAGE. The NTLMv2 hash, serving as the effective password hash, is derived as follows:
NTLMv2_Hash = HMAC-MD5(NT_Hash, UNICODE(Uppercase(Username) + Domain))
NTLMv2_Hash = HMAC-MD5(NT_Hash, UNICODE(Uppercase(Username) + Domain))
where NT_Hash is the MD4 hash of the Unicode password, and Username and Domain are concatenated after uppercasing only the username.[12] The NTLMv2 response then combines a proof string with a challenge structure (blob). The proof string (NTProofStr) is:
NTProofStr = HMAC-MD5(NTLMv2_Hash, [ServerChallenge](/page/Challenge) + [Temp](/page/Temp))
NTProofStr = HMAC-MD5(NTLMv2_Hash, [ServerChallenge](/page/Challenge) + [Temp](/page/Temp))
Here, ServerChallenge is the 8-byte challenge from the server, and Temp is a concatenation including a 1-byte response version (0x01), a 1-byte high response version (0x01), 6 zero bytes, an 8-byte client-generated timestamp (in FILETIME format), an 8-byte client nonce (client challenge), 4 zero bytes, the target information (AV pairs provided by the server), and 4 trailing zero bytes.[12] The full response is NTProofStr concatenated with Temp, ensuring the proof binds to the dynamic elements without revealing the hash. This structure approximates HMAC-MD5(NT_Hash, Uppercase(Username) || ClientChallenge || Blob), where Blob encapsulates the timestamp and target AV pairs for contextual binding.[12]
The client challenge, an 8-byte random nonce, and the timestamp provide mutual authentication elements and replay protection; the server verifies the timestamp's recency and the client's knowledge of the challenge, while the target information (e.g., server name, domain) ties the response to the specific authentication context.[12] For session security, the session base key is derived as:
SessionBaseKey = HMAC-MD5(NTLMv2_Hash, NTProofStr)
SessionBaseKey = HMAC-MD5(NTLMv2_Hash, NTProofStr)
This key enables stronger message signing using HMAC-MD5 (with sequence numbers for integrity) and sealing via RC4 encryption (with keys derived from the session base key), offering improved protection against modification and eavesdropping compared to NTLMv1's weaker mechanisms.[12]
NTLM2 Session Security
NTLM2 session security, also known as extended session security, is an optional layer added to NTLMv1 authentication to provide message integrity through signing and confidentiality through sealing, without altering the core authentication process of NTLMv1.[17] It is negotiated in the NTLM NEGOTIATE_MESSAGE via the NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag (0x00080000), which enables the use of stronger key derivation for session protection, and often in conjunction with the NTLMSSP_NEGOTIATE_LM_KEY flag (0x00000080) to utilize the LM key for encryption during key exchange.[17] This mechanism operates in a half-duplex mode when using NTLMv1, meaning signing and sealing alternate directions rather than supporting full-duplex simultaneously.[22]
The key exchange process begins with the client generating a random 16-byte ExportedSessionKey upon receiving the CHALLENGE_MESSAGE. To securely share this key with the server, the client encrypts the first 8 bytes of the ExportedSessionKey using the LM session key—derived from the client's LM hash truncated to 8 bytes for DES encryption—and includes the resulting 8-byte ciphertext in the EncryptedRandomSessionKey field of the AUTHENTICATE_MESSAGE.[23] The server, possessing the same LM session key from the verified LM challenge response, decrypts this field to recover the first 8 bytes; the full 16-byte session key is then reconstructed by appending 8 zero bytes to these decrypted bytes if necessary, though in practice, the random generation ensures the full key's entropy.[23] This approach leverages the shared LM key without requiring NTLMv2's enhanced challenge-response computations.[20]
Message signing for integrity uses a derived signing key based on the ExportedSessionKey. The client-to-server signing key (ClientSignKey) is computed as the MD5 hash of the ExportedSessionKey concatenated with the magic constant "session key to client-to-server signing key magic constant" (a 20-byte ASCII string).[24]
\text{ClientSignKey} = \text{MD5}(\text{ExportedSessionKey} \parallel \text{"session key to client-to-server signing key magic constant"})
The server-to-client signing key is derived analogously using "session key to server-to-client signing key magic constant". Signing involves computing a 16-byte message authentication code (MAC) by DES-encrypting a sequence number and message buffer with keys derived from the signing key, ensuring tamper detection for subsequent protocol messages.[22]
For message confidentiality, sealing employs RC4 encryption with a derived sealing key. The sealing key (SealKey) depends on negotiated key strengths: if NTLMSSP_NEGOTIATE_128 (0x20000000) is set, SealKey is the full 16-byte ExportedSessionKey; for NTLMSSP_NEGOTIATE_56 (0x8000000), it uses the first 7 bytes plus parity for a 56-bit effective key; otherwise, the first 5 bytes are used for 40-bit. This base is then processed with MD5 using mode-specific magic constants, such as "session key to client-to-server sealing key magic constant" for client-side operations.[25]
\text{ClientSealKey} = \text{MD5}(\text{ExportedSessionKey} \parallel \text{"session key to client-to-server sealing key magic constant"})
Encryption reinitializes the RC4 state with this SealKey and a per-message sequence number to handle potential out-of-order delivery in connectionless modes.[22]
This session security enhances NTLMv1 compatibility by adding protections atop legacy authentication, commonly implemented in older Windows versions (e.g., Windows NT 4.0 SP4 and later) for protocols like SMB to enable signing without mandating NTLMv2's full protocol upgrade.[21] It supports anonymous or guest logons only without security, disabling signing and sealing in those cases to prevent exposure.[22]
Implementation and Usage
NTLM Security Support Provider
The NTLM Security Support Provider (SSP), implemented in the msv1_0.dll dynamic link library, serves as a core component within the Windows Security Support Provider Interface (SSPI) framework, enabling authentication, integrity, and confidentiality services for distributed applications.[26][2] It operates as a security package that the Local Security Authority (LSA) loads by default, allowing protocols to perform challenge-response authentication without direct access to underlying credentials or session keys.[27]
Initialization of the NTLM SSP begins with the AcquireCredentialsHandle function, which obtains a handle to the credentials of a security principal, such as a logged-on user, for subsequent authentication operations.[28] This handle is then used in calls to InitializeSecurityContext on the client side or AcceptSecurityContext on the server side to iteratively build a security context through token exchanges, establishing mutual authentication and optional session security features like signing and encryption.[29][30]
The NTLM SSP integrates seamlessly into Windows protocols via SSPI calls, providing a protocol-agnostic interface for secure communications; for example, it supports authentication in Server Message Block (SMB) for file sharing, HTTP Negotiate for web access, and Remote Procedure Call (RPC) or Distributed Component Object Model (DCOM) services.[26]
Configuration of the NTLM SSP occurs through registry settings under the HKLM\SYSTEM\CurrentControlSet\Control[Lsa](/page/LSA) key, where administrators can adjust SSP ordering, enable restrictions on NTLM usage, and specify parameters like minimum session security levels via subkeys such as MSV1_0.[11][27]
In environments where Kerberos authentication is unavailable or fails, such as in workgroup configurations or non-domain-joined scenarios, the NTLM SSP acts as the default fallback mechanism to ensure compatibility and continued access.[2] It supports both NTLMv1 and NTLMv2 protocols within this framework.[26]
Version Deployment and Availability
NTLMv1, introduced as the initial version of the protocol, was deployed in early Windows operating systems including Windows NT 3.1 through Windows XP, where it served as the primary authentication mechanism for domain and local logons. However, due to its security limitations, NTLMv1 support became legacy in subsequent releases; it was disabled by default starting with Windows Vista and Windows Server 2008, though it remained available for backward compatibility until its removal in Windows 11 version 24H2 and Windows Server 2025. In contrast, NTLMv2 has been the default authentication variant since Windows 2000, with native support added in that OS and retrofitted to Windows NT 4.0 via Service Pack 4; Windows Vista and later versions enforce NTLMv2 responses by default for enhanced session security, requiring it for features like certain remote desktop connections and file sharing protocols. NTLMv1 continues to be available in Windows 10 and Windows Server 2022 for compatibility, but has been removed from Windows 11 version 24H2 and Windows Server 2025. NTLMv2 remains available across Windows 10, Windows 11 (including 24H2), and Windows Server 2022, integrated through the NTLM Security Support Provider (SSP), though administrators can restrict usage via policy settings.[5]
In practical deployment, NTLM serves primarily as a fallback mechanism when Kerberos authentication fails, such as in intra-domain scenarios where domain controllers are unreachable or misconfigured. It is commonly used for extranet HTTP authentication in web applications employing the Negotiate protocol, particularly in mixed-trust environments without full Kerberos ticket-granting support. Legacy SMB shares also rely on NTLM for client-server authentication in workgroup configurations or when accessing older file servers, ensuring compatibility with pre-Active Directory systems. Negotiation between NTLM versions occurs during the initial handshake, influenced by server-side policies; for instance, the Group Policy setting "Network security: LAN Manager authentication level" allows administrators to mandate NTLMv2 only (e.g., by selecting "Send NTLMv2 response only. Refuse LM & NTLM"), blocking weaker variants like NTLMv1 and enforcing stronger cryptography across domain-joined devices.
As of November 2025, NTLMv2 remains enabled by default in Windows 10, Windows 11 (including version 24H2), and Windows Server 2022 to support legacy applications and devices, but its use is increasingly restricted in modern infrastructures. In cloud environments like Azure Active Directory (Azure AD), NTLM is largely unsupported for services such as Azure Files, where authentication falls back to Kerberos or identity-based methods, prompting hybrid setups to migrate away from it.[31] Usage has declined significantly since 2010, driven by Microsoft's preference for Kerberos in Active Directory domains and ongoing deprecation efforts, yet NTLM persists in air-gapped networks isolated from domain infrastructure and mixed environments with legacy hardware, where full Kerberos deployment is impractical.
Deprecation and Modern Alternatives
Microsoft has pursued the deprecation of NTLM through a series of milestones aimed at reducing its usage and eventually eliminating it from Windows environments. Auditing and restriction policies for NTLM were first introduced in Windows 7 and Windows Server 2008 R2, allowing administrators to monitor and limit NTLM authentication traffic. These capabilities were expanded in subsequent versions, with enhanced auditing features becoming available in Windows 8.1 and later. In June 2024, Microsoft officially deprecated all versions of NTLM, announcing that it is no longer under active development. For Windows 11 version 24H2 and Windows Server 2025, NTLMv1 was removed entirely, with default auditing of NTLMv1 usage enabled starting in late August 2025 for Windows 11 version 24H2 clients and the rollout of Windows Server 2025 beginning in November 2025, culminating in a default block of NTLMv1 via update in October 2026. Full disablement options for NTLM, including NTLMv2, are configurable through Group Policy and registry settings in [Windows 11](/page/Windows 11), enabling organizations to prohibit NTLM authentication domain-wide.[5]
The primary reasons for deprecating NTLM include its persistent security vulnerabilities, such as susceptibility to relay attacks and pass-the-hash exploits, which undermine modern security architectures. Additionally, NTLM is incompatible with zero-trust models due to its lack of mutual authentication, absence of certificate-based validation, and reliance on weaker challenge-response mechanisms that do not align with contemporary requirements for explicit verification at every access point.
As the primary alternative, Microsoft recommends Kerberos, a ticket-based protocol that provides mutual authentication and is the default in Active Directory environments since Windows 2000. For transport-layer security, TLS (particularly TLS 1.3) should be used to encrypt communications, such as in LDAPS or HTTPS, replacing NTLM's insecure fallback role. In web and cloud scenarios, OAuth 2.0 with JWT tokens via Microsoft Entra ID offers scalable, token-based authorization without NTLM's limitations.
To facilitate the transition, Microsoft provides tools like Windows Local Administrator Password Solution (LAPS), which automates the randomization and secure management of local administrator passwords, reducing reliance on domain credentials that might trigger NTLM in lateral movement scenarios. For Remote Desktop Protocol (RDP) sessions, Restricted Admin mode prevents the forwarding and storage of domain credentials on remote systems, mitigating NTLM-related risks by enforcing network-level logons and limiting exposure during administrative access.
Looking ahead, Microsoft plans a phased elimination of NTLM support, with mandatory disabling in Microsoft Entra Domain Services as a best practice already, and broader enforcement expected across Azure and hybrid environments by mid-2026 to align with zero-trust principles.
Security Analysis
Known Vulnerabilities
One of the most prominent vulnerabilities in NTLM is the Pass-the-Hash (PtH) attack, which enables adversaries to reuse stolen NTLM password hashes to authenticate to remote systems without knowledge of the plaintext password. This technique exploits the design of NTLM, where hashes serve as proof of identity in challenge-response exchanges, and has been feasible since NTLMv1 due to the static nature of the hashes until password changes occur. Tools like Mimikatz facilitate PtH by extracting NTLM hashes from LSASS process memory, allowing lateral movement across Windows networks.[32][33][34]
NTLM relay attacks represent another critical flaw, where an attacker intercepts authentication messages and forwards them to target services like SMB or RDP to impersonate the victim. These attacks thrive on NTLM's lack of inherent mutual authentication and are especially potent against NTLMv1, as it does not enforce message signing, though partial mitigations exist via SMB signing requirements. Even in NTLMv2, relay remains viable if signing is disabled or bypassed, enabling privilege escalation or unauthorized access. Recent analyses as of 2025 highlight a "renaissance" in NTLM relay techniques, including low-privilege HTTP-to-LDAP relaying and bypasses of default protections in services like Exchange and AD CS.[35][36][37]
A specific tampering vulnerability in NTLMv2, identified as CVE-2019-1040, allows man-in-the-middle attackers to bypass the Message Integrity Code (MIC) protection, enabling modification of authentication messages without detection. This flaw, exploitable over HTTP, leverages weaknesses in PKCS#7 padding validation to recover hashes or alter fields like target information, facilitating advanced relay scenarios and remote code execution in affected Windows versions.[38][39]
Version-specific weaknesses exacerbate NTLM's risks: in NTLMv1, the LM hash's reliance on DES encryption permits efficient rainbow table attacks, as the 56-bit key length and password splitting into uppercase 7-character halves allow precomputed lookups for millions of common passwords in seconds using modern hardware. For NTLMv2, weak server nonce generation in SMB implementations enables prediction attacks, including replay of timestamped responses if the attacker's knowledge of system time allows simulation of valid challenges.[40][41][42]
Historical CVEs highlight early NTLM flaws, such as those enabling LM downgrades where attackers force fallback to the weaker LM/NTLMv1 protocol, exposing systems to brute-force cracking. Additionally, MS08-068 addressed SMB vulnerabilities tied to NTLM credential reflection, allowing remote code execution via relayed authentication without valid credentials.[43][44]
In 2025, several new NTLM vulnerabilities were disclosed and patched by Microsoft, underscoring ongoing risks despite deprecation efforts. CVE-2025-24054 involves NTLM hash disclosure via spoofing, allowing attackers to capture NTLMv2 hashes with minimal user interaction and was exploited in the wild prior to its March 2025 patch. CVE-2025-54918 enables privilege escalation over the network due to improper authentication in Windows NTLM. Additionally, CVE-2025-59214 is a zero-click credential leak that bypasses prior patches, exposing NTLM hashes on fully updated systems as of October 2025.[45][46][47]
Mitigation and Best Practices
To mitigate risks associated with NTLM authentication, organizations should implement Group Policy Objects (GPOs) to restrict its use, starting with auditing to assess dependency before enforcement. The "Network security: Restrict NTLM: Audit NTLM authentication in this domain" policy, located under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options, enables logging of all NTLM authentication attempts on domain controllers without blocking them, allowing administrators to identify reliant applications and services. Similarly, the "Network security: Restrict NTLM: Audit incoming NTLM traffic" policy audits incoming NTLM traffic from clients and member servers, while the "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" policy audits or denies outbound NTLM attempts to prevent credential exposure. Once audited, these can be escalated to "Deny all" modes to block NTLM domain-wide or for specific traffic directions, with exceptions added via the "Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication" policy for legacy systems.
For finer control, registry modifications provide direct disablement options. Setting the DWORD value RestrictReceivingNTLMTraffic to 2 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 denies all incoming NTLM traffic to the local server, while RestrictSendingNTLMTraffic=2 under the same path blocks outgoing NTLM to remote servers. These changes correspond to the deny options in the aforementioned GPOs and should be tested in non-production environments to avoid disrupting compatible applications. Monitoring can be enhanced by reviewing Event ID 4624 in the Security event log, where the "Authentication Package" field lists "NTLM" for NTLM-based logons, providing visibility into usage patterns.
Best practices emphasize transitioning away from NTLM toward stronger protocols while layering defenses. Enforce Kerberos authentication by configuring the "Network security: LAN Manager authentication level" GPO to "Send NTLMv2 response only. Refuse LM & NTLM," which rejects weaker NTLM variants and prompts fallback to Kerberos where possible. For HTTP-based services, enable Extended Protection for Authentication (EPA) to bind NTLM credentials to the TLS channel, mitigating man-in-the-middle relay attacks; this is configurable via IIS settings or application-specific policies like in Exchange Server. On file shares, require SMB 3.0 signing and encryption through GPOs such as "Microsoft network client: Digitally sign communications (always)" and "Server Message Block: Server SPN target name validation level," which prevent NTLM relay by verifying message integrity and encrypting traffic. Additionally, rotate user credentials frequently—ideally every 90 days or less—to limit the window for offline attacks on captured NTLM hashes, combined with enforcing complex password policies.
Tools like Microsoft Defender for Identity provide automated monitoring by analyzing NTLM traffic for anomalies, such as relay attempts, and generating alerts based on event logs from domain controllers. Third-party tools, including BloodHound from SpecterOps, enable attack path analysis to visualize NTLM-dependent privilege escalation routes, helping prioritize remediation. For testing NTLM reliance, deploy auditing scripts like those in PowerShell to parse Event ID 4624 logs and enumerate NTLM usage across the environment, or use built-in GPO auditing to simulate blocks and measure impact before full deployment.
Integration with Linux and Unix
Samba provides comprehensive support for NTLMv1 and NTLMv2 authentication in its smbclient tool and smbd/nmbd server daemons on Linux and Unix systems, enabling interoperability with Windows networks for file and print sharing via the SMB/CIFS protocol. This support originated in early Samba releases, with encrypted password authentication (enabling NTLM over LM) becoming the default in version 3.0.0 released in 2003, and NTLMv2 handling refined in subsequent versions to match Windows behaviors.[48]
Configuration of NTLM in Samba is managed through the smb.conf file, where parameters control authentication versions and compatibility. For instance, setting ntlm auth = yes allows the server to accept NTLMv1 alongside NTLMv2, though this is deprecated in Samba 4.13 and later due to security concerns; the default is now restricted to NTLMv2 via NTLMSSP. On the client side, client ntlmv2 auth = yes (default since Samba 3.0) enforces NTLMv2 usage in tools like smbclient, disabling weaker NTLMv1 and LANMAN variants. These settings ensure secure negotiation while supporting legacy environments.[48]
In Active Directory-integrated setups, Samba's Winbind daemon facilitates domain user authentication on Linux/Unix hosts, preferring Kerberos for modern clients but falling back to NTLM for legacy Windows systems unable to use Kerberos tickets. Winbind integrates with PAM and NSS for seamless user mapping, allowing NTLM-only authentication in mixed-domain scenarios where Kerberos is unavailable. This fallback is configured via smb.conf security modes like security = ads and Winbind options in /etc/nsswitch.conf.
Key utilities for NTLM operations include ntlm_auth, a helper program for verifying NTLM credentials against domain backends like Winbind or tdbsam, often used in proxy or custom authentication scripts. For mounting SMB shares with NTLM, the cifs-utils package provides mount.cifs, supporting options like sec=ntlm or sec=ntlmv2 to specify authentication types during filesystem mounts. These tools enable testing and practical use of NTLM in non-Windows environments.[49]
Challenges in NTLM integration on Linux/Unix include differences in Unicode string handling compared to Windows, where NTLM expects UTF-16 encoding; mismatches can lead to authentication failures with non-ASCII usernames or passwords unless properly configured via client charset options in smb.conf. Additionally, in mixed Windows-Linux networks, NTLM's susceptibility to relay attacks persists if signing is not enforced, as attackers can intercept and reuse credentials across SMB connections.[48]
Support in Other Operating Systems
macOS provides native support for NTLMv2 authentication through its SMB implementation, enabling secure file sharing over SMB. This support integrates with the system's Keychain for credential storage and management, allowing users to authenticate to Windows-based SMB shares without repeated prompts. For instance, macOS clients can negotiate NTLMv2 sessions with servers supporting SMB2 and higher, ensuring compatibility in mixed environments while favoring Kerberos when available.
On mobile platforms, NTLM support is limited and primarily occurs through enterprise Mobile Device Management (MDM) configurations for Wi-Fi authentication. In iOS and iPadOS, configuration profiles can enable NTLM-based methods like MSCHAPv2 within EAP-PEAP for enterprise Wi-Fi networks, though this is typically restricted to supervised devices in corporate settings.[50] Similarly, Android Enterprise allows NTLM via MDM-deployed Wi-Fi profiles using EAP methods that rely on NTLM hashes, such as for connecting to legacy Active Directory-integrated networks.[51] However, both platforms discourage direct NTLM use in applications due to security concerns, recommending certificate-based alternatives like EAP-TLS instead.[52]
Embedded and IoT systems often incorporate NTLM for legacy compatibility, particularly in printing and scanning devices. For example, HP JetDirect-enabled printers support NTLM authentication for IPP and SMB-based workflows, such as scanning to network folders on Windows shares, though many older models are limited to NTLMv1 due to hardware constraints.[53] With the removal of NTLMv1 support in Windows 11 version 24H2 and Windows Server 2025, these older NTLMv1-limited devices may face compatibility issues with newer Windows clients unless upgraded or configured to use NTLMv2 or alternative protocols.[5] This enables interoperability with enterprise print servers but requires careful configuration to avoid exposing weaker authentication variants.
Third-party systems extend NTLM support through specialized integrations. Cisco Identity Services Engine (ISE) utilizes NTLM, particularly NTLMv1 via MSCHAPv2, for supplicant authentication in network access control scenarios, allowing seamless integration with Active Directory for 802.1X environments.[54] Oracle Solaris includes native NTLM authentication in its SMB services, configurable via properties like lm-compatibility-level to handle NTLMv1 and v2 sessions with Windows domains.[55] Earlier implementations relied on Sun Freeware ports for additional tools like ntlm_auth, but modern Solaris versions provide built-in support.[56]
Interoperability challenges with NTLM, especially v2, frequently arise from clock skew in timestamp validation, where discrepancies exceeding five minutes between client and server clocks can cause authentication failures.[57] Additionally, message parsing issues stem from NTLM's little-endian byte order, leading to errors in non-Windows implementations that fail to correctly interpret flags or offsets without proper handling.[12] These problems underscore the need for synchronized time sources and endianness-aware protocol stacks in cross-platform deployments.