I've had a few encounters with Kerberos so, as a result, I decided to collect what I have learnt together in a series of blog posts. Primarily my concern is with regards to enabling Kerberos Authentication for SharePoint, but I will add some general information, too.
Enabling Kerberos offers a few advantages over NTLM, it:
- Is less susceptible to replay attacks because it includes a timestamp of when the network traffic was sent
- Allows verification of servers through the use of Service Principal Names (SPNs)
- Reduces authentication traffic because authentication is valid until the tickets expire (or are manually purged)
- Allows authentication over multiple hops (via the use of delegation).
The last point is frequently the driving force in enabling Kerberos for SharePoint, although reduced authentication traffic and increased performance are also often cited. An example of where we might need authentication over multiple hops would be where we need to authenticate with a SharePoint Web Application, our credentials have to be passed on to a web service and this web service has to pass our credentials to SQL to retrieve data from a database. This is only possible if Kerberos is enabled and the intermediate accounts are trusted for delegation in Active Directory.
Concepts
There are some concepts key to Kerberos which are worth understanding. This is a very basic level understanding of them but hopefully will provide some insight.
What is a Service Principal Name?
An SPN is a string constructed using an arbitrary text name for a service, the computer name that the service is running on and the port. This then appears in the following format:
ServiceName/Computer:Port
An example would be MSSQLSvc/sqlserver01:1433
It is used to allow a client to uniquely identify an instance of a service.
To enable Kerberos we need to configure a mapping in Active Directory between SPNs and the account that the service is supposed to be running under. To do that, we either use ADSIEDIT or SETSPN (found in the Windows Server Support Tools or downloadable from Microsoft). You must at least be a domain administrator to perform these updates.
SETSPN
SETSPN is a command–line tool and has 3 switches that we're interested in:
–A to add an arbitrary SPN
–D to delete an arbitrary SPN
–L to list registered SPNs
The syntax we'll use is as follows:
setspn –A service/computer:port domain\user
setspn –D service/computer:port domain\user
setspn –L domain\user
Computer may be the NetBIOS name, Fully Qualified Domain Name (FQDN) or another DNS name – more about this later.
How Kerberos Works (very briefly)
Kerberos is an authentication service developed at MIT. The idea behind Kerberos is that both the user and service have a shared key and this is used to encrypt and decrypt something freshly created (for example a timestamp). If the wrong key is used at either end, decryption is not possible and authentication fails. In practise, what occurs is much more complicated, but this is the very basic idea.
When using Kerberos in a Microsoft environment, broadly speaking, the following occurs. A Kerberos authentication server will grant a ticket in a response to a client computer authentication request, as long as the request contains valid user credentials and a valid SPN (see above). This ticket can be used to access network resources. For the lifetime of the ticket (by default, it is 600 minutes, i.e. 10 hours) a new ticket does not have to be issued and this is how authentication traffic is reduced. For Kerberos to work, both the client and server must have a trusted connection to the domain Key Distribution Centre (KDC). The KDC distributes the shared secret keys to allow encryption to take place. Both computers also need to be able to access Active Directory directory services and the forest root domain is the centre of Kerberos authentication referrals.
In the next part I'll move on to talking about configuring Kerberos.