SPN's Validate"Good Status" in Kerberos Config Mgr- cannot gen SSPI

  • After Adding SPN's and Validating "Good Status" in Kerberos Config Manager attempt to log into SQL Sever Remotely Results in: The target principal name is incorrect. Cannot generate SSPI context.

    SQL 2017- Windows Server 2019

    We have added 4 SPN entries for one of our SQL Server running as a domain account. It is a default instance running on port 1433 and SQL Server service is running as domain account  (dom1\SQLSVC)   Here Are the statements executed :

    • setspn -A MSSQLSvc/server1234.dom1.org:1433 dom1\SQLSVC
    • setspn -A MSSQLSvc/server1234:1433 dom1\SQLSVC
    • setspn -A MSSQLSvc/server1234.dom1.org dom1\SQLSVC
    • setspn -A MSSQLSvc/server1234 dom1\SQLSVC

    We have verified the entries are there ( setspn -l dom1\SQLSVC) and have run the MS Kerberos Configuration Manager locally on the server (server1234) and 2 SPN's  listed had green "Good status". When we try to logon to the SQL Server remotely we encounter the "The target principal name is incorrect. Cannot generate SSPI context" error.

    What could we be missing here? With out the SPN's  in place , remote connections work just fine, but using NTLM authentication.

    While I have configured many SPN's successfully prior , this is the first one in this particular domain. SO I am wondering if there could be some additional AD related setting or permissions being overlooked that factor into the  Kerberos "Auth Process". Thanks in advance for any help or suggestions.

    Thank you,

    Mark G.

  • Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • In AD, did you give the service account the 'Trust for delegation'  property?

  • You are using the “setspn-a” cmd. You likely have a duplicate spn on the domain. Use the -s in place of -a to create the spn.

    This is from this link:

    https://ss64.com/nt/setspn.html

    Early versions of Setspn had the option Setspn -A, which skipped the check for duplicates, use Setspn -S in preference to this.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply