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

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

ayi

J'ai wrestled avec service principle names a peu de times now et le Microsoft explanation is juste pas sufficient. Je suis configuring an IIS application to work on our domain et it looks like certains of mon issues are related to mon need to configure http specific SPNs on the windows service account that is running le application pool hosting mon site.

All this has made me realize I juste ne fully get le relationship entre service types (MSSQL, http, host, termsrv, wsman, etc.), Kerberos authentication, active directory computer accounts (PCName$), windows services accounts, SPNs, et le user account Je suis using to try et access a service.

Can someone please explain Windows Service Principle Names (SPNs) sans oversimplifying le explanation?

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

ayi

A Service Principal Name is a concept depuis Kerberos. C'est 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/mail.example.com@EXAMPLE.COM). Il y a aussi User Principal Names qui identify users, in form of user@REALM (or user1/user2@REALM, qui identifies a speaks-for relationship). The service class can loosely be thought of as le protocol for le 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 le REALM's Key Distribution Center (KDC) et issued a service key. The setspn.exe utility qui is disponible in \Support\Tools folder on le Windows install media ou as a Resource Kit download, manipulates assignments of SPNs to computer ou autre accounts in le AD.

When a user accesses a service that uses Kerberos for authentication (a "Kerberized" service) they present an encrypted ticket obtained depuis KDC (in a Windows environment an Active Directory Domain Controller). The ticket is encrypted avec le service key. By decrypting le ticket le service proves it possesses le key for le given SPN. Services running on Windows hosts use le key associated avec AD computer account, mais to be compliant avec le Kerberos protocol SPNs must be added to le Active Directory for chaque kerberized service running on le host — except those built-in SPNs mentioned above. In le Active Directory le SPNs are stored in le servicePrincipalName attribute of le host's computer object.

For more information, see: