SPN (Service Principle Names) Quick Facts

I have put together a list of digestible facts about SPN to clear some of the confusion on this topic:

- SPN's do a similar job to CNAME records - they are simply a pointer to a service.

- They are made up of a service type (e.g. DNS, LDAP etc.), an instance name, an optional port number and the service name - for example:

In some circumstances user / service accounts are used to run a specific service - for example MSSQL or ADFS, in this case we must associate the service with the user by setting a SPN on the user (service) account as follows:

setspn -s http/<computername>.<domainname>:<port> <domain-user-account>

e.g.:

setspn -s http/mywebapplication.contoso.com CONTOSO\myserviceaccount 

or alternatively we could register a SPN against a computer account e.g.:

setspn -s http/mywebapplication.contoso.com web01.contoso.com

Typically when creating the initial AD forest / setup of AD you will find that there are a lot of SPN's that are automatically created - to review these you can run the following to list all SPN's registered to an object - in this case my DC:

setspn -l "dc01.contoso.com"

I quite often see tonnes of information about what SPN's are - although I rarely come across anyone decent explanations of why they are needed in the first place! So a common need is when you start to split applications (such as MSSQL, CRM, ADFS and so on) across different servers - you need to be able to pass user's credentials between the servers.

A typical example of this might be where a user accesses a web application - he is authenticated against IIS - although IIS itself has no permissions to access a database sitting behind the web frontend - rather it must use (impersonate) the end user's account to access the database - this is referred to kerboros delegation.

The service needs to be "accessible" across the kerboros domain - simply using a local account such as "NETWORK SERVICE" will not work as the account does not exist within kerboros's scope (i.e. the account does not exist on Active Directory.) So any service that needs to be authenticated by kerberos needs to have an SPN set.

-  You can also check registered SPN's by checking an object's (user account or computer account) properties within ADSIEdit.msc - there is an servicePrincipalName attribute.