Share via

IE prompts 3 times for credentials and fails with 401.1 error message while website is set to run on Windows Integrated Authentication under IIS 6.0

  • Article

Many a times while troubleshooting Kerberos related issues we have come across a situation where IE prompts 3 times for credentials and even after providing the correct credentials every time it fails with 401.1 error message.

First of all while using Kerberos authentication (Keep in mind I am not talking about Kerberos delegation here, this article is strictly meant for Kerberos Authentication) IE should not prompt you for credentials if you are already logged in the domain from your client machine and your user account has sufficient NTFS permissions on the website content folder.

So what it means if IE is prompting for credentials and failing with 401.1 error messages after 3 attempts? Any guesses!!!

The only reason why IE will prompt and fail with 401.1 error message is because the Kerberos ticket which IE is sending to the IIS is invalid , so what I mean by Kerberos ticket being invalid is that it does not belongs to a Account or Identity under which our Application Pool is set to run on IIS.

Let’s take an example here.

The URL which is used to browse the website: - https://abc.xyz.com (Fully Qualified Domain Name of the IIS server).

NetBIOS Name of the IIS server: - *abc*

The Account/Identity under which the Application Pool is running on IIS: - xyz/test (Domain User Account under xyz domain).

In the above scenario when a user from its client machine will request for https://abc.xy.com website, IE will prompt for credentials and after 3 attempts it will fail with 401.1 error message.

I know by this time many of you would have guessed that we need to set the HTTP SPN for "abc.xyz.com" under "xyz/test" account.

But do you know how IE will react if the above SPN's were not found?

So let’s assume that we don’t have the HTTP SPN for the "abc.xyz.com" under "xyz/test" a/c.

1) User will request the URL https://abc.xyz.com

2) IE will get an initial 401.2 error message from IIS referring that it only supports either "Negotiate, NTLM".

3) IE will not try to contact the KDC to get a service ticket for the name "http/abc.xyz.com".

The catch in the above step is that IE has only requested the service ticket by specifying the name of SPN, it doesn’t know under which account this SPN is set.

4) KDC will now search in its database to find if any SPN is set with the name “http/abc.xyz.com”, guess what?, KDC will find a HOST record for "abc.xyz.com" set under the NetBIOS name of the IIS server , since HOST SPNS are added by default for both "NETBIOS and Fully qualified domain name" for any object which becomes a part of Domain.

5) Since HOST SPNS are added for the "abc.xyz.com" name, KDC can issue a kerberos ticket for any service running under that name. But the ticket would be issued for "xyz/abc" account rather than for "xyz/test" account.

6) IE will get a Kerberos ticket from the DC, assuming that it is the right one, it will pass on that ticket to the IIS.

7) Now when IIS will try to get that ticket validated from DC, DC will reject that ticket because IIS would be validating that ticket against the xyz/test account.

8) Since IIS got an error message from DC, IIS will send the 401.1 error message to the IE, at this point of time IE will prompt you for credentials assuming that there is something wrong in your user credentials by which you have logged in, you will again try to provide the same credentials to IE which you have used while logging in the domain.

9) IE will again wrap your credentials under that false Service Ticket which is issued under the wrong account and will pass on to IIS, IIS will again send the 401.1 error message.

10) The step number 8 and 9 would be again repeated and after one more Prompt IE will simply display 401.1 error messages.

Now if somebody will try to capture the NETMON traces and would see how the communication is happening between the Client (IE) and the Server (IIS), you will only see a valid ( which is not actually valid from the perspective of Account under which it is issued) Kerberos ticket is sent to the IIS and IIS is just returning 401.1 error message.

You might think there is something wrong under IIS or it could lead you in way where you start verifying your network settings to see if somebody is modifying the Kerberos ticket while it is sent over IIS through HTTP protocol.

But in 99.9% cases it's an issue with the SPNS not set correctly under the Domain.

Let’s list out the cases under which wrong SPN could cause the above issue.

A) First and foremost the issue listed above could be one of the possibilities.

B) Duplicate SPN set for two different domain accounts, in this case you will see the above situation happening intermittently (will explain you in detail in my next blog).

C) HTTP SPN missing for the application pool identity but the same HTTP SPN is added for an account which is not used for the earlier application pool identity.

 

Note:- The above issue will never happen if *NO* SPNS were found (not even the wrong the SPNS) under the Active Directory for a given URL(In this type of issues IE will simply fall back on NTLM).

=================================================================================================================

Kerberos issues are pretty interesting to troubleshoot and I just love troubleshooting them.

Hope the above explanation will help!!

Nitin Gupta

Comments