HiveBrain v1.2.0
Get Started
← Back to all entries
debugsqlMinor

The Target Principal Name Is Incorrect. Cannot Generate SSPI Context (SQL or AD Issue)?

Submitted by: @import:stackexchange-dba··
0
Viewed 0 times
cannotsspithetargetincorrectsqlissuegeneratenameprincipal

Problem

We had a power outage last night and when the server came back up our domain users could not access our SQL Server 2000 instance name: MASSQL.

We can access using SQL Authentication.

  • We tried making sure the user that runs the service has SSPI read and Write



  • We tried creating a new user



  • We tried running the service using NETWORK SERVICE account



  • We tried running as Local System Account



  • We tried creating a new Domain Admin account and run service as the new Domain Admin account



I also ran the following command against the problem SQL Server instance:

setspn -L xsql2


Results

Registered ServicePrincipalNames for CN=MASSQL,CN=Computers,DC=ABC,DC=com:
HOST/MASSQL
HOST/MASSQL.ABC.COM

I ran the following command against a non-problem SQL instance:

setspn -L xensql1


Results

Registered ServicePrincipalNames for CN=XENSQL1,CN=Computers,DC=ABC,DC=com:
WSMAN/XENSQL1
WSMAN/XENSQL1.ABC.com
RestrictedKrbHost/XENSQL1
HOST/XENSQL1
RestrictedKrbHost/XENSQL1.ABC.COM
HOST/XENSQL1.ABC.COM

It seems the results for the non-problem instance have more data. I do not know if this has to do with the fact one is 2000 and the other is 2012.

What likely happened? How do I allow domain users login again?

Solution

The SQL Server SPNs are not set on the computer account per se, but on the account that SQL Server is running under. You will need to create two SPNs for the SQL Server service if the service account does not have permissions to create the SPNs. The following examples assume using the default port of 1433.

SetSPN -s "MSSQLSvc/" "\"
SetSPN -s "MSSQLSvc/:1433" "\"


See Register a Service Principal Name for Kerberos Connections

To check to see if they are already there:

SetSPN -L ServiceAccountName


However, it seems that you may have bigger issues in play. If you configured SQL Server to run with a domain admin account, it should have had permissions to create the SPNs.

Code Snippets

SetSPN -s "MSSQLSvc/<FQDN_SERVERNAME>" "<DOMAIN>\<SERVICE_ACCOUNT_NAME>"
SetSPN -s "MSSQLSvc/<FQDN_SERVERNAME>:1433" "<DOMAIN>\<SERVICE_ACCOUNT_NAME>"
SetSPN -L ServiceAccountName

Context

StackExchange Database Administrators Q#241051, answer score: 5

Revisions (0)

No revisions yet.