通过

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

  • 项目

Overview and working of NTLM

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 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.1Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*Accept-Language: en-usAccept-Encoding: gzip, deflateUserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)Host: www.kerberos.comConnection: 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 = 401ProtocolVersion: HTTP/1.1StatusCode: 401, UnauthorizedReason: UnauthorizedContentLength: 1656ContentType: text/htmlServer: Microsoft-IIS/6.0WWWAuthenticate: 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: GETURI: /ProtocolVersion: HTTP/1.1Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*Accept-Language: en-usAccept-Encoding: gzip, deflateUserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)Host: www.kerberos.comConnection: Keep-AliveAuthorization: NTLM TlRMTVNTUAABAAAAB7IIoAcABwssAoAAAACAAIACAAAABWQU5XSU5YUFZBTkRBTkE=

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 = 401ProtocolVersion: HTTP/1.1StatusCode: 401, UnauthorizedReason: UnauthorizedContentLength: 1539ContentType: text/htmlServer: Microsoft-IIS/6.0NTLMAuthorization: NTLMTlRMTVNTUAACAAAADgAOADgAAAAFgomiRCfS+kdwvJ0MAAAAAAAAAAJYAlgBGAAAABQLODgAAAA9WAEEATgBEAEEATgBBAAIADgBWAEEATgBEAEEATgBBAAEAFgBXAEkATgBEAEss8AVwBTADIAMAAwADMABAAWAHYAYQBuAGQAYQBuAGEALgBjAG8AbQADAC4AVwBpAG4AZABvAHcAcwAyADAAMAAzAC4AdgBhAG4AZA

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: GETURI: /ProtocolVersion: HTTP/1.1Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*Accept-Language: en-usAccept-Encoding: gzip, deflateUserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)Host: www.kerberos.comConnection: Keep-AliveNTLMAuthorization: NTLMTlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAAA4ADgBAAAAAGgAaAE4AAAAQABAAaAAAAAAAAACoAAAABYKIoFYAQQBOAEQAQQBOAEEAQQBkAG0AaQBuAGkAcwB0AwwHIAYQB0AG8AcgBWAEEATgBXAEkATgBYAFAAo53RVbJ/EucAAAAAAAAAAAAAAAAAAAAAcWyNNNlQLNMC3EVd+aoZCA9lkh8dVY/M

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 = 200ProtocolVersion: HTTP/1.1StatusCode: 200, OkReason: OKServer: Microsoft-IIS/6.0X-Powered-By: ASP.NETContentLength: 19ContentType: text/htmlCache-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

References:

https://en.wikipedia.org/wiki/NTLM https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/bb643328.aspx https://msdn.microsoft.com/en-us/library/bb643328.aspx

Technorati Tags: authentication,iis,UI,missing section,missing,anonymous,registry

Comments

  • Anonymous
    March 20, 2014
    Thanks for this Blog, helped me understand how NTLM works, it is very detailed.

  • Anonymous
    March 29, 2014
    The comment has been removed

  • Anonymous
    April 13, 2014
    Awesome writeup!!!!

  • Anonymous
    April 16, 2014
    very useful

  • Anonymous
    May 12, 2014
    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.

  • Anonymous
    May 19, 2014
    The comment has been removed

  • Anonymous
    July 02, 2014
    Thanks for sharing - very useful!

  • Anonymous
    July 31, 2014
    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

  • Anonymous
    August 02, 2014
    @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.

  • Anonymous
    October 13, 2014
    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

  • Anonymous
    October 14, 2014
    The comment has been removed

  • Anonymous
    November 23, 2014
    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?

  • Anonymous
    November 24, 2014
    @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 onsupport.microsoft.com/.../813834

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

  • Anonymous
    April 05, 2015
    Good work Chiranth

  • Anonymous
    May 25, 2015
    Awesome clarification... Thanks a ton!!!

  • Anonymous
    May 30, 2015
    great article, thanks

  • Anonymous
    September 03, 2015
    I rarely comment but this is great explanation! I have read so much and gotten so confused. You explained it brilliantly!

  • Anonymous
    September 09, 2015
    Hi, 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?

  • Anonymous
    September 10, 2015
    @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.

  • Anonymous
    September 10, 2015
    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?

  • Anonymous
    September 10, 2015
    @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

  • Anonymous
    October 20, 2015
    Thank you, this reveal NTLM mystery

  • Anonymous
    October 28, 2015
    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.

  • Anonymous
    October 30, 2015
    @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.

  • Anonymous
    February 24, 2016
    Incredibly awesome post with useful fiddler data.

  • Anonymous
    April 13, 2016
    Kerberos!!!!!!! want to know how it works!!!!!!!!! (i want this one as well)

    • Anonymous
      April 14, 2016
      @Sudheer: i have already posted 2 blogs on kerberos
      • Anonymous
        November 07, 2016
        Hi Chiranth, Thank you for the NTLM bolg. I Really appreciate your valuable time to spend for everyone.I did not find Kerberos blogs. Started working on HDFS with kerberos . Thanks,saritha
        • Anonymous
          November 12, 2016
          @saritha: Below are the links for kerberos blogs. Hope it helpshttps://blogs.msdn.microsoft.com/chiranth/2014/04/17/setting-up-kerberos-authentication-for-a-website-in-iis/https://blogs.msdn.microsoft.com/chiranth/2013/09/20/all-about-kerberos-the-three-headed-dog-with-respect-to-iis-and-sql/

  • Anonymous
    June 21, 2016
    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.

  • Anonymous
    June 21, 2016
    Excellent article!!Thx

    • Anonymous
      July 12, 2016
      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
      • Anonymous
        July 14, 2016
        @sreehari: do you see that authentication is failing?

  • Anonymous
    July 13, 2016
    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.

  • Anonymous
    July 27, 2016
    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 ?

    • Anonymous
      July 29, 2016
      @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

  • Anonymous
    August 16, 2016
    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.

  • Anonymous
    August 08, 2017
    Hi Chiranth,i configured NTLM on apache, Tomcat. Once we delete browser cache NTLM prompts for username and password again which should not be the case. can you help me with that.Thanks In Advance

    • Anonymous
      August 09, 2017
      @sudha: if this is a intranet site, make sure that the website is added to the local intranet sites zone in IE settings. Also make sure you have elected do no prompt for intranet sites option selected in IE options in the security tab

  • Anonymous
    December 05, 2017
    Hey Chiranth! In an active directory environment, how do I query the AD/Domain Controller to verify the ntlm response sent by the client? I'm actually looking to implementing NTLMv2 on such an environment. Also, server is a Linux machine