Overview
Service Principal Name (SPN) is a field in Active Directory (AD) against a user account that is used to store details of the services for which the account is authorised to receive delegated authentication for Kerberos authentication. It is, essentially, a mapping between user accounts and services, and is required for Kerberos authentication. For example, user account ServiceA may be authorised to run SQL Server on Server1, in which case one of the possible SPNs would be:
MSSQLSvc/Server1 Domain\ServiceA
Querying
To return the SPNs registered against a user account, use:
setspn -L {account name}
To return the details of an SPN, use:
setspn -Q {SPN}
Duplicates and manual modifications
Duplicates
An SPN registration is a one-to-one mapping from user account to service. If a duplicate exists in AD for a service, i.e. if a service is listed against more than one user account, the registration will be in error and Kerberos authentication will not function.
The current domain may be queried for duplicates by running:
setspn -X
Manual removals
Duplicates and other entries may be carefully removed using:
setspn -D {SPN} {account name}
Manual additions
When registering an SPN, ensure that an entry is added for every possible name by which the service can be accessed, such as the NetBIOS name and FQDN, and also any ports or instance names that may be used. For example, for SQL Server, all of the following are valid for a single instance and should, ideally, all be registered:
MSSQLSvc/Server1:1433 Domain\ServiceA MSSQLSvc/Server1.domain.local:1433 Domain\ServiceA MSSQLSvc/Server1:MSSQLSERVER Domain\ServiceA MSSQLSvc/Server1.domain.local:MSSQLSERVER Domain\ServiceA MSSQLSvc/Server1 Domain\ServiceA MSSQLSvc/Server1.domain.local Domain\ServiceA
To manually add an SPN, use:
setspn -S {SPN} {account name}
NB: using -S performs a check for duplicates in the domain before creating the registration. If a duplicate is found, no modification of AD takes place.
Automatic registration
Many applications will attempt to automatically register the SPNs applicable to their service. To do so, the context under which the service executes, i.e. the user account, must have permission to modify this field in AD on its own object.
Service types
This is a non-exhaustive list of SPN service types.
| Type | SPN name | Notes |
| SQL Server (OLTP) | MSSQLSvc | For instances with the default name, there should be three registrations for each server name by which the service will be accessed: (1) by port, (2) by instance name and (3) without a port or instance name. For instances with a specified name, there should be two registrations for each server name by which the service will be accessed: (1) by port and (2) by instance name. |
| SQL Server: SSAS | MSOLAPSvc.3 | |
| SQL Server: SSRS | HTTP | |
| SCOM: RMS (emulator) and management server | MSOMHSvc | |
| SCOM: management server | MSOMSdkSvc | |
| SCOM: management server with ACS | AdtServer |
Remember that an entry should be added for every possible name by which a service can be accessed, such as the NetBIOS name and FQDN, and also any ports or instance names that may be used.