Integrated Windows Authentication with Negotiate

This article has been moved to its new home here:

IIS provides a number of different authentication techniques.  One of which is Integrated Windows Authentication.  Integrated Windows Authentication utilizes Negotiate/Kerberos or NTLM to authenticate users based on an encrypted ticket/message passed between a browser and a server.

The preceding image shows a standard communication flow between Internet Explorer and IIS version 6+.  The initial request from Internet Explorer typically uses Anonymous as the authentication method.  For this example it is assumed that IIS disables Anonymous Authentication and enables Integrated Windows Authentication to include the Negotiate and NTLM providers.  Considering those assumptions, when IIS receives an Anonymous request from Internet Explorer, a 401.2.x message is returned along with the authentication providers IIS is configured to accept.

Internet Explorer reads the supported authentication providers in the response header from IIS and determines which provider to use.  To configure Internet Explorer to use Integrated Windows Authentication select the Tools menu item of Internet Explorer, click on the Advanced tab and you will find a checkbox similar to the below:

When enabled, Internet Explorer will use the Negotiate authentication provider, which means Kerberos.  Internet Explorer will return the authentication provider it wants to use along with the encrypted security ticket.  IIS will then authenticate the users’ credentials, and if successful, return a 200.0.0 message.

On a Windows Server R2 2008 using IIS 7.5 the configuration which utilizes only Integrated Windows Authentication resembles the following image.

To view the request and response headers of a web request you can use a tool named Fiddler.  The following image is a textual representation of the first image in this post.  Using Fiddler you see that a browser request is made, a 401.2.x server response is returned containing the supported/configured authentication providers (Negotiate and NTLM).  A request from the browser containing the Kerberos token is sent to the server which returns the requested content along with a 200 OK status.

Here is a very good article coverning how to troubleshoot Kerberos issues.

Comments (10)
  1. Anonymous says:

    Good to know!  Thanks.

  2. Nice detailed article 🙂

  3. Anonymous says:

    thanks for article Integrated Windows Authentication with Negotiate

  4. Anonymous says:

    Extremely helpful, knowing the difference in integrated technologies really helps.  

  5. Anonymous says:

    You wrote above that Negotiate means Kerberos. this is mistake.

    Negotiate means that the server should try Kerberos but if it fails it should try NTLM.

    beside that not all systems support Negotiate and you may have to specify the exact authentication method to use (usually NTLM or Kerberos)

  6. Anonymous says:

    In this scenario,  can you please explain how does IIS authenticates if you have a "local" windows account (say user1) on the server (say server1)  and you send (unknownuser1) on windows prompt

    In the fiddler, I noticed that the server returns NTLM Type2: Challenge]——————————

    Provider: NTLMSSP and authenticates user1 (even though you send "unknown" domain name.

  7. Anonymous says:

    I get the similar results ,but I need to refresh the page to get the 200 Ok..why is it like that ?

  8. microsoft cloud says:

    Extremely helpful, knowing the difference in integrated technologies really helps.

  9. Barnabas says:

    Thanks for sharing I find it very insightful

  10. jp2code says:

    How would someone use this to connect to a non-Windows server (specifically, a Novell eDirectory)?

Comments are closed.

Skip to main content