Can someone please explain Windows Service Principle Names (SPNs) without oversimplifying?

I have wrestled with service principle names a few times now and the Microsoft explanation is just not sufficient. I am configuring an IIS application to work on our domain and it looks like some of my issues are related to my need to configure http specific SPNs on the windows service account that is running the application pool hosting my site.

All this has made me realize I just don't fully get the relationship between service types (MSSQL, http, host, termsrv, wsman, etc.), Kerberos authentication, active directory computer accounts (PCName$), windows services accounts, SPNs, and the user account I am using to try and access a service.

Can someone please explain Windows Service Principle Names (SPNs) without oversimplifying the explanation?

Bonus points for a creative analogy that would resonate with a moderately experienced system administrator/developer.

Solution 1:

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/[email protected]). 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

Solution 2:

yarek's answer was great, and I upvoted it, but I also wanted to give you a little bit more Windows-specific information on the topic, or rather coming from the perspective of someone who is more familiar with AD than just Kerberos in general, just because this is a topic that interests me greatly.

I felt like this guy did an excellent job of explaining it, and I recommend you read his article, but here is an especially concise paragraph right toward your question:

"Service Principal Names define what services run under the accounts security context. For example some of the services that a computer might have are File server / CIFS (Common Internet File System), if it is a domain controller it is going to have an LDAP SPN, and Active Directory Replication SPN, and FRS SPN. Service Principal Names can be defined on user accounts when a Service or application is running under that users Security context. Typically these types of user accounts are known as “Service Accounts”. It is very import that you understand that Service Principal Names MUST be unique throughout the entire Active Directory forest."

The entire article is here: https://docs.microsoft.com/en-us/archive/blogs/askds/kerberos-for-the-busy-admin