debugsqlMinor
The Target Principal Name Is Incorrect. Cannot Generate SSPI Context (SQL or AD Issue)?
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.
I also ran the following command against the problem SQL Server instance:
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:
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?
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 xsql2Results
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 xensql1Results
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.
See Register a Service Principal Name for Kerberos Connections
To check to see if they are already there:
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.
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 ServiceAccountNameHowever, 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 ServiceAccountNameContext
StackExchange Database Administrators Q#241051, answer score: 5
Revisions (0)
No revisions yet.