NTLM Authentication

All NTLM protocols use a challenge-response mechanism to authenticate users and computers. This process requires the user to prove to the server or domain controller that they know their account password, without actually sending the password over the network.

NTLM was introduced in 1993 with Windows NT 3.1, replacing the older LM hash method, which had significant security flaws. However, NTLM itself also had security vulnerabilities, leading to the development of NTLMv2 with Windows NT 4.0 SP4. The original version was then referred to as NTLMv1.

With the release of Windows 2000, Kerberos became the default authentication protocol for Active Directory (AD) domains, replacing NTLM.

Despite its security issues, NTLM remains supported in modern IT environments for backward compatibility. NTLMv2 is still in use for local logins, network logins in WORKGROUPS, certain HTTP servers, and Single Sign-On (SSO) applications.

NTLM Authentication Process

Initial Request (Client to Server)

When a client tries to access a resource on a server (for example a file server), the server requests authentication from the client. This typically happens in situations where the client hasn’t yet authenticated to the server, like accessing shared files or services.

The client sends a request to the server or domain controller asking for access to a particular resource, indicating that it needs to authenticate.

Challenge (Server to Client)

Once the server receives the request, it responds with a challenge. This challenge is a randomly generated number (sometimes called a nonce) that the server sends to the client. This step ensures that the client cannot simply reuse any previously captured information to authenticate again.

Response (Client to Server)

The client proves it knows the password by encrypting the randomly generated number using the DES algorithm. The encryption key is the NT hash of the password, which is a hashed version of the password created using the MD4 algorithm. By encrypting the random number this way, the client confirms it knows the password without sending the actual password over the network.

Verification (Server to Domain Controller)

Local Authentication

If the authentication is local (not domain-based), the server uses its own local SAM (Security Account Manager) database to retrieve the stored NT hash of the user’s password. It then uses this hash to validate the client’s response.

Domain-Based Authentication

If the authentication is domain-based, the server forwards the challenge/response pair to the domain controller. The domain controller retrieves the stored NT hash from the Active Directory database and uses it, along with the challenge (nonce), to generate a hash that it compares to the client’s response.

If the server’s (or domain controller’s) generated hash matches the client’s response, the authentication is successful, and access to the requested resource is granted.

Work in Progress