Kerberos configuration known issues (SharePoint Server 2010)

Applies to: SharePoint Server 2010

Kerberos authentication and non-default ports

There is a known issue where some Kerberos clients (.NET Framework, Internet Explorer 7 and 8 included) do not correctly form service principal names when attempting to authenticate with Kerberos enabled web applications that are configured on non-default ports (ports other than 80 and 443). The root of the problem is the client does not properly form the SPN in the TGS request by specifying it without the port number (as seen in the Sname of the TGS request).

Example:

If the web application is running at http://intranet.contoso.com:1234, the client will request a ticket for a service with a SPN equal to http/intranet.contoso.com instead of http/intranet.contoso.com:1234.

Details regarding the issue can be found in the following article:

• Configure Kerberos authentication (Office SharePoint Server 2007)

To work around this issue, register SPNs with and without port number. Example:

• http://intranet.contoso.com:12345

• http/intranet

• http/intranet.contoso.com

• http/intranet:12345

• http/intranet.contoso.com:12345

We recommend that you register the non-default port to ensure that if the issue is resolved in some future service pack or hot fix, the applications using the workaround will still continue to function.

Note that this workaround will not work if the following conditions are true:

• There is more than one web application running on a non-default port

• The web applications either bind to the host name of the server or bind to the same host header (on different ports)

• The web application IIS application pools use different service accounts

• http://server.contoso.com:5000 AppPool Id: contoso\svcA

• http://server.contoso.com:5001 AppPool Id: contoso\svcB

If these conditions are true, following the recommendation in this workaround will yield duplicate SPNs registered to different service accounts which will break Kerberos authentication.

If you have multiple web sites sharing a common host name running on multiple ports, and you use different IIS application pool identities for the web applications, then you cannot use Kerberos authentication on all web sites. (One application can use Kerberos, the rest will require another authentication protocol.) To use Kerberos on all applications in this scenario, you would need to either:

1. Run all web applications under 1 shared service account

2. Run each site with its own host header

Kerberos authentication and DNS CNAMEs

There is a known issue with some Kerberos clients (Internet Explorer 7 and 8 included) that attempt to authenticate with Kerberos enabled services that are configured to resolve using DNS CNAMEs instead of A Records. The root of the problem is the client does not correctly form the SPN in the TGS request by creating it using the host name (A Record) instead of the alias name (CNAME).

Example:

A Record: wfe01.contoso.com

CNAME: intranet.contoso.com (aliases wfe01.contoso.com)

If the client attempts to authenticate with http://intranet.contoso.com, the client does not correctly form the SPN and requests a Kerberos ticket for http/wfe01.contoso.com instead of http/intranet.contoso.com

To work around this issue, configure Kerberos enabled services using DNS A records instead of CNAME aliases. The hotfix mentioned in KB article will correct this issue for Internet Explorer but will not correct the issue for the .NET framework (which is used by Microsoft Office SharePoint Server for web service communication).

Kerberos authentication and Kernel Mode Authentication

Beginning in IIS version 7.0, there is a new authentication feature called Kernel Mode Authentication. When an IIS web site is configured to use Kernel Mode authentication, HTTP.sys will authenticate the client’s requests instead of the application pool’s worker process. Because HTTP.sys runs in kernel mode this yields better performance but also introduces a bit of complexity when configuring Kerberos. This is due to HTTP.sys running under the computer’s identity and not under the identity of the worker process. When HTTP.sys receives a Kerberos ticket, by default it will attempt to decrypt the ticket using the server’s encryption key (aka secret) and not the key for the identity the worker process is running under.

If a single web server is configured to use Kernel Mode authentication, Kerberos will work without any additional configuration or additional SPNs because the server will automatically register a HOST SPN when it is added to the domain. If multiple web servers are load balanced, the default Kernel Mode Authentication configuration will not work, or at least will intermittently fail, because the client has no way of ensuring the service ticket they received in the TGS request will work with the server authenticating the request.

To work around this issue you can do the following:

• Turn off Kernel Mode Authentication

• Configure HTTP.sys to use the IIS application pool’s identity when decrypting service tickets. See Internet Information Services (IIS) 7.0 Kernel Mode Authentication Settings.

  You may also need a hotfix when configuring HTTP.sys to use the application pool’s credentials: FIX: You receive a Stop 0x0000007e error message on a blue screen when the AppPoolCredentials attribute is set to true and you use a domain account as the application pool identity in IIS 7.0

Kerberos authentication and session-based authentication

You may notice increased authentication traffic when using Kerberos authentication with IIS 7.0 and greater. This may be related to Windows authentication settings in IIS, in particular:

For instructions on how to configure authentication persistence in IIS 7.0, see Implementing Access Control.

Kerberos authentication and duplicate/missing SPN issues

When configuring Kerberos authentication, it is easy to accidentally configure duplicate service principal names, especially if you use SetSPN -A or the ADSI Edit (adsiedit.msc) tool to create your SPNs. The general recommendation is to use SetSPN -S to create SPNs because the -S switch will check for a duplicate SPN before creating the specified SPN.

If you suspect you have duplicate SPNs in your environment, use the SetSPN -X command to query for all duplicate SPNs in your environment (Windows 2008 or greater only). If any SPNs are returned you should investigate why the SPNs have been registered and delete any SPNs that are duplicates and are not needed. If you have two services running with two different identities and both use the same SPN (duplicate SPN issue) you need to reconfigure one of those services to either use a different SPN or share a common service identity.

If you suspect a SPN has not been registered, or not registered in a format required, you can use the SetSPN -Q <insert SPN> to query for the existence of a particular SPN.

Kerberos Max Token Size

In some environments, users may be members of many Active Directory groups, which can increase the size of their Kerberos tickets. If the tickets grow too large, Kerberos authentication can fail. For more information about how to adjust the max token size, see New resolution for problems with Kerberos authentication when users belong to many groups (https://support.microsoft.com/kb/327825).

Kerberos authentication hotfixes for Windows Server 2008 and Windows Vista

A Kerberos authentication fails together with the error code 0X80090302 or 0x8009030f on a computer that is running Windows Server 2008 or Windows Vista when the AES algorithm is used (https://support.microsoft.com/kb/969083).

You may need to install a hotfix for Kerberos authentication on all computers that are running Windows Server 2008 or Windows Vista in your environment. This includes all computers that are running SharePoint Server 2010, SQL Server, or Windows Server 2008 that SharePoint Server attempts to authenticate with by using Kerberos authentication. Follow the instructions in the support page to apply the hotfix if you experience the symptoms documented in the support case.