Overview and working of 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).
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 in general words:
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:
◦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.
NTLM Working from Fiddler Perspective:
The following is a scenario-based example in which IIS is configured to support only the NTLM protocol. In IIS 6.0 and in earlier versions, this is done by having the NTAuthenticationProviders metabase key set to "NTLM". In IIS 7.0 and in later versions, only the NTLM protocol must be listed as a provider in the <windowsAuthentication> section. Again, Internet Explorer does not include any authentication information in the first request on a new connection:
If the IIS server is not configured to support Anonymous authentication, the server returns a 401.2 status that tells the client that the client is unauthorized. Together with the error status, the server also sends a list of authentication protocols that the server supports. The response headers that IIS returns in this NTLM-only scenario resemble the following:
IIS then writes an entry that resembles the following to the IIS log:
When the client receives the server's notification that the server supports the NTLM protocol, the client re-sends the request. The client includes authentication information in an Authorization header:
As part of the NTLM handshake, the server acknowledges that the client has sent authentication information. However, the server needs the client to send more information. Therefore, the server returns another 401 response that resembles the following:
HTTP: Response, HTTP/1.1, Status Code = 401 ProtocolVersion: HTTP/1.1 StatusCode: 401, Unauthorized Reason: Unauthorized ContentLength: 1539 ContentType: text/html Server: Microsoft-IIS/6.0 NTLMAuthorization: NTLM TlRMTVNTUAACAAAADgAOADgAAAAFgomiRCfS+kdwvJ0MAAAAAAAAAAJYAlgBGAAAABQ
IIS then writes an entry in the IIS log that resembles the following:
The 401.1 status that IIS sends tells the client that the client must provide the remainder of the valid authentication information. The client receives this challenge. The client then sends one more request that resembles the following:
HTTP: Request, GET / Command: GET URI: / ProtocolVersion: HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language: en-us Accept-Encoding: gzip, deflate UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: www.kerberos.com Connection: Keep-Alive NTLMAuthorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAAA4ADgBAAAAAGgAaAE4A
When the IIS server receives this request, the IIS server communicates with a domain controller to complete the authentication request. When the client's authentication request is confirmed, IIS sends a response that resembles the following:
After IIS sends this response, IIS writes the following associated entry to the IIS log:
Thanks for this Blog, helped me understand how NTLM works, it is very detailed.
YW Jimmy :)
I have a question: what's length of The challenge from server ? 16 byte or 8 byte ? Is there any doc except "msdn.microsoft.com/.../aa378749(v=vs.85).aspx"
In the doc("davenport.sourceforge.net/ntlm.html) ,the challenge in the type message 2 is 8 byte.
Hi Jim, sorry for the late response. thats a good question. i looked into the structure of nonce or server challenge and it appears it is 8 bytes. if we look at a serverchallenge in a network trace, it looks like below.
- ServerChallenge: xxxxxxxxxxxxxxxx
Each unit has a hex value and the size of each unit is 1 byte
Thanks for sharing - very useful!
Good draft. One question is why can't the client can not send whole authentication information in first attempt? Some clarity needed in this area
@srikanth: All browsers tend to make an anonymous request to the server first. they dont know that they need to authenticate themseleves in the first request itself. For eg take bing.com anyone can access bing.com by not providing credentials. it is my servers responsibility to tell the browser that it needs to authenticate itself. After the browser selects ntlm this is a 2 way process(challenge and response). in order to prepeare a challenge the server needs session and some details from client that are unique, based on this infomration a 8 bit challenge is built and given to the client. so that whole architecture of ntlm is a 2 step process. However you can tell your browser to send the credentials or authorize itself in the first request itself. this is called NTLMPreAuth. However i wouldnt recommend this change.
i am using IIS6 for my application to authenticate and authorization but when it forwards request to my app the authorization header missing pls suggest
@Ravi: in order for your app to forward the authorization header, the app in the second tier needs to have authentication set as windows as well and in order to delegate the logged in credentials to a backend app(double hop scenario), this cant be done using NTLM. you might have to configure kerberos and enable impersonation and proper authentication settings on the backend app as well. you can check my blogs on kerberos for reference