Kerberos in Multi-Tier Applications - Part 1 - Properly Configuring SPNs

Understanding how to correctly configure Kerberos in multi-tier applications, such as FIM, seems to be an elusive skill in not only identity folks, but even in well-seasoned IT people.  Even the most well-known and respected people get it wrong. It’s a very confusing topic. When I explain this to someone, it sometimes takes multiple conversations with the same person to help them understand it. Nothing to do with the person’s technical skills – it’s just a really complex topic if you’re not used to working with it.  To make this a little more digestible, I’m going to split this discussion into two posts.

In this first post, I’m going to explain why a Service Principal Name (SPN) is important and how to properly set one.

A Little Background on Kerberos

Before we can look at what an SPN is, you first have to have a decent understand of the basics of Kerberos.  In a nutshell, this is how it works – when a client (a user on a Windows 7 workstation, for example) wants to authenticate and use a resource on the network (such as a file share on a file server), the client gives the server a Kerberos ticket, which provides proof of the client’s identity.

To get a ticket, the client goes to a Key Distribution Center (such as a Domain Controller) and asks for one. The KDC will create a ticket and put some information inside. Here is some of the information in the ticket:

  • Principal of the user
  • Principal of the service hosting the resource
  • Timestamp indicating the date and time that the ticket becomes valid
  • Lifetime of the ticket
  • Session key that the client and server can use to establish an encrypted connection with

This ticket is encrypted with a shared secret that only the KDC and the Server hosting the resource knows. The KDC gives the ticket to the user, along with a copy of a session key, which both the user and the Server will know.  The user, in turn, gives the ticket to the Server and also sends the Server some data along with it (the user principal and timestamp – also known as the Authenticator), which is encrypted with the session key.

The Server decrypts the ticket with its copy of the secret (the one that is known only by the Server and the KDC) and it extracts the session key (the same one that the user got a copy of from the KDC) from the ticket. The Server can then use that session key to decrypt the Authenticator that the user sent over to it. If the Server can successfully decrypt the Authenticator, it knows that the user’s identity was verified by the KDC.

So, let’s recap on what happened in english, using the example of a user accessing a file share on a Windows Server:

  1. The user decides that he wants to connect to the file share
  2. The user goes to the Domain Controller (KDC) and says – “Hey, Mr. DC, I need a Kerberos ticket for this here file share so I can prove my identity to it”
  3. The DC says – “Sure, let me build a session key for you guys to talk securely with”
  4. The DC then looks in its database (Active Directory) and looks up the account that the file server is running under (the computer account of the server)
  5. The DC uses the secret in the computer account to encrypt the ticket it creates
  6. The DC sends the ticket and the session key back to the client
  7. The client sends the ticket and the encrypted Authenticator to the file server and says “Here you go – here’s proof of my identity and here’s the ticket to verify it”
  8. The file server decrypts the ticket, extracts the session key, and uses it to decrypt the Authenticator
  9. The file server says “OK, you’re good to go – here’s the data you want”

Where’s the SPN Used?

So now you might be asking – “what does this have to do with SPNs?”  A lot, actually. The key piece that SPNs are needed for are in step #4 of what I described above. In order for the DC to give a client a session ticket, it needs to know who the ticket is for and what secret to encrypt it with. And that’s where the SPN comes into play.

The SPN is all about helping the DC figure out which account to encrypt the session ticket for. Let’s look at it another way… let’s say that the situation is a user connecting to a SharePoint web site with Internet Explorer and trying to authenticate with Kerberos. In this case, the user goes to the DC and says – “Hey, Mr. DC, I need a Kerberos ticket for sharepoint.contoso.com.”   This should start making more sense about now…

You see, the web browser can’t ask for a Kerberos ticket for the server named CONTOSO-SHR01 because it has no idea what the name of the server is. The only thing the client knows to tell the DC is – “give me a ticket for sharepoint.contoso.com”. The DC has to figure out which account sharepoint.contoso.com is running under.  And the way it does this is by looking in Active Directory and finding the account that has the servicePrincipalName (SPN) attribute that matches sharepoint.contoso.com. Once the DC finds the account that the sharepoint.contoso.com web site is running under, it knows what secret to use to encrypt the session ticket.

Now you should also understand why duplicate SPNs are a problem. If more than one account has the same SPN, then the Domain Controller gets confused because it doesn’t know which account to encrypt the Kerberos ticket for.

What Does an SPN Look Like

As I just mentioned, SPNs are configured on the servicePrincipalName attribute of security principals in Active Directory – this applies to both user accounts and computer accounts. The servicePrincipalName attribute is a multi-valued attribute, because a security principal can have multiple SPNs. This makes sense, as a single account might host more than one service.

The actual SPN itself is presented in the format of: Service/Hostname

This is important because it adheres to the Kerberos v5 standards for service principals. Here are a couple of examples:

Service

Host Name

SPN

Web Site

www.contoso.com

HTTP/www.contoso.com

SQL

sqlserver1.fabrikam.com

MSSQLSvc/sqlserver1.fabrikam.com

File Share

fileserver03

HOST/fileserver03

 

You may have noticed that in the “File Share” example, the SPN uses HOST as the Service portion of the name. The HOST service is a generic representation of any service that runs under the context of the server’s security principal. In general, these are services that are provided by the Operating System. The computer account in Active Directory owns the HOST SPN. In the following screen shot, you’ll notice that this particular server (CONTOSO-WEB1) owns the SPNs for both the NetBIOS name and the FQDN, since a client could potentially use either SPN when getting a Kerberos ticket for the server – it entirely depends on how the client application that is requesting the Kerberos ticket works.

Setting a Proper SPN

So to recap – here are the rules to follow if you want to properly set an SPN.

  • The SPN must be in the format of Service/Hostname
  • The SPN for a service can only be attached to one account
  • The account that has the SPN has to be the account that receives the Kerberos ticket – this may be either a dedicated user account (also known as a Service Account)  or the computer account that belongs to the server
  • An account can have as many SPNs as you want
  • Use the HOST SPN for services that are running under the principal of the server’s computer account in Active Directory

So if you’re running SharePoint under a dedicated service account named CONTOSO\svc-sharepoint then the svc-sharepoint account in Active Directory needs to have the following entry in the servicePrincipalName attribute: HTTP/sharepoint.contoso.com.  It needs this so the Domain Controller knows which account to get the Kerberos ticket for when a user tries to connect to the SharePoint site.