Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Quelqu'un peut-il expliquer les noms de principal de service Windows (SPN) sans trop simplifier ?

ayi

I have wrestled with service principle names a few times now and the <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms677949%28v=vs.85%29.aspx" rel="noopener nofollow ugc">Microsoft explanation</a> 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 <a href="http://blogs.msdn.com/b/webtopics/archive/2009/01/19/service-principal-name-spn-checklist-for-kerberos-authentication-with-iis-7-0.aspx" rel="noopener nofollow ugc">http specific SPNs on the windows service account</a> 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.

ayi_2

A Service Principal Name is a concept from <code>Kerberos</code>. It’s an identifier for a particular service offered by a particular host within an authentication domain. The common form for SPNs is <code>service class</code>/<code>fqdn</code>@<code>REALM</code> (e.g. <code>IMAP/mail.example.com@EXAMPLE.COM</code>). There are also User Principal Names which identify users, in form of <code>user</code>@<code>REALM</code> (or <code>user1</code>/<code>user2</code>@<code>REALM</code>, which identifies a speaks-for relationship). The <code>service class</code> can loosely be thought of as the protocol for the service. The list of service classes that are built-in to Windows <a href="http://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx">are listed in this article from Microsoft</a>.
Every SPN must be registered in the <code>REALM</code>’s Key Distribution Center (KDC) and issued a service key. The <code>setspn.exe</code> utility which is available in <code>\Support\Tools</code> 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 <code>servicePrincipalName</code> attribute of the host’s computer object.
For more information, see:
<ul>
<li>
<a href="https://learn.microsoft.com/en-us/windows/win32/ad/service-principal-names">Microsoft Learn article on SPN</a>
</li>
<li>
<a href="http://www.faqs.org/faqs/kerberos-faq/general/">Ken Hornstein’s Kerberos FAQ http Link</a>
</li>
<li>
<a href="https://web.fe.up.pt/%7Ejmcruz/etc/segur/kerberos/faq.html">Ken Hornstein’s Kerberos FAQ https 
Link</a>
</li>
</ul>