NTLM is a suite of **authentication and session security protocols** used in various Microsoft network protocol implementations and supported by the *NTLM Security Support Provider* ("NTLMSSP"). It is probably best recognised as part of the "**Integrated Windows Authentication**" stack for *HTTP authentication*; however, it is also used in Microsoft implementations of *SMTP*, *POP3*, *IMAP* (all part of Exchange), *CIFS/SMB*, *Telnet*, *SIP*, and possibly others. The NTLM Security Support Provider *provides authentication, integrity, and confidentiality* services within the Window Security Support Provider Interface (**SSPI**) framework. **SSPI specifies a core set of security functionality** that is implemented by supporting providers; the NTLMSSP is such a provider. The SSPI specifies, and the **NTLMSSP implements**, the following core operations: 1. **Authentication** -- NTLM provides a challenge-response authentication mechanism, in which clients are able to prove their identities without sending a password to the server. 2. **Signing** -- The NTLMSSP provides a means of applying a digital "signature" to a message. This ensures that the signed message has not been modified (either accidentally or intentionally) and that that signing party has knowledge of a shared secret. *NTLM implements a symmetric signature scheme* (Message Authentication Code, or **MAC**); that is, a valid signature can only be generated and verified by parties that possess the common shared key. 3. **Sealing** -- The NTLMSSP implements a *symmetric-key encryption mechanism*, which provides message confidentiality. In the case of NTLM, sealing also implies signing (a signed message is not necessarily sealed, but all sealed messages are signed). > [!note] > > NTLM has been **largely supplanted by Kerberos** as the authentication protocol of choice for domain-based scenarios. However, *Kerberos is a trusted-third-party scheme*, and *cannot be used in situations where no trusted third party exists*; for example, member servers (servers that are not part of a domain), local accounts, and authentication to resources in an untrusted domain. In such scenarios, NTLM continues to be the primary authentication mechanism (and likely will be for a long time). ### NTLM Terminology NTLM authentication is a **challenge-response scheme**, consisting of three messages, commonly referred to as Type 1 (*negotiation*), Type 2 (*challenge*) and Type 3 (*authentication*). It basically works like this: 1. The client sends a Type 1 message to the server. This primarily *contains a list of features supported by the client and requested of the server*. 2. The server responds with a Type 2 message. This contains a *list of features supported and agreed upon by the server*. Most importantly, however, it **contains a challenge** generated by the server. 3. The client replies to the challenge with a Type 3 message. This contains several **pieces of information about the client**, including the *domain* and *username* of the client user. It also contains **one or more responses to the Type 2 challenge**. The responses in the Type 3 message are the most critical piece, as they **prove to the server that the client user has knowledge of the account password**. The process of authentication establishes a shared context between the two involved parties; this includes a **shared session key**, used for subsequent signing and sealing operations. More info: https://davenport.sourceforge.net/ntlm.html