Internet Explorer behaviors with Kerberos Authentication

  • Article

Hey Rob here again, I thought that I would share with you some of the things that we see where Internet Explorer Kerberos authentication fails.

It is important to understand the default behavior of Internet Explorer and its support for Kerberos authentication so that you don’t start ripping out your hair (can’t speak to what Ned does here). I have listed three very common problems that we typically see when Kerberos authentication is failing with web-based applications.

Scenario 1: Website does not use the standard TCP/IP port of (80/443)

Web Server Configuration:
  • Webserver1 has two different IIS sites running on it.
  • Website1 runs with a web application pool account assigned to NetworkService.
  • Website2 runs with a web application pool account assigned to a domain user account.
  • The website2 is configured to listen on Port 8080.
  • The following SPN’s have been defined on the website2 application pool account.
    • http/webserver1.contoso.com:8080
    • http/webserver1:8080

In this scenario you can see why a non-standard port is being used since multiple websites have been configured on the same web server. When this happens you need to specify the port to be used when you add the Service Principal Name, otherwise there is going to be a high likely hood that you will get a Kerberos ticket for the wrong web application pool account.

Client Workaround

In this scenario you need to make sure that when Internet Explorer accesses Website2 that it asks for a Service Principal name with the port number defined. However, the default behavior of IE is to not add the port number to the Kerberos ticket request. When this ticket is presented to IIS you will see a KRB_AP_ERR_MODIFIED message back.

You will need to use the below KB article change the default behavior on all IE client versions. For Internet Explorer 6 it will require the QFE Brach of Wininet.dll to be installed before the registry change will actually work.

908209 Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003 - https://support.microsoft.com/default.aspx?scid=kb;EN-US;908209

I can tell you that there is not a version of this KB article for IE7 and above, but you do have to make the same registry change for these versions of IE also.

Server Workaround:

There really is not a good workaround to the issue other than to use host headers for one of the websites and adding a DNS HOST record for the host header in your DNS configuration. You will see shortly why we are not recommending a CNAME record in DNS.

Scenario 2: CNAME DNS RR is used for a website.

Web Server Configuration:
  • Webserver1 has two different sites running on it.
  • Website1 runs with a web application pool account assigned to NetworkService.
  • Website2 runs with a web application pool account assigned to a domain user account.
  • Website2 is configured to us a host header of app1.contoso.com.
  • In DNS a CNAME record for app1.contoso.com was created and pointed to webserver1.contoso.com HOST record.
  • The following SPN’s have been defined on the website2 application pool account.
    • http/app1.contoso.com
    • http/app1

In this scenario it appears that this should work just fine. When a user goes to app1.contoso.com the client machine is going to do a DNS lookup, and the DNS server is going to respond with the CNAME record and point to the webserver1.contoso.com HOST record. We can also see that the Service Principal Name configuration is properly configured on the web application pool account for website2.

The default behavior of Internet Explorer is to generate the Kerberos ticket request for the HOST record that is returned from a CNAME record, not the actual CNAME record itself. So IE specifically asks for a Kerberos ticket for http/webserver1.contoso.com which will result in a Kerberos ticket being generated encrypted with the WebServer1 computer’s password. This will in turn generate a KRB_AP_ERR_MODIFIED from IIS back to IE when the user attempts to visit the app1.contoso.com website.

Client Workaround

You will need to use the KB articles below to change the default behavior on all IE versions. For IE 6 it will require the QFE Brach of Wininet.dll to be installed before the registry key change will actually work.

For Internet Explorer 6:

911149 Error message in Internet Explorer when you try to access a Web site that requires Kerberos authentication on a Windows XP-based computer: "HTTP Error 401 - Unauthorized: Access is denied due to invalid credentials" - https://support.microsoft.com/default.aspx?scid=kb;EN-US;911149

For Internet Explorer 7 and above:

938305 Error message when you try to log on to a Web site that requires Kerberos authentication by using Internet Explorer 7: "Access is denied due to invalid credentials" - https://support.microsoft.com/default.aspx?scid=kb;EN-US;938305

Server Workaround:

The only work around is to remove the DNS CNAME RR and replace it with a HOST RR.

Scenario 3: Website works on first access but starts failing 30 minutes later

Web Server Configuration:
  • Computer Webserver1 one site on it.
  • Website1 runs with a web application pool account assigned to a domain user account.
  • The following SPN’s have been defined on the website1 application pool account.
    • http/webserver1.contoso.com

When a user visits the website they use the NETBIOS computer name for the URL to visit. For example: https://webserver1.

In this scenario there does not seem to be much wrong here, except that there is only the FQDN version of the Service Principal Name defined. Yeah, I know all of our documentation around Kerberos always states to add FQDN as well as NETBIOS name versions of the SPN. Believe it or not, we see this all the time where the user did not register both of them, but stick with me here.

The default behavior of Internet Explorer is to add on the computer’s DNS suffix or use DNS suffix search order if defined on the machine to whatever the user types in the URL if it is not a dotted name. If your DNS configuration is correct it will resolve to webserver1.contoso.com. Once IE finds this name it stores the DNS entry in its own DNS cache. Just like most caches it times out - for IE’s cache it is 30 minutes. After 30 minutes IE again has to resolve the name, however the next time it does not try to resolve the name through DNS again, it tries just NetBIOS name resolution (hopefully there is WINS in the environment; otherwise it will just fail). Based on your configuration you could expect one of the following Kerberos errors:

  • KRB_AP_ERR_MODIFIED – Expect to get this error if web site name is the same name as your web server’s computer name. That is because it is going to ask for an http/webserver1 SPN and will resolve to HOST/webserver1 which is assigned to the computer account.
  • KRB_ERR_S_PRINCIPAL_UNKNOWN – Expect to get this error if the web site name is something like app1.contoso.com. That is because it is going to ask for an http/app1 SPN and will not resolve to any account in the domain.
Client Workaround:

Thankfully there is a fix that can be implemented for Internet Explorer.

899417 You may receive an "Access is denied" error message you use the WWW-Authenticate: Negotiate method of HTTP authentication to connect to a Web server - https://support.microsoft.com/default.aspx?scid=kb;EN-US;899417

I will tell you that there is not a version of this KB article for IE7 and above, but you do have to make the registry key change for these versions of IE also before the functionality is supported.

Server Workaround:

You can register the NetBIOS version of the Service Principal Name to the account, using SETSPN.EXE.

I hope that you found this post interesting. As always it is easier to spot these type of issues by reviewing network trace taken at the client side (where IE is being used) to find the root cause of the issue.

- Rob “I Speak Tampa” Greene