The target principal name is incorrect. Cannot generate SSPI context

问题

I am struggling to get a SQL Server connection from machine A to machine B which is running the SQL Server.

I have Googled extensively and all the things I have found have not worked. Nor do they lead you step by step through the process of solving this.

We are not using Kerberos, but NTLM where configured.

The machines involved are (xx is used to obscure some of the machine name for security purposes):

xxPRODSVR001 - Windows Server 2012 Domain Controller
xxDEVSVR003 - Windows Server 2012 (This machine is generating the error)
xxDEVSVR002 - Windows Server 2012 (This machine is running SQL Server 2012)

The following SPN's are registered on the DC (xxPRODSVR001). I have obscured the domain with yyy for security purposes:

Registered ServicePrincipalNames for CN=xxDEVSVR002,CN=Computers,DC=yyy,DC=local:

            MSSQLSvc/xxDEVSVR002.yyy.local:49298

            MSSQLSvc/xxDEVSVR002.yyy.local:TFS

            RestrictedKrbHost/xxDEVSVR002

            RestrictedKrbHost/xxDEVSVR002.yyy.local

            Hyper-V Replica Service/xxDEVSVR002

            Hyper-V Replica Service/xxDEVSVR002.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR002

            Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR002

            Microsoft Virtual Console Service/xxDEVSVR002.yyy.local

            SMTPSVC/xxDEVSVR002

            SMTPSVC/xxDEVSVR002.yyy.local

            WSMAN/xxDEVSVR002

            WSMAN/xxDEVSVR002.yyy.local

            Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local

            TERMSRV/xxDEVSVR002

            TERMSRV/xxDEVSVR002.yyy.local

            HOST/xxDEVSVR002

            HOST/xxDEVSVR002.yyy.local

Registered ServicePrincipalNames for CN=xxDEVSVR003,CN=Computers,DC=yyy,DC=local:

            MSSQLSvc/xxDEVSVR003.yyy.local:1433

            MSSQLSvc/xxDEVSVR003.yyy.local

            Hyper-V Replica Service/xxDEVSVR003

            Hyper-V Replica Service/xxDEVSVR003.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR003

            Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR003

            Microsoft Virtual Console Service/xxDEVSVR003.yyy.local

            WSMAN/xxDEVSVR003

            WSMAN/xxDEVSVR003.yyy.local

            TERMSRV/xxDEVSVR003

            TERMSRV/xxDEVSVR003.yyy.local

            RestrictedKrbHost/xxDEVSVR003

            HOST/xxDEVSVR003

            RestrictedKrbHost/xxDEVSVR003.yyy.local

            HOST/xxDEVSVR003.yyy.local

Now if only the SQL Server error message was more descriptive and told me what principal name it was trying to connect to I might be able to diagnose this.

So can anyone step me through how to solve this one or can you see anything in what I have provided that is wrong?

I would be happy to generate more debug info, just tell me what you need.

回答1:

I had this problem with an ASP.NET MVC app I was working on.

I realized I had recently changed my password, and I was able to fix it by logging out and logging back in again.

回答2:

I spent about couple hours with the same problem. It turned out, that "Integrated Security=true" caused the problem.

Try to remove this param from the connection string.

回答3:

I received this error when connecting via SQL Server Management Studio using Windows Authentication. My password had expired but I had not yet changed it. Once changed, I then had to log out and log back in so that the machine was working using my new credentials.

回答4:

I was logging into Windows 10 with a PIN instead of a password. I logged out and logged back in with my password instead and was able to get in to SQL Server via Management Studio.

回答5:

I was getting the same error when trying through windows authentication. Sounds ludicrous but just in case it helps someone else: it was because my domain account got locked somehow while I was still logged in (!). Unlocking the account fixed it.

回答6:

Just to add another potential solution to this most ambiguous of errors The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider) :

Verify that the IP that is resolved when pinging the SQL Server is the same as the one in the Configuration Manager. To check, open SQL Server Configuration Manager and then go to SQL Server Network Configuration > Protocols for MSSQLServer > TCP/IP.

Make sure TCP/IP is enabled and in the IP Addresses tab, make sure that the IP that the server resolves to when pinging is the same one here. That fixed this error for me.

回答7:

ipconfig /flushdns
nbtstat -R

If that doesn't work, renew your DHCP on your client machine... This work for 2 PCs in our office.

回答8:

In my case, restarting SQL Server 2014 (on my development server) fixed the issue.

回答9:

I was testing out IPv6 on a cluster of PC's in an isolated network and ran into this issue when I reverted back yo IPv4. I had been play in the active directory, DNS and DHCP so have no idea what I prodded to break the Kerberos setup.

I retested the connection outside of my software with this useful tip to connect remote connectivity I found.

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

then after a brief search found this on the Microsoft website https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message.

run the tool on the SQL server see if there are any issue if the status says error then hit the fix button that appears.

This resolved the problem for me.

回答10:

I just ran into this and fixed it by doing 2 things:

Granting read/write servicePrincipalName permissions to the service account using ADSI Edit, as described in https://support.microsoft.com/en-us/kb/811889
Removing the SPNs that previously existed on the SQL Server computer account (as opposed to the service account) using
```
setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
```
where 1234 was the port number used by the instance (mine was not a default instance).

回答11:

The SSPI context error definitely indicates authentication is being attempted using kerberos.

Check the security event logs, if you are using kerberos you should see logon attempts with authentication package: Kerberos.

The NTLM authentication may be failing and so a kerberos authentication attempt is being made. You might also see an NTLM logon attempt failure in your security event log?

You can turn on kerberos event logging in dev to try to debug why the kerberos is failing, although it is very verbose.

Microsoft's Kerberos Configuration Manager for SQL Server may help you quickly diagnose and fix this issue.

Here is a good story to read: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

回答12:

I had this problem when accessing the web application. It might be due to i have changed a windows password recently.

This issue got resolved when i have updated the password for the app pool where i have hosted the web application.

回答13:

Check your clock matches between the client and server.

When I had this error intermittently, none of the above answers worked, then we found the time had drifted on some of our servers, once they were synced again the error went away. Search for w32tm or NTP to see how to automatically sync the time on Windows.

回答14:

Since I landed here when looking for a solution to my own problem, I'll share my solution here, in case others land here as well.

I was connecting fine to SQL Server until my machine was moved to another office on another domain. Then, after the switch, I was getting this error regarding the target principal name. What fixed it was connecting using a fully qualified name such as: server.domain.com. And actually, once I connected to the first server that way, I could connect to other servers using just the server name (without the full qualification), but your mileage may vary.

回答15:

I ran into this today and wanted to share my fix, since this one is simply overlooked and easy to fix.

We manage our own rDNS and recently redid our server naming scheme. As part of that, we should have updated our rDNS and forgot to do this.

A ping turned up the correct hostname, but a ping -a returned the wrong hostname.

Easy fix: change the rDNS, do an ipconfig /flushdns, wait 30 seconds (just something I do), do another ping -a , see it resolving the correct hostname, connect ... profit.

回答16:

I ran into a new one for this: SQL 2012 hosted on Server 2012. Was tasked to create a cluster for SQL AlwaysOn.
Cluster was created everyone got the SSPI message.

To fix the problems ran following command:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService == the domain account I set for SQL I needed a Domain Administrator to run the command. Only one server in the cluster had issues.

Then restarted SQL. To my surprise I was able to connect.

回答17:

I was trying to connect to a VM running SQL Server 2015 from my laptop in a Visual Studio 2015 Console App. I run my app the night before and it is fine. In the morning I try to debug the app and I get this error. I tried ipconfig/flush and release + renew and a a bunch of other garbage, but in the end...

Restart your VM and restart the client. That fixed it for me. I should have known, restart works every time.

回答18:

Make sure that "Named Pipes" are enabled from "SQL Server Configuration Manager". This worked for me.

Open "SQL Server Configuration Manager".
Expand "SQL Server Network Configuration", from the list on the left.
Select "Protocols for [Your Instance Name]".
Right click on "Named Pipes", from the list on the right.
Select "Enable"
Restart your Instance service.

回答19:

This Microsoft Tool is like Magic. Run it, connect it to the SQL server, and click Fix

The old version linked here worked on SQL server 2017.

Kerberos Configuration Manager for SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

回答20:

I ran into a variant of this issue, here were the characteristics:

User was able to successfully connect to a named instance, for example, connections to Server\Instance were successful
User was unable to connect to the default instance, for example, connections to Server failed with the OP's screenshot regarding SSPI
User was unable to connect default instance with fully qualified name, for example, connections to Server.domain.com failed (timeout)
User was unable to connect IP address without named instance, for example, connections to 192.168.1.134 failed
Other users not on the domain (for example, users who VPN to the network) but using domain credentials were able to successfully connect to the default instance and IP address

So after many headaches of trying to figure out why this single user couldn't connect, here are the steps we took to fix the situation:

Take a look at the server in the SPN list using
setspn -l Server
a. In our case, it said Server.domain.com
Add an entry to the hosts file located in C:\Windows\System32\drivers\etc\hosts (run Notepad as Administrator to alter this file). The entry we added was
Server.domain.com Server

After this, we were able to successfully connect via SSMS to the default instance.

回答21:

I had this problem on my sql server. I setspn -D mssqlsvc\Hostname.domainname Hostname then stoped and started my SQL server service.

I am thinking that just stopping and starting my sql service would have done it.

回答22:

I too had this problem on SQL Server 2014 while logging with windows Authentication, to resolve the issue i have Restarted my server once and then try to login, it worked for me.

回答23:

I had the same issue, but locking, and unlocking the machine worked for me. Sometimes, firewall issues will give errors.

I am not sure it will work for you or not, just sharing my experience.

回答24:

I had the same issue. I recently changed my windows password and my website was throwing the error. I tried to logout and login but not worked. Then I realized I configured my defaultappppol using my account in the "custom account" section and I configured the account once again using the new password. This did the magic!!! Please let me know your feedback on this solution.

回答25:

I have tried all the solutions here and none of them have worked yet. A workaround that is working is to Click Connect, enter the server name, select Options, Connection Properties tab. Set the "Network protocol" to "Named Pipes". This allows users to remote connect using their network credentials. I'll post an update when I get a fix.

回答26:

I'm running a Mickey Mouse testing system based on SQL.COM.

I ran setspn -T sql -F -Q */Servername (in this case SQL01) on both the machine I couldn't connect to and a machine I could. I then simply removed the additional entries in the problem machine and it all worked, e.g. setspn -D MSSQLSvc/SQL01.SQL.COM:1433 SQL01

回答27:

Seems to be issue is related to DNS Server. To resolve this issue change the IP Address to ComputerName.

Example: Change the value "10.0.0.10\TestDB" to "YourcomputerName\TestDB"

回答28:

Not at all an ideal solution, I just wanted to add this for future reference for anyone seeing this page:

I was having this issue trying to connect to a remote SQL Server instance using my domain account, trying the same thing on an instance hosted on a different machine worked fine.

So if you have the option to just use a different instance it may help, but this doesn't actually address whatever the issue is.

回答29:

I'll add this here as it caught me out and may help someone else. Caveat emptor, I am not a windows person, but had to look at a scenario that included SQL server.

I downloaded the developer version of the full SQL Server product and installed it on Windows 10. All good for local connections, nothing for the remote client.

Tried many of the above but it eventually dawned on me that the Windows Authentication wanted to authenticate remoteclient\myuser and there was no way in a standalone Windows world to create a mechanism to authenticate against (As I understand it kerberos). The error message being "Cannot generate SSPI context".

Using SQL Authentication didn't appear to work either.

I eventually went back to SQL Server Express which has a combined mode and I could then use SQL Authentication from the remote clients.