Chances are high that you have a bad SPN currently registered on the domain. To find this, you can simply run the following command from the command prompt:
setspn -q MSSQLSvc/ComputerName*
Replace ComputerName with the name of the server hosting SQL Server and keep the trailing asterisk as it acts as a wildcard.
This should return any SPNs currently registered on the domain for the SQL Server service. The item to pay most attention to is the account or machine that this SPN is registered as. If it does NOT match the account currently running the SQL Server service (found via running services.msc on the server), that is your issue. To fix it, you will want to delete the bad SPN(s) and then register the SPN under the proper user, or even better, let SQL Server do it after you place the service account in a properly configured OU on the domain. Take note though, SQL Server only tries to register the correct SPN at service startup.
UPDATE:
Based on the fact that you said the command above returned no results, I suggest you run a less restrictive query as follows:
setspn -q MSSQLSvc/* > SPNList.txt
This will list all SPNs that are associated with a SQL Server service (i.e. MSSQLSvc). I'm redirecting the output to a file here as the results will likely be large, but the command should run pretty fast. Dig through that output file and see if you can find any MSSQLSvc SPNs associated with any of the following:
- The machine this database instance is running on
- The service account that is currently running this database instance
- The service account(s) that previously ran this database instance
- The IP address of this server
- If this is a named instance, any reference to the instance name
If there's anything clearly incorrect, delete it and see if that fixes the issue.
If you're still not seeing anything based on the above criteria, I think the next step is to troubleshoot your service account. Since you're running a Managed Service Account, you can get information about it via the PowerShell command Get-ADServiceAccount, as follows:
Get-ADServiceAccount "AccountName" -Properties *
Take note that you don't need to include the $ here for a MSA.
Specifically check if the service account has any SPNs listed under the ServicePrincipalNames property. If not, you may need to set this via the Set-ADServiceAccount cmdlet, as follows:
Set-ADServiceAccount "AccountName" -Add @{'ServicePrincipalNames'=@('MSSQLSvc/fqdn','MSSQLSvc/fqdn:port')}
In the example above, fqdn is the Fully Qualified Domain name and port would be the port number your database instance is listening on.
One other property I've seen throw off Kerberos Authentication is when the KerberosEncryptionType property is not set with either AES128, AES256 or both. If this is the case, you may also want to set this property as well using a similar convention to what I have shown above.
