Ken Schaefer

Apologies for the delay in posting Part 2 - I've been on holidays so it's been a bit hard finding the time to write these posts. In this part we cover Service Principal Names (SPNs). 

In a previous post we covered the basics of Kerberos authentication. Everything is relatively straitforward, however I didn't cover the one particular aspect. Namely, how does the Authorisation Service (AS) and remote Service share their shared secret?

In an Active Directory domain, all computer and user objects have a password. This password is used as the basis of the shared secret between the AS and the remote service. If the remote service is running under an inbuilt principal such as LocalSystem or Network Service then the computer account's password is used as the basis of the shared secret. If the remote service is running under a custom user account, then the user account's password is used as the basis of the shared secret.

So how does the AS know which user or computer account's password should be used? When a user wishes to connect to a remote service, it tells the Domain Controller what Kerberos service it wishes to connect to. The AS searches through Active Directory to find a matching Service Principal Name (SPN). SPNs are attributes of user and computer objects in the directory. For example, for the computer w03-svr-sql we can see the following SPNs (using ADSIEdit):

SPNs can be viewed, added and removed using a GUI tool like ADSIEdit, or you can do the same using a command line tool such as SetSPN (part of the Windows 2000 Resource Kit).

Generally, when installing a product such as SQL Server or IIS that supports Kerberos, SPNs are registered for you for the accounts that those products are configured to use. However you later change the user account that the services are running under, you may need to set a new SPN for that Kerberos authentication continues working.

This method of determining the shared secret to be used between the AS and remote service raising a couple of gotchas which can break Kerberos Authentication:

1) The missing SPN
When installing IIS (and a lot of other common services) the installer will register a set of default SPNs in the Directory. However if you change the way that your service runs after installation, you may need to update the SPNs that are registered.

For example, after installing IIS, SPNs for servername and servername.domain.tld are registered under the server's computer account in Active Directory. These SPNs will allow Kerberos authentication to work when using the following built-in service principles: LocalSystem, Network Service or Local Service as the identity for your worker processes.

However if you change the process identity of your web application pool, and assign its worker process a custom domain user acccount as a process identity, then you will need to create SPNs for servername and servername.domain.tld under this custom user account. This allows the KDC to encrypt the service ticket with the password of the user account rather than the computer account.

2) The duplicate SPN
In the event that an SPN for the same service is registered under multiple accounts in Active Directory (e.g. under a computer account and a user account), then the KDC will not know which password should be used to encrypt the service ticket, and Kerberos Authentication will fail.

In the above scenario, once you change the identity of your web application pool, and add the new SPNs for servername and servername.domain.tld, you may need to remove the existing SPNs from under the computer account. Likewise, if you change the process identity from one user account, to another user account, you would most likely need to remove the SPNs from the first user account, and add them to the second user account.

3) Load-balanced IIS solutions
In this situation, the user's request might be routed to either of the two (or more) nodes in your cluster. In this case, you can not run your web application pools under an inbuilt principal (such as Network Service), because the KDC can not know which computer account's password should be used (it does not know which node in the cluster the request will be routed to). In this situation you must use a common domain user account as the process identity of your worker processes.

4) Multiple web applications hosted at a single domain name
Because SPNs are organised by name (either NetBIOS or fully qualified domain name), all web applications hosted at that domain name must be running in worker processes utilising the same, common, identity. This is so that the KDC can generate a service ticket using that identity, no matter what web application is being accessed at the FQDN. You can still run the web applications in separate web application pools, but each pool must be running under the same, common, identity.