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

  • Roeland

    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.

  • Chris

    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.

  • 48091

    I had this same issue, did the same resolution, and also got a low of BLAMMO! Thanks!

  • Samuel Mnisi

    Dude, Where have you been? I have been struggling for the last 3 weeks on Dynamics CRM. Thanks a lot

  • Mousa M. Abdeljaber

    man…you rock!
    I have no idea why it works this way 🙂 but it works…

  • Jignesh Surati

    Yes.. perfect solution.

    Many thanks

  • Joseph Corbett

    I want to have your adopted babies…

  • Paul Scott

    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!

  • pjh64

    Great post – thank you!

  • rod baldwin

    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!

  • Adam Tokarski

    Awesome – that works! Thanks for that post!

  • 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!

  • Christopher J. McClellan

    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!

  • Robert Zeurunkl

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

  • Shehzad Baichoo

    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.

  • Joshua Austill

    Thank you, doesn’t seem like enough in this case…

  • Charlie Brown

    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

  • sim_pro

    Works like a charm!

    Thanks!

  • Max Struever

    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!

  • isotonic uk

    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.

  • fedu

    If your password has changed, change it to (Windows Credentials): Control PanelUser AccountsCredential Manager

  • Townboy

    Which means kerberos doesn’t work?

    • Daniel Lemur

      See my commnet.

  • Daniel Lemur

    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