Kerberos Authentication – Fix Kerberos Authentication in IIS with .NET App

A Service Principal Name is a concept from Kerberos. It's an identifier for a particular service offered by a particular host within an authentication domain. The common form for SPNs is service class/fqdn@REALM (e.g. IMAP/mail.example.com@EXAMPLE.COM). There are also User Principal Names which identify users, in form of user@REALM (or user1/user2@REALM, which identifies a speaks-for relationship). The service class can loosely be thought of as the protocol for the service. The list of service classes that are built-in to Windows are listed in this article from Microsoft.

Every SPN must be registered in the REALM's Key Distribution Center (KDC) and issued a service key. The setspn.exe utility which is available in \Support\Tools folder on the Windows install media or as a Resource Kit download, manipulates assignments of SPNs to computer or other accounts in the AD.

When a user accesses a service that uses Kerberos for authentication (a "Kerberized" service) they present an encrypted ticket obtained from KDC (in a Windows environment an Active Directory Domain Controller). The ticket is encrypted with the service key. By decrypting the ticket the service proves it possesses the key for the given SPN. Services running on Windows hosts use the key associated with AD computer account, but to be compliant with the Kerberos protocol SPNs must be added to the Active Directory for each kerberized service running on the host — except those built-in SPNs mentioned above. In the Active Directory the SPNs are stored in the servicePrincipalName attribute of the host's computer object.

For more information, see: Microsoft TechNet article on SPN, Ken Hornstein's Kerberos FAQ

First, I would confirm that this is occurring from a client where IE shows that the site is in the Trusted Sites zone, and the Trusted Sites zone is configured for "Automatic logon with current username and password."

Next, I would suspect the http authorization header size may exceed the IIS limits. Integrated Kerberos authorization is quite susceptible to this issue due to the IIS limits are actually quite low, and it does not require that many group memberships to bloat the token over the limit.

Each and every request includes the user's Kerberos token in the http authorization header. Because the token is encoded, it is frequently much larger than the actual memory used.

You can increase the values using the following document:

Http.sys registry settings for Windows
http://support.microsoft.com/kb/820129

I would use the following values:

MaxRequestBytes - set to 1048576
MaxFieldLength - set to 65534

Another useful utility DelegConfig. You can drop this in as an application on any web site, and connect to get a nice useful report on how your Kerberos authentication is configured. This would need to be tested as the victim account (or a suitably configured test account taht is exhibiting the symptom in the victim's domain).

http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/delegconfig-delegation-configuration-reporting-tool.aspx

You may also need to review:

How to use SPNs when you configure Web applications that are hosted on Internet Information Services
http://support.microsoft.com/kb/929650

Specifically:

"In Active Directory, verify that the Account is sensitive and cannot be delegated check box is cleared for users who access the application."

"Verify that all computers that are part of the Kerberos process have consistent name resolution and are connected by Kerberos trust. For example, verify that the computers that are involved in the Kerberos process are in the same forest or are part of a cross-forest Kerberos trust."

"Verify that the token size does not exceed the value that is set for the MaxTokenSize property." (MaxTokenSize should be set to 65535).

Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port
http://support.microsoft.com/kb/908209

There are also some excellent tips in the following article.

https://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx

In particular, checking that the client is connect to the expected SPN, using NetMon or KerbSpy.