Integrated Windows Authentication with Negotiate


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 (9)

  1. Regie says:

    Good to know!  Thanks.

  2. Nice detailed article 🙂

  3. Usman says:

    thanks for article Integrated Windows Authentication with Negotiate

  4. Aziz says:

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

  5. ofirmgr 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. Rajesh 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. Adi 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

Skip to main content