Windows Authentication with Chrome and IIS

Recently I was tasked at work with creating a dashboard application for use on our intranet using ASP.Net MVC. Due to the need to track some user preferences, I set this up to use Windows Authentication so I would be automatically passed the credentials from the user’s Windows session. I developed the web app and tested it using IIS express on my local machine using both Internet Explorer and Google Chrome without issue. When it came time to deploy the site to our test cluster for some user feedback, this is where I discovered an issue around Windows Authentication with Chrome and IIS (Internet Explorer still worked fine).

When pulling up the site in Chrome I was greeted with “This webpage is not available”. Clicking on the more button revealed the error code: “ERR_INVALID_AUTH_CREDENTIALS”.
 

Chrome Invalid Auth Credentials

 
 

What Didn’t Work:

I remembered reading where Chrome uses the local intranet settings from Internet Explorer so I pulled up those settings to take a look. I tried specifically adding the new site to the local intranet zone with the dialog box shown below (Internet Options -> Security Tab -> Sites -> Advanced). Unfortunately, this didn’t help. When I refreshed Chrome I still had the “ERR_INVALID_AUTH_CREDENTIALS” error.
 

Local Intranet Add Site To Zone

 
Back on the security tab in the internet options dialog, I clicked the “Custom Level” button and looked through all the settings. At the very bottom I found what looked like a promising setting under User Authentication -> Logon. By default, “Automatic logon only in Intranet zone” was selected. I changed that to the option below it that read, “Automatic logon with current user name and password”. Upon refreshing Chrome, I once again found I was still getting the “ERR_INVALID_AUTH_CREDENTIALS” error.
 

Local Intranet Security Settings

 
 
What Worked:

At this point I decided to start Googling around for some help. I found several StackOverflow questions that offered some suggestions, but none of them seemed to work. Eventually I stumbled across the suggestion of removing “Negotiate” from the enabled providers in IIS for the site. I gave it a shot, and this is what ended up solving the issue for me.

Here’s how to make the change: Navigate to your site/application in IIS and select it by clicking on it. This should show a list of options in the “features view” on the right hand side of the screen. Find “Authentication” and double click on it.
 

IIS Select Authentication

 
You should now see a list of different authentication types. Click on Windows Authentication to select it and then click on Providers in the Action section of the right hand column.
 

IIS Select Windows Auth

 
This will pop-up a dialog showing the enabled providers. I tried adjusting the negotiate provider’s priority by moving it down the list, but that didn’t seem to have any effect. Remove the “Negotiate” provider by clicking on it in the list to select it and then clicking on Remove.
 

IIS Providers Dialog

 
Click the Ok button on the dialog to close it down and then refresh your site in Chrome.

Version Information:
Google Chrome v33
Internet Explorer v11
IIS v7.5

26 thoughts on “Windows Authentication with Chrome and IIS

  1. I was about to dive into messing with this and was afraid of being greeted with a long day of testing settings and slamming my head on my desk and then I found your post. Two seconds to fix and it worked! Thank you so much for taking the time to post this.

  2. Dude – Where were you about 8 hours ago? I was having success with IE after bumping Negotiate below NTLM, and then had success with Firefox after disabling Extended Protection…but simply couldn’t get Chrome to work. I was at the end of my rope and ran across your suggestion thinking there wasn’t a chance it would work…and then… BLAMMO. Worked. You rock.

  3. We had the same issue and your solution solved it! I assume that the domain used Kerberos authenitication, so Negotiate somehow was affected.
    Thank you!

  4. i don’t know why everyone has been having this problem. I simply googled “iis windows authenticated users chrome” found this article and applied the suggestions. LeftyCoder should have tried that first! But seriously awsome – Thanks!

  5. CHEESE AND RICE! Thank you sooo much! Been banging my head against a wall for 2 days trying to hammer this out! Moving an ancient Classic ASP intranet net site running on Win Sever 2000, to a brand new IIS 8.5 box The odd thing was I created to HOST file entries to the same site on the dev server; one had the same URL as the production site, the other a dummy URL. The existing URL failed as explained above, however the dummy URL worked just fine in Chrome… removing the Negotiate option worked!

  6. A thousand thank yous kind sir. Everyone should know that it’s only necessary to move Negotiate *below* NTLM though.

    • People can definitely try moving “Negotiate” below “NTLM” and see if it works for them. I didn’t have any luck with that at the time I wrote this post or now (I just tried it again). Glad you got yours working!

  7. Worked for me too! Thanks!

    Further note:

    Before removing “Negotiate”, I wanted to make sure I would be able to put it back if something went wrong.

    So, I looked at the “Available Providers” dropdown, but there were TWO “Negotiate” options. “Negotiate:Kerberos”, and “Negotiate:PKU2U”.

    But in the list above, it says simply “Negotiate”. I didn’t know WHICH of the two options “Negotiate” might refer to.

    As it turns out, “Negotiate” is it’s own option, and the dropdown only shows what’s available and has NOT been chosen already.

    So, when you remove “Negotiate” from the list of providers, it will immediately appear in the dropdown list as it’s own option. You will have “Negotiate: Kerberos”, “Negotiate: PKU2U”, and just plain “Negotiate”.

    Hope that helps anyone reading…..

  8. Hi unfortunately this is not working for me. Basically I am creating an asp.net 4.5 web forms site. I configured it for Windows Authentication, and under IIS Express it works fine. When I created a website under IIS on Windows Server 2012 R2, I also configured Authentication as Windows and disabled Anonymous. Still IE will keep prompting me for the credentials. I supply them but they don’t work.

  9. I was getting this error when testing a web api from localhost. I had to remove the Negotiate from the applicationHost.config file in C:WindowsSystem32inetsrvconfig and C:UsersyourusernameDocumentsIISExpressconfig.
    Not sure if I have to remove it from both locations but I did anyway and it now works…..
    This post did guide me in the right direction…thank you

  10. epic! thank you very much. I started getting this error because I tried to mess with some SPN settings on a site that was working. the SPN broke it for chrome. then removing negotiate fixed it!

  11. Thank you for this post, this resolved the issue for when we were trying Chrome to access a custom .asp application. It also resolved an issue for us where we were getting continuous prompt asking for credentials on a client machine even though it worked ok on the server itself.

  12. This post has been very useful for me. I was able to replicate this problem by adding or removing the “Negotiate” provider from my Web directory in IIS.

    However I was told by the Server Admin here where I currently work that we could not remove this provider since the recommended domain authentication is by using Kerberos.

    Indeed this is the Microsoft suggestion as you can read here:

    Reasons to Use the Negotiate Package

    Allows the system to use the strongest (most secure) available protocol.
    Ensures forward compatibility for your application.
    Ensures that your application exhibits behavior that is in accordance with the security policy set by the customer.

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa378748(v=vs.85).aspx

    In my specific case I had two servers Dev and Staging and the problem was happening only in Chrome browsers consuming Staging.

    So I compared IIS settings and I found this: After comparing the settings of both IIS servers I’ve been able to determine what was causing the browser to prompt an authentication modal.

    The file is applicationHost.config located in C:WindowsSystem32inetsrvconfig

Leave a Reply

Your email address will not be published. Required fields are marked *