IT:AD:SetSPN
Summary
Put simply, an SPN mapping allows a service on a particular server to be associated with an account responsible for the management of the service, thereby permitting mutual Kerberos authentication.
To use mutual Kerberos authentication, the Windows security layer must be able to determine the account that a service is using.
With an SPN map defined in Active Directory (AD), the Windows account responsible for the service can be ascertained and used for Kerberos authentication.
This mapping is necessary because many clients will compose an SPN based on the hostname and port the client is connecting to.
Many services register SPNs for this reason; for example, Microsoft SQL Server registers an SPN if TCP/IP is enabled to facilitate Kerberos authentication, thereby avoiding the use of NTLM.
Detailed
Mutual Authentication
SPN's are about Mutual Authentication across a Network.
Mutual Authentication is when a Service authenticates itself to a Client, before a Client authenticates itself to a Service.
The reason for the Client having to authenticate itself to the Service before it can access the Service's resources is pretty obvious, but the Server authenticating itself to the Client is so that Client doesn't get spoofed across a Network.
Obviously Mutual Authentication is not required when the Client and the Server are on the same machine (no network traveral = no possibility of spoofing).
Delegated Authentication
The subject of Kerberos often comes up in the context of Delegation, which leads to a misunderstanding that the Kerberos provides Delegation.
It does not.
It's just that MS will not honour delegation across a netork unless it is absolutely sure both parties trust each other – ie, that Mutual Authentication has taken place.
Delegated Authentication Scenarios
In a simple/classic scenario, an authenticated web user accesses a website, who in turns uses it's AppPool's Identity to authenticate itself to and use the resources of a SQL Server service.
In a delegated scenario, the WebSite authenticate itself to SQL Server using the web users credentials.
But – importantly – the webserver in itself does not have the required ability to delegate and be that other person.
This is only the case when the web and SQL instances are on separate servers.
If they were on the same server you would not need to worry about SPNs.
Kerberos Authentication Service
For two parties to authenticate to each other safely, they turn to a Kerberos Authentication Service to authenticate them. Ie, AD.
Domain Users by default are registered in AD, and therefore can be authenticated in a Kerberos context.
Services – on the other hand – are not automatically registered in AD, and therefore have to be registered within AD before they can partake in Mutual Authentication.
This is done using a Service Principal Name.
A Service Principal Name
Officially, a service principal name (SPN) is the name by which a Client uniquely identifies an instance of a Service.
What this means is…
One does not Mutually Authenticate with a Service – a Service is not an identity/principal in itself – but with the identity backing the Service.
Hence, when registering a Service for mutual authentication, one combines the two concepts (authentication + anti-spoofing) by registering “the realm/domain's Principal/Identity that back the specific Service on a specific machine within the realm/domain.”
Note: for `Kerberos` to be able to assist in mutual authentication, both `Client` and server have to be in the same realm/domain.
How it works.
When a Client identifies the Service to communicate with, a Kerberos naming convention is used to create the SPN that identifies that Service.
When a Client wants to connect to a Service, the Client locates an instance of the Service, composes an SPN for that Service instance, connects to the Service, and presents the SPN for the Service to authenticate. [TODO:what exactly happens at this point?] When Kerberos requests are made to AD, it can translate the Kerberos SPN to the correct AD accounts.
Q: Why does it not just send the Account Name and be done with it, rather than the whole SPN? A: Because that would mutually be enough to identify the identity -- but not enough for specifying the identity on the server/port, required to authenticate the `Service` (not just the identity).
How is the Service Identity defined?
For Win32 services, a service installer specifies the logon account when an instance of the Service is installed. A service installer could complete the installation by composing the SPNs, and write them as a property of the principal account object in AD.
For an IIS hosted application, the Service identity will be the AppPool Identity,
Q: If a WCF service endpoint (ServiceA) hosted within an IIS hosted application that has an AppPool Identity of IdentityA, does one register an SPN for the `Service` Host/Port + AppPoolIdentity -- or can one register a *different* acount for the Identity?A: I'm *pretty sure* (not 100%) that one because a ServiceHost is actually a sub-program with its own threads, etc. running within the parent application, that the `Service` can have it's own Identity. How it gets specified, I'm not sure.