If you choose to run services such as SQL Server under a service account (not a domain user called a “service” account, but a “real” managed/group managed service account), one thing you will need to do manually is register necessary service principal names (SPNs) under this account to allow for Kerberos authentication.

If the service were running as NT AUTHORITY\SYSTEM, this would occur automatically, as the computer account already has the necessary permissions.

Here’s how you can achieve the same behavior by granting NT AUTHORITY\SELF the same permission, which will allow a gMSA to write SPNs on itself:

1
2

$gMSA = Get-ADServiceAccount -Identity 'gMSA_Name$'
dsacls $gMSA.DistinguishedName /G 'SELF:RPWP;servicePrincipalName'

After setting the above permission, simply restarting the SQL Server service will cause the SPNs to be registered, which you can confirm by running setspn -L gMSA_Name$.

To easily handle this for more than one gMSA, you can also delegate permissions to an OU that contains your gMSAs the same permission via the “Delegate Control” wizard:

  • Step 1: Select NT AUTHORITY\SELF as the identity to delegate permissions to. Permissions Delegation Step 1

Step 2: Select custom task to delegate. Permissions Delegation Step 2

Step #3: Select only group managed service account objects to apply the delegated permissions to. Permissions Delegation Step 3

Step #4: Select the “Write servicePrincipalName” property-specific permission to delegate. Permissions Delegation Step 4

Step #5: Click Finish to complete the permissions delegation. Permissions Delegation Step 5

The full output text in the last window should look similar to the following:

You chose to delegate control of objects
in the following Active Directory folder:

    corp.ajf.one/TEST

The groups, users, or computers to which you
have given control are:

    SELF (NT AUTHORITY\SELF)

They have the following permissions:

    Write servicePrincipalName

For the following object types:

    msDS-GroupManagedServiceAccount