What’s the issue?
A Service Principal Name (SPN) is an Active Directory identifier that maps a service instance to the account running it, allowing clients to request Kerberos tickets for that service. SQL Server requires SPNs in the form MSSQLSvc/<FQDN>:<port> or MSSQLSvc/<FQDN>:<instancename> to be registered for its service account before Kerberos authentication can succeed.
At service startup, SQL Server attempts to register its own SPNs automatically. This only works if the service account has the Active Directory rights to write the servicePrincipalName attribute on its own object, which is granted by default to accounts running as LocalSystem or NetworkService but not to typical domain user accounts.
This finding identifies instances where SQL Server logged an SPN registration failure at startup. The message appears in the SQL Server error log and typically reads that the SQL Server Network Interface library could not register the SPN, along with the reason and the SPN it attempted to register.
Why is this a problem?
Without a correctly registered SPN, clients cannot obtain a Kerberos ticket for the instance, and Windows authentication silently falls back to NTLM. Connections continue to succeed, so the failure produces no visible symptom for users or applications, and the environment can operate on the weaker protocol indefinitely without anyone noticing.
NTLM is more vulnerable to relay attacks than Kerberos and is being progressively deprecated across the Windows platform. Running an instance on NTLM by accident means the environment is not getting the authentication protection it was designed to have.
Missing SPNs also break any scenario requiring delegation. Double-hop authentication through linked servers, SSRS, and middle-tier applications all depend on Kerberos, and these fail with login errors that are hard to trace back to an SPN registration message logged at service startup days or weeks earlier.
What should you do about this?
Review the SQL Server error log for the SPN registration message and note the exact SPN that failed and the reason given. Then check the current registration state with setspn -L <DOMAIN\ServiceAccount> and setspn -Q MSSQLSvc/<FQDN>:<port> to see whether the SPN exists, is missing, or is registered to a different account.
Register the missing SPNs manually with a domain administrator account using setspn -S MSSQLSvc/<FQDN>:<port> <DOMAIN\ServiceAccount>, registering both the port-based and instance-based forms where applicable. Remove any duplicate registrations found on other accounts, since duplicates break Kerberos for the instance entirely.
As a longer-term fix, consider granting the SQL Server service account the Read servicePrincipalName and Write servicePrincipalName rights on its own Active Directory object, which allows SQL Server to self-register and self-deregister its SPNs across restarts, port changes, and failovers. Alternatively, use a Group Managed Service Account, which handles SPN management as part of the account model.