NTLM!!!!!!! want to know how it works!!!!!!!!!

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). 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 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:

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.

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:

HTTP: Request, GET /
Command: GET 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

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:

HTTP: Response, HTTP/1.1, Status Code = 401
ProtocolVersion: HTTP/1.1
StatusCode: 401, Unauthorized
Reason: Unauthorized
ContentLength: 1656
ContentType: text/html
Server: Microsoft-IIS/6.0
WWWAuthenticate: NTLM

IIS then writes an entry that resembles the following to the IIS log:

<Date> <Time> W3SVC<ID> <serverIP> GET / – 80 – <clientIP> Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 401 2 2148074254

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:

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

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




IIS then writes an entry in the IIS log that resembles the following:

<Date> <Time> W3SVC<ID> <serverIP> GET / – 80 – <clientIP> Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 401 1 0

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




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:

HTTP: Response, HTTP/1.1, Status Code = 200
ProtocolVersion: HTTP/1.1
StatusCode: 200, Ok
Reason: OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
ContentLength: 19
ContentType: text/html
Cache-control: private

After IIS sends this response, IIS writes the following associated entry to the IIS log:

<Date> <Time> W3SVC<ID> <serverIP> GET /time.asp – 80 Domain\User <clientIP> Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 0






Comments (36)

  1. Jimmy says:

    Thanks for this Blog, helped me understand how NTLM works, it is very detailed.

  2. Sunny says:

    Awesome writeup!!!!

  3. Dineshbabu says:

    very useful

  4. jm says:

    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.

  5. 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

             UINT8: xxxx

             UINT8: xxxx

             UINT8: xxxx

             UINT8: xxxx

             UINT8: xxxx

             UINT8: xxxx

             UINT8: xxxx

             UINT8: xxxx

    Each unit has a hex value and the size of each unit is 1 byte

  6. Lesley L says:

    Thanks for sharing – very useful!

  7. Srikanth says:

    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

  8. @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.

  9. ravi says:

    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

  10. @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

  11. Laxmikant says:

    I used ntlm authentication in a nodejs webservice, but it is accepting any credentials, I confused how can I what is exact use of ntlm authentication in webservices?

  12. @Laxmikant: i am not sure i completely understand your question. Are we trying to enable NTLM authentication for the web service and how are we calling the web service. Regarding the setting of authentication make sure you disable anonymous auth and only have NTLM windows auth and below is a kb which will show you how you can pass the logged in creds to a web service when you have windows auth on


  13. Mark says:

    Thanks!  This is awesome!  Now I finally understand what is going on with the 2 401s that are always present in Fiddler.

  14. Pradeep says:

    Good work Chiranth

  15. Abhijeet says:

    Awesome clarification… Thanks a ton!!!

  16. Swapnil says:

    great article, thanks

  17. John says:

    I rarely comment but this is great explanation! I have read so much and gotten so confused. You explained it brilliantly!

  18. Somnath says:


    I have a question. How subsequent reqs work? Once authenticated then how can it recognize that the same user is trying to access a diff page? Does it use any header for subsequent requests?

  19. @Somanth: That's a good question. NTLM is a HTTP/TCP channel based protocol. once the authentication happens the same encrypted token or NTLM token is exchanged over the multiple requests over the same channel. Imagine in case there is connection reset or the channel gets closed abruptly or due to a reset then the authentication process will have to happen again over the new channel.

  20. Chris says:

    I would have expected each subsequent request to include the Authorisation header each time but they don't. I don't understand how the client is identified if there is nothing within the request message to identify them. Could you let me know how this works please?

  21. @Chris: Yes you are right. Every time a request is sent you should be able to see the authorization header. If you have enabled windows auth and you are not seeing the authorization header, this means that the request is not going to the server and is picked up from the local cache. I tried to set up a repro opn my machine and was able to get the exact same behaviour as you see and in all those cases where I took netmon traces I don't see any request going out of the client and it is picked from cache. Possibly what you can so to confirm this behaviour is whenever you see this issue again, do a CTRL+F5 on the browser for the link and now you will be able to see the authorization header. Doing a CTRL+F5 in IE forces the browser to make a hard request to the server rather than picking it from the cache. Hope this helps and answers your question. Let me know in case of any further questions

  22. Sultan Rayes says:

    Thank you, this reveal NTLM mystery

  23. Radhika says:

    Nice article!! Can you explain how the NTLM authentication works in 2-way domain trust. That is user from Domain A is trying to access an application in Domain B with NTLM authentication enabled on it.

  24. @Radhika: I don't have a trace or something to explain it in detail. But I will work to get in sometime later. But when user in domain A accesses the site in domain B, the steps would be almost the same, during auth phase the client would be sending the domain info of the user and once the challenge and encrypted challenge reaches the server in domain B, server will contact its parent domain controller and this call recursively is taken to the domain controller of domain A to get this authentication completed and for this to happen, there should be trust between the domains. I do have a scenario where I have worked on the flow for multi domain scenario in case of Kerberos and its in my Kerberos blog. Please let me know if you have any queries.

  25. Awesome says:

    Incredibly awesome post with useful fiddler data.

  26. sudheer says:

    Kerberos!!!!!!! want to know how it works!!!!!!!!! (i want this one as well)

    1. @Sudheer: i have already posted 2 blogs on kerberos

  27. Hamid says:

    Thanks a lot for your very useful text.I have a special question that hope you can help me.
    I want to measure (or find a valid document) how long it takes to authenticate from local PC to windows 2008 R2 through RDP with local authentication .(Just authentication from when session start to when user authenticate(in failed and successful situation)
    Im looking a way to measure a minimum time.

  28. Jorge says:

    Excellent article!!

    1. sreehari says:

      hi ,

      In my application we are using NTLM authentication , We have a one search Page which used Jquery Data table . The search is working properly in local PC when access in cloud it is not working. We observed that some of the search parameters are not receiving at the server. please assist

      1. @sreehari: do you see that authentication is failing?

  29. Nagalakshmi says:

    Excellent article. Thanks. I am having to roll out custom NTLM auth for a mobile app using Xamarin. Do you know of a reference implementation of the handshake.

  30. Kuppi says:

    Hi Chiranth,

    Thanks for a great post. I have to write a simple test application to explore the NTLM authentication possibility. This program (client console) will just simply get authenticated using NTLM. I am wondering how to proceed with this ?

    1. @kuppi: Depends on what language this is using. As an example if this is a .net console or windows application and assuming you are using system.net to make the outbound web call, you can set the user credential in network credential manager and system.net should take care if the ntlm authentication internally and you don’t have to implement much. https://msdn.microsoft.com/en-us/library/system.net.networkcredential(v=vs.110).aspx

  31. Ajinkya19 says:

    Thanks for such detailed working of NTLM. I have one question for you, i am using java.net.Authenticator class for performing NTLM authentication to SharePoint 2010. Once the authentication is successful with correct username password it doesn’t throw any exception even if i send request with wrong credentials. Actually once i have made successful connection this Authenticator doesn’t take any new username or password till i restart the JVM. Is this behavior is correct or not ? If not then what should i try out.