Registration of Service Principal Name
A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. The Kerberos authentication service can use an SPN to authenticate a service. When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate.
When an instance of the Database Engine starts, SQL Server attempts to register the SPN for the SQL Server service. When the instance is stopped, SQL Server attempts to deregister the SPN. The SPN is registered in the format MSSQLSvc**/<FQDN>:**<tcpport>, where MSSQLSvc is the service that is being registered, <FQDN> is the fully qualified domain name of the server, and <tcpport> is the TCP port number. Both named instances and the default instance are registered as MSSQLSvc, relying on the <tcpport> value to differentiate the instance. Because the TCP port is included in the SPN, SQL Server must enable the TCP protocol for a user to connect using Kerberos authentication.
To register the SPN, the Database Engine must be running under the local system account or a domain administrator account. When SQL Server is running under an other account, the SPN is not registered at startup, but an administrator can manually register the SPN if desired. The same rules apply for clustered configurations. For more information on registering a SPN, see the section "Step 3: Create an SPN for SQL Server" of the topic How to: Enable Kerberos Authentication on a SQL Server Failover Cluster.
The following limitations apply:
- The SQL Server 2005 Database Engine supports the ability to listen on multiple IP addresses, but the automatic registration of SPNs only registers the first port it identifies.
- The port for the dedicated administrator connection (DAC), is not registered, therefore connecting to the DAC is only available using NTLM authentication, not Kerberos authentication.
If SPN registration fails during startup, it is recorded in the SQL Server error log, and startup continues.
Help and Information
5 December 2005