Compartilhar via

Internet Explorer behaviors with Kerberos Authentication

  • Artigo

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

Comments

  1. Access to both servers works fine for hundreds of users.
  2. For a very limited number of users access works fine for server A but not for server B if access is done with Internet Explorer (same issue with IE6 and IE8). For these users, access works fine for both servers if they use Firefox or Chrome.
  3. When I check their event log, I can see: "The kerberos SSPI package generated an output token size of size 3514 bytes, which was too large to fit in the 3510 buffer provided by process id 0." The solution to this issue was to reduce the number of groups of the impacted users. My question: how is it possible that access was working for one server and not the other one before the group reduction? Thanks, Benoit

  • Anonymous
    December 17, 2010
    Hey BugBunny69, From the error you are stating that you are seeing it sounds like you have a problem with your Kerberos ticket size.   By default a Kerberos ticket can only be 12k in size, but is allowed to get to 65,535.  You can use the MaxTokenSize registry key value to set this. However, with IIS, since the Kerbeos ticket is sent in the HTTP header, you are also going to run into a problem there also because by default (for security reasons) the HTTP header size is only allowed to be 16k. So you will need to make some changes within IIS, and every computer in the mix and add MaxTokenSize to them (you can exclude domain controllers) MaxTokenSize: 938118 How to use Group Policy to add the MaxTokenSize registry entry to multiple computers support.microsoft.com/default.aspx 327825 New resolution for problems with Kerberos authentication when users belong to many groups support.microsoft.com/default.aspx NOTE:  The hotfix is not needed unless you are on Windows 2000. Also, just as a side note, if you make sure that your forest / domain functional levels are atleast Windows Server 2003, you might fix your self if you are currently at Windows 2000 levels.  This is because we use RID values for global group memberships after that. For IIS 6 and above you need to modify the following two registry keys: MaxRequestBytes MaxFieldLength 2020943 "HTTP 400 - Bad Request (Request Header too long)" error in Internet Information Services (IIS) support.microsoft.com/default.aspx Hope this helps. Rob Greene

  • Anonymous
    December 21, 2010
    The comment has been removed

  • Anonymous
    December 23, 2010
    Hey bugbunny69, As far as one IIS Server working vs another could be as simple as the required group membership is in the truncated token on the working vs missing on the failing logon. If you are not seeing an answer to the 401.1 with www-negotiate response from the IIS server then it sounds like you need to troubleshoot IE if it is not sending any response back. You will want to make sure that the site you are going to shows up in the intranet zone.  After that I would suggest opening a case with our IE team. HTH, Rob Greene

  • Anonymous
    May 27, 2015
    The comment has been removed