Kerberos configuration known issues (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 articles:

• 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 (http://support.microsoft.com/kb/908209/en-us)
• Configure Kerberos authentication (Office SharePoint Server 2007) (http://go.microsoft.com/fwlink/p/?LinkId=196987)

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
   
   
   Reference : http://technet.microsoft.com/en-us/library/gg502606%28v=office.14%29.aspx