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.
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 isservice class
/fqdn
@REALM
(e.g.IMAP/[email protected]
). There are also User Principal Names which identify users, in form ofuser
@REALM
(oruser1
/user2
@REALM
, which identifies a speaks-for relationship). Theservice 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. Thesetspn.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
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:
The entire article is here: https://docs.microsoft.com/en-us/archive/blogs/askds/kerberos-for-the-busy-admin