Kerberos authentication uses an identifier called the “Service Principal Name” or SPN. Basically, the SPN acts as a domain or forest unique identifier of some instance in a server resource. There can be an SPN for a web service, for an SQL service, or for an SMTP service. There can also be multiple web service instances on the same physical computer that has a unique SPN.
This becomes abundantly clear at almost every client I install SCCM for. Most DBAs seem to stick with the well-established best practice of running the SQL services under seperate domain accounts, and rightly so. And most companies seem to want to grant service accounts the least privileges needed: another best practice indeed. As a result, the SPN can fail to be created for the SQL instance for ConfigMan:
Why does this happen? By default, if you run the SQL Server service under the LocalSystem account, the SPN is automatically registered and Kerberos authentication interacts successfully with the computer that is running SQL Server. However, if you run the SQL Server service under a domain account or under a local account, the attempt to create the SPN can often fail in most cases because the domain or local accounts do not have the rights to set their own SPNs. When the SPN creation is not successful, it can prevent you from using Kerberos authentication when connecting to the SQL server instance. If this were done with a domain administrator account as the SQL Server service account, the SPN would be successfully created because the domain administrator-level credentials that you must have to create an SPN are present.
Most people will opt not to use a domain administrator account to run the SQL Server service and therefore, you must manually create an SPN for your computer that is running SQL Server if you want to use Kerberos authentication when you connect to it. The SPN you create must be assigned to the service account of the SQL Server service on that particular computer. The SPN cannot be assigned to the computer container unless the computer that is running SQL Server starts with the local system account. There must be one and only one SPN, and it must be assigned to the appropriate container. Typically, this is the current SQL Server service account.
To configure the SQL Server service to create SPNs dynamically, follow these steps:
1. Click Start, click Run, type Adsiedit.msc, and then click OK.
2. In the ADSI Edit snap-in, expand Domain [DomainName], expand DC= RootDomainName, expand CN=Users, right-click CN= AccountName, and then click Properties.
3. In the CN= AccountName Properties dialog box, click the Security tab.
4. On the Security tab, click Advanced.
5. In the Advanced Security Settings dialog box, make sure that SELF is listed under Permission entries.If SELF is not listed, click Add, and then add SELF.
6. Under Permission entries, click SELF, and then click Edit.
7. In the Permission Entry dialog box, click the Properties tab.
8. On the Properties tab, click This object only in the Apply onto list, and then make sure that the check boxes for the following permissions are selected under Permissions:
9. Click OK three times, and then exit the ADSI Edit snap-in.
To Create an SPN from the command line:
1. Open a Command Prompt or PowerShell from and account with Domain Admin priveleges
setspn -A MSSQLSvc/server:instance domain\account
3. After the command completes, type
setspn -Q MSSQLSvc/server:instance
to verify the SPN is successfully created and present.