In my site I have one folder that does not allow anonymous access. It is set up to use Integrated Windows Authentication as it is on an AD domain. The login works fine in Firefox, Chrome, even Safari, but not IE8. Has anyone encountered this before? I can't seem to find anyone else with a similar issue, except for where the login fails in all browsers of course.

  • Sorry for too many questions, but want to understand a bit more. What is the version of IIS? Is it a .net application and the folder is it on the same server or on another box? Sep 23, 2010 at 0:51
  • are you trying to get IE to login automatically, or can you not login at all? Jan 23, 2012 at 0:01

5 Answers 5


Chances are this is due to a broken SPN somewhere.

I suspect that the non-Microsoft browsers don't do Kerberos (or at least, don't do it in the same way as IE does).

This means that IE might be attempting a Kerberos logon, where the others might well be using NTLM.

If an SPN exists for http/www.example.com or host/www.example.com, and it isn't owned by the account that runs the Application Pool, that'd be a good reason for this type of break.

On Windows 2008 or later: SETSPN -X will check for duplicates; SETSPN -Q http/www.example.com will look for owners of that specific SPN.

Fix your SPN problem, and you'll probably fix IE logons being broken.

Other guidance might tell you to disable Integrated Windows Authentication in IE Advanced properties; that's a boneheaded move which breaks Kerberos for everything and covers up the problem.

More here.

  • 1
    I believe this answer is correct. My site using Windows Auth worked fine for IE and Chrome. Then I changed the site's Application Pool identity and following that authentication stopped working in IE -- though it worked in Chrome. IE would present the user/pass dialog, I would put in the appropriate credentials but login would fail. The fix for me (I believe) was disabling the Enable Integrated Windows Authentication option in IE settings.
    – kingdango
    Mar 29, 2012 at 20:16
  • SPN = Service Principal Name Nov 24, 2017 at 16:34

This was mentioned in passing in one of the comments, but I wanted to call it out specifically in case anybody else finds it useful. I was having this same problem and I was able to resolve it by changing the App Pool Identity. This is found under "Advanced Settings" for the given App Pool.

Someone had set this value to "AppPoolIdentity" but I had to set it back to "NetworkService" to fix the problem.

(I tried to post an image, but I need more reputation apparently. If someone upvotes this answer then I can add the image.)


The broken SPN answer appears to be correct. This means that you may need to point out the problem to your IT/IS department if you want to get Kerberos set up correctly.

I do not recommend the "disable the Enable Integrated Windows Authentication" solution, because it requires normal users to go in and click something that they may not even have permission to change depending on how administrators have configured IE.

In the event that the Kerberos setup isn't getting fixed anytime soon, the more flexible solution is to go to the app in IIS, click Authentication, highlight the Windows Authentication line (which should be marked enabled, with everything else disabled), and then click the "Providers..." link on the right. There will likely be two entries, "Negotiate" and "NTLM", with Negotiate on top. Move NTLM to the top. While this forces your site to use NTLM, which is a security risk, but it's the only option if Kerberos is unavailable.


Are you accessing the site by a fully qualified domain name? For instance, an intranet site might be accessible by "intranet" but IE8 will not think this is in your AD domain because it's "domain part" doesn't match. You'd have to use "intranet.example.com" where your AD domain is "example.com".

  • Out intranet is just a subfolder in the main site, so just www.example.com/intranet. I've tried putting the domain in the login box in front of the username, but that didn't make a difference.
    – CoreyT
    Jun 16, 2010 at 17:24

Chrome prompted once for my password and succeeded.

IE prompted 3x for my password and I get a 401 Unauthorized.

My issue ended up being that both IE and Chrome prompted me for credentials for two different servers. The reason for the prompting for credentials is likely due to a password change last week.

Chrome prompted me with my domain account. MyDomain\MyUserId

But IE prompted me for ThisServerUrl.com\MyUserId (which of course failed because that user doesn't exist on the server but even worse -- the URL has nothing to do with the server name -- M$ what are you thinking???)

Hopefully this will help the next poor sap with the same issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.