The Working of NTLM Authentication

Why NTLM:

Microsoft adopted Kerberos as the preferred authentication protocol for Windows 2000 and subsequent Active Directory domains. Kerberos is typically used when a server belongs to a Windows Server domain, or if a trust relationship with a Windows Server Domain is established in some other way (such as Linux to Windows AD authentication). But NTLM can be used in either case(if you have a active directory or not).

NTLM is still used in the following situations:

• The client is authenticating to a server using an IP address
• The client is authenticating to a server that belongs to a different Active Directory forest that has a legacy NTLM trust instead of a transitive inter-forest trust
• The client is authenticating to a server that doesn't belong to a domain
• No Active Directory domain exists (commonly referred to as "workgroup" or "peer-to-peer")
• Where a firewall would otherwise restrict the ports required by Kerberos (typically TCP 88)

Working of NTLM:

The following steps present an outline of NTLM non-interactive authentication. The first step provides the user's NTLM credentials and occurs only as part of the interactive authentication (logon) process.

1. (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.

2. The client sends the user name to the server (in plaintext).

3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.

4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.

5. The server sends the following three items to the domain controller:

• User name
• Challenge sent to the client
• Response received from the client

6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.

7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.

NTLM working in terms of status codes:

Windows NT Challenge/Response protocol

Windows NT Challenge/Response (NTCR) protocol differs from Kerberos in that the server presents the HTTP client with a "challenge" and the client responds with its response. This way, the client's password is never sent over the network. Authentication with the NTCR protocol occurs as follows:

1. Typically, the client issues an initial anonymous request. When the anonymous request is rejected, IIS returns a 401.2 error and the WWW-Authenticate headers.

2. If the client fails or does not support Kerberos, the Negotiate and NTLM header values initiate an NTCR authentication exchange. The client closes the TCP connection, opens a new one, and sends a request that includes an Authorization: NTLM header. This header also includes encoded text that represents the users UserName, ComputerName, and Domain. This text is used by the Windows Security Support Provider Interface (SSPI) to generate the challenge. If the user account is not a local Windows account on the IIS server, the data is passed on to an appropriate domain controller, which then generates the challenge.

3. The challenge is sent to the client and IIS returns another 401.1 error.

4. The client uses its password and the challenge to create a mathematical hash. The client sends the hash back to the server in another Authorization: NTLM header.

5. The server accepts the response, and the local security provider or the appropriate domain controller recreates the same hash and compares the two. If they match, the user is successfully authenticated.