Otdfbt

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.

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.

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

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

But IE prompted me for ThisServerUrl.comMyUserId
(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.