At a conference recently I had someone ask how they would configure Kerberos for accounts that look like “NT Service\MSSQLServer” or “NT Service\MSSQL$MyInstance”. Please note that these are NOT the built-in system accounts, even though they look similar. The system accounts are “Local System”, “Local Service”, and “Network Service”. The “NT Service” accounts are virtual accounts that were released in Windows 7 and Windows Server 2008 R2. If you are familiar with Managed Service Accounts and Group Managed Service Accounts these virtual accounts are very similar but local. In fact they are sometimes referred to as Managed Local Accounts.
If you are using one of these accounts, which is now the default if you do not specify a domain account during SQL setup, then how do you configure your SQL Server for Kerberos authentication? The answer is quite simple. You don’t have to because it has the rights by default. Okay so that’s not the answer you were looking for because maybe you are using one of these accounts and still don’t have Kerberos. In this case the permissions on the computer object account have been altered and you’ll either need to fix that or add the SPNs manually.
You will need to place your SPNs on the computer object account for the server. By default, computer object accounts have the necessary permissions to manage their own SPNs. You shouldn’t actually need to register SPNs when using these accounts and your SQL Server should already be authenticating with Kerberos. If that is not the case then you will need to register the SPNs yourself or check the permissions on the computer object account in Active Directory.
If you are having issues configuring Kerberos and settings SPNs in your environment then I suggest you check out the Microsoft Kerberos Configuration Manager. If you are in a split DNS environment then you should read about Kerberos Configuration Manager’s Nasty Bug first.