The target principal name is incorrect. Cannot generate SSPI context

小开

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

由于 Kerberos 身份验证 SQL Server's Windows Authentication依赖于 活动目录，它需要计算机和网络网域控制器之间的一种强制关系，因此应该从验证这种关系开始。

你可以通过下面的 Powershell 命令 abc0快速检查这种关系。

Test-ComputerSecureChannel -Verbose

If it returns 假的, you must repair your computer Active Directory secure channel, since without it no domain credencials validation is possible outside your computer.

You can repair your Computer Secure Channel, thru the following Powershell command:

Test-ComputerSecureChannel -Repair -Verbose

如果上述方法不起作用(因为您的域凭据不起作用，因为机器不受信任) ，您可以从提升的 cmd.exe(而不是 PowerShell)提示符中使用 NETDOM RESET:

NETDOM RESET %COMPUTERNAME% /UserO:domainAdminUserName /Password0:* /SecurePasswordPrompt

_{(是的，命令行参数确实有一个 O(大写的“哦”，而不是零 0)。/Password0:* /SecurePasswordPrompt选项将使用凭据弹出窗口，而不是让您将密码直接放在命令行中，这是绝对不能做的)。}

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

NTLM 身份验证可能失败，因此正在进行 Kerberos 身份验证尝试。您可能还会在安全事件日志中看到 NTLM 登录尝试失败？

您可以在 dev 中打开 kerberos 事件日志，尝试调试 kerberos 失败的原因，尽管这非常冗长。

微软的 SQLServer 的 Kerberos 配置管理器可以帮助您快速诊断和修复这个问题。

这里有一个很好的故事可以读: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

小开

因为我是在为自己的问题寻找解决方案时来到这里的，所以我将在这里分享我的解决方案，以防其他人也来到这里。

我一直很好地连接到 SQLServer，直到我的机器被转移到 另一个领域上的另一个办公室。然后，在切换之后，我得到了关于目标主体名称的这个错误。修复它的是使用 完全限定名称进行连接，如: server.domain.com。实际上，一旦我以这种方式连接到第一个服务器，我就可以只使用服务器名称(没有完整的限定)连接到其他服务器，但是您的使用范围可能会有所不同。

小开

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

使用 ADSI Edit 将读/写 servicePrincipalName 权限授予服务帐户，如 https://support.microsoft.com/en-us/kb/811889中所述
删除 SQLServer电脑帐户上以前存在的 SPN (与服务帐户相反)
```
setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
```
其中 1234是实例使用的端口号(我的实例不是默认实例)。

小开

我今天碰到了这个问题，想分享一下我的解决方案，因为这个问题很容易被忽略，而且很容易解决。

我们管理自己的 rDNS，最近重做了服务器命名方案。作为其中的一部分，我们应该更新我们的 rDNS 并忘记这样做。

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

简单的解决方法: 改变 rDNS，做一个 ipconfig/flushdns，等待30秒(只是我做的事情) ，做另一个 ping-a，看到它解决正确的主机名，连接... 利润。

小开

同时登录到您的 SQL Box 和客户端，然后键入:

ipconfig /flushdns
nbtstat -R

如果这不工作，更新您的 DHCP 在您的客户端机... 这个工作在我们的办公室2台电脑。

小开

我遇到了这个问题的一个变体，它的特点如下:

用户能够将 successfully connect连接到命名实例，例如，连接到 Server\Instance是成功的
用户是连接到默认实例的不能，例如，与 Server的连接失败，关于 SSPI 的 OP 截图
用户无法使用完全限定名连接默认实例，例如，与 Server.domain.com的连接失败(超时)
用户无法在没有命名实例的情况下连接 IP 地址，例如，到 192.168.1.134的连接失败
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

因此，在经历了许多令人头痛的事情之后，我们试图找出这个单一用户无法连接的原因，以下是我们为解决这个问题所采取的步骤:

查看 SPN 列表中的服务器
setspn -l Server
在我们的例子中，它说的是 Server.domain.com
向位于 C:\Windows\System32\drivers\etc\hosts中的主机文件添加一个条目(以管理员身份运行记事本以更改该文件)。我们添加的条目是
Server.domain.com Server

在此之后，我们能够成功地通过 SSMS 连接到默认实例。

小开

我遇到了一个新的问题: 服务器2012上托管的 SQL2012。负责为 SQLAlwaysOn 创建群集。
创建了集群，每个人都收到了 SSPI 消息。

要修复这些问题，运行以下命令:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService = = 我为 SQL 设置的域帐户我需要一个域管理员来运行这个命令。

然后重新启动 SQL。

小开

我试图在 VisualStudio2015控制台应用程序中从我的笔记本电脑连接到一个运行 SQLServer2015的 VM。我前一天晚上运行了我的应用程序，它没问题。早上我试着调试这个应用程序，却得到了这个错误。我试过 ipconfig/flush和 release + renew和一堆其他垃圾，但最后..。

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

小开

我在开发一个 ASP.NET MVC 应用程序时遇到了这个问题。

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

小开

尝试设置 Integrated Security=true以从连接字符串中删除此参数。

重要提示: 正如用户@Auspex 所评论的,

移除集成安全性将防止此错误，因为在尝试使用 Windows 凭据登录时会发生此错误。不幸的是，大多数时候，您希望能够使用 Windows 凭据登录

小开

我的 sql 服务器出现了这个问题。我设置 spn-D mssqlsvc Hostname.domainname Hostname 然后停止并启动 SQL 服务器服务。

我认为只要停止并启动我的 sql 服务就可以做到这一点。

小开

我也有这个问题在 SQL 服务器2014，而登录与 Windows 身份验证，以解决这个问题，我已经重新启动我的服务器一次，然后尝试登录，它为我工作。

小开

Integrated Security=false

在 webconfig连接字符串中将此标志设置为 false。它将工作！

小开

我在访问 Web 应用程序时遇到了这个问题。这可能是因为我最近更改了一个窗口密码。

这个问题得到解决时，我已经更新了应用程序池的密码，我已经托管的网络应用程序。

小开

请检查 SQL 服务器管理工作室中提到的登录名的权限，使其成为 sysadmin 复选框，然后在。配置文件。

在客户端机器上发出2个命令

ipconfig /flushdns
klist purge.

在客户端计算机上安装 kerbarose 配置管理器。

最后，重新启动客户端机器和主 SQL 服务器服务。在客户端机器上运行应用程序。此操作100% 正确。

小开

我也遇到过同样的问题，但是锁定和解锁机器对我来说很有效。有时候，防火墙问题会导致错误。

我不确定它是否适合你，只是分享我的经验。

小开

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.

小开

仅仅为这个最模糊的错误添加另一个可能的解决方案 The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

验证在 ping SQLServer 时解析的 IP 是否与配置管理器中的 IP 相同。若要进行检查，请打开 SQLServer 配置管理器，然后转到 SQLServer 网络配置 > 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.

小开

我也有同样的问题。我最近更改了我的 Windows 密码，我的网站抛出了错误。我试图注销和登录，但没有工作。然后我意识到我使用“自定义帐户”部分中的帐户配置了我的 defaultappppol，并且我再次使用新密码配置了帐户。这真是太神奇了! ! ！请让我知道你对这个解决方案的反馈意见。

小开

我已经尝试了所有的解决方案，但没有一个奏效。一个可行的解决方案是单击连接，输入服务器名称，选择 Options，Connection Properties 选项卡。将“网络协议”设置为“命名管道”。这允许用户使用其网络凭据进行远程连接。有消息我会更新的。

小开

我用 PIN 而不是密码登录 Windows10。我退出并用我的密码重新登录，然后能够通过 ManagementStudio 进入 SQLServer。

小开

我正在运行一个基于 SQL.COM 的米老鼠测试系统。

我在无法连接的机器和可以连接的机器上运行 setspn -T sql -F -Q */Servername(在本例中为 SQL01)。然后我简单地删除了问题机器中的附加条目，它就全部工作了，例如 setspn -D MSSQLSvc/SQL01.SQL.COM:1433 SQL01

小开

问题似乎与 DNS 服务器有关。若要解决此问题，请将 IP 地址更改为 ComputerName。

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

小开

检查客户端和服务器之间的时钟匹配。

当我间歇性地出现这个错误时，上面的答案都不起作用，然后我们发现时间在我们的一些服务器上漂移了，一旦它们再次同步，错误就消失了。搜索 w32tm 或 NTP，看看如何在 Windows 上自动同步时间。

小开

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

我在尝试使用我的域帐户连接到远程 SQLServer 实例时遇到了这个问题，在托管在不同计算机上的实例上尝试相同的操作效果很好。

因此，如果您可以选择只使用不同的实例，这可能会有所帮助，但这实际上并不解决任何问题。

小开

在我的例子中，重新启动 SQLServer2014(在我的开发服务器上)修复了这个问题。

小开

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.

我下载了完整 SQLServer 产品的开发版本，并将其安装在 Windows10上。对于本地连接一切正常，对于远程客户端则一无所获。

尝试了上面的许多方法，但最终我明白了 Windows Authentication 想要验证远程客户端 myuser，而且在一个独立的 Windows 世界里没有办法创建一个验证机制(据我所知是 kerberos)。错误消息是“无法生成 SSPI 上下文”。

使用 SQL 身份验证似乎也不起作用。

我最终回到了 SQL Server Express，它有一个组合模式，然后我可以使用来自远程客户端的 SQL 身份验证。

小开

我在一个孤立的网络中的一个个人电脑集群上测试 IPv6，当我恢复使用 IPv4时遇到了这个问题。我一直在活动目录，DNS 和 DHCP，所以不知道我推动破坏 Kerberos 设置。

我用这个有用的技巧重新测试了软件之外的连接，以连接我发现的远程连接。

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

然后经过简单的搜索，在微软的网站上发现了这个 Https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message.

在 SQL 服务器上运行该工具，查看是否存在任何问题 if the status says error then hit the fix button that appears.

This resolved the problem for me.

小开

对我来说，问题是在 WIFI 上设置 DNS。我删除了设置，让它们空着，然后开始工作。

小开

只有一个用户在一个 SQLServer 上得到此错误。原来他在控制面板中的 Windows 凭据管理器中为服务器名存储了一个旧密码。删除了存储的凭据，就成功了。

小开

当我试图在加入域的 Windows10机器上通过 L2TP VPN 连接到我的 SQLServer2017实例时，遇到了这个问题。

问题最终出现在我的 VPN 设置中。在安全设置、身份验证、使用 EAP-MSCHAPv2和属性对话框中，我选择了 Automatically use my Windows logon name and password (and domain if any).

我关闭了它，然后重新连接我的 VPN，然后我能够成功地连接到 SQLServer。

我相信这会导致我的 SQL 登录(带有 Windows 帐户安全性)使用 Kerberos 而不是 NTLM，从而导致 SSPI 错误。

小开

确保“命名管道”是从“ SQLServer 配置管理器”启用的。

打开“ SQLServer 配置管理器”。
展开“ SQLServer 网络配置”，从左边的列表开始。
选择“[实例名称]的协议”。
右键单击右侧列表中的“命名管道”。
选择「启用」
重新启动实例服务。

小开

此 Microsoft 工具类似于 Magic。运行它，将其连接到 SQL 服务器，然后单击 Fix

这里链接的旧版本可以在 SQL Server 2017上工作。

SQLServer 的 Kerberos 配置管理器 Https://www.microsoft.com/en-us/download/details.aspx?id=39046

小开

我的问题变得如此奇怪和简单:

ServerA 上的 SQLServerWindows 服务(配置为使用 DOMAINsvcAccountA 运行)
ServerB 上的 SQLServerWindows 服务(配置为使用 DOMAINsvcAccountB 运行)

DOMAINsvcAccountA 和 DOMAINsvcAccountB 都是 ActiveDirectory 域中的服务帐户。

即使为 DOMAIN svcAccountA 正确设置了连接到 ServerB 的所有权限，ServerA 上的 C # CLR (作为 DOMAIN svcAccountA 运行)也不能再使用 SqlConnection 连接到 ServerB (同样奇怪的无信息错误消息: 目标主体名称不正确。无法生成 SSPI 上下文)。

简单的部分？重新启动 ServerA 后，SQLServerWindows 服务将不再自动启动！这是发现有人更改了 DOMAIN svcAccountA 的密码的线索，我必须在这里更正 SQL Server Windows Service 配置:

在更正了密码之后，ServerA 上的 SQL Server Windows Service 开始正常运行，ServerA 上的 C # CLR (作为 DOMAIN svcAccountA 运行)现在可以使用 SqlConnection 连接到 ServerB。

小开

在我的情况下，我试图使用集成安全从一台 PC 连接到 SQL 服务器在另一台 PC 上的网络没有域。在两台电脑上，我都是 用同一个 Microsoft 帐户登录到 Windows。在 PC 和 SQLServer 上的 I转到了一个本地账户现在成功连接。

小开

在我的案例中，由于我在自己的开发环境中工作，有人关闭了网域控制器，Windows 凭证无法进行身份验证。打开网域控制器后，错误就消失了，一切正常。

小开

我有这个问题，它抓住了我大约4-5个小时，以找到这个错误消息的根本原因。唯一的区别是，我只在从 VisualStudio 连接 DB 时得到此错误，而不是直接通过 SQLServerManagementStudio。

出现错误的原因是，我的应用程序托管在本地 IIS 上，我在一天前更改了系统密码，但没有将其更新到托管应用程序的 IIS 应用程序池中。

我进入 IIS，点击应用程序池，在池列表中右键点击适当的应用程序池，进入“高级设置”，选择“身份”，并在“自定义帐户”下更改其值(域帐户名和新密码) ，它解决了我的问题。

Thanks

小开

这个问题似乎是一个 Windows 凭证问题。我的工作笔记本电脑在使用 VPN 时也出现了同样的错误。我应该是以我的域名/用户名登录的，这是我在直接连接时成功使用的，但是一旦我转到使用另一个连接的 VPN，我就会收到这个错误。我认为这是一个 DNS 问题，因为我可以 ping 服务器，但结果是，我需要在命令提示符下以用户身份显式运行 SMSS。

Runas/netonly/user: YourDoman YourUsername“ C: Program Files (x86) Microsoft SQL Server Management Studio 18 Common7 IDE Ssms.exe”

小开

这通常是由于缺少、不正确或重复的服务原则名称(SPN)

解决步骤:

确认 SQLServer 正在使用的 AD 帐户
以管理员模式(服务帐户不应包含域名)在 Powershell 或 CMD 运行以下命令

setspn -L <ServiceAccountName> | Select-String <ServerName> | select line

确保返回的输出包含一个 SPN，该 SPN 是完全限定的，没有完全限定的，带有一个端口，没有端口。

预期产出:

Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com:
MSSQLSvc/<ServerName>.<domain>.com:1433
MSSQLSvc/<ServerName>:1433
MSSQLSvc/<ServerName>.<domain>.com
MSSQLSvc/<ServerName>

如果没有看到以上所有内容，请在 PowerShell 或管理模式下运行以下命令(如果没有使用默认的1433，请确保更改端口)

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName>
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName>
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName>
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>

一旦以上是完成它通常需要几分钟的 DNS 传播

此外，如果您收到关于找到重复 SPN 的消息，您可能希望删除它们并重新创建它们

小开

如果有人想知道的话，我解开了 MS 术语:

Target = (active directory) target


Active directory target = target server running the domain controller


Domain controller = server that verifies your login information


Principal name = your windows username


SSPI = security support provider interface


Security support provider interface = software interface that manages "authenticated
communications" and allows SSPs like TLS to allow SSL, among others


SSP = security support provider (SSPI implementation)


TLS/SSL = you should already know this

= 无法验证密码。

小开

In your SQL Server Firewall, open ports 1433, 4022, 135, 1434 for inbound and outbound. Works like magic for me.

小开

Another niche to this issue caused by network connections. I connect via windows VPN client and this issue popped up when I switched from Wifi to a wired connection. The fix for my situation was to manually adjust the adapter metric.

在 powershell 中，使用 Get-NetIPInterface 查看所有度量值。较低的数字是较低的成本，因此他们是首选的窗口。我切换了以太网和虚拟专用网然后凭证就到了 SSMS 需要的地方。

配置自动公制功能: 在“控制面板”中，双击“网络连接”。右键单击网络接口，然后选择“属性”。单击 Internet 协议(TCP/IP) ，然后选择“属性”。在“常规”选项卡上，选择“高级”。若要指定指标，请在“ IP 设置”选项卡上选择以清除“自动指标”复选框，然后在“接口指标”字段中输入所需的指标。

来源: Https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

小开

我在更改 SQLServer 服务用户时遇到了这个问题。当它发生在一个主实例上时，下面的第1点和第2点修复了问题，因为 SPN 没有被更新。

我在更改命名实例服务用户时也遇到了这个问题。这个新用户是主实例已经在使用的域帐户。我不知道哪里出了问题，但我用这种方式解决了问题:

我按照上面的建议(参见前面的线程)运行 MicrosoftKerberos SQLServer 配置管理器
该工具发现了一些问题，并为我修复了它们
该工具表明在命名实例上启用动态端口不是一个好主意，因此我运行了 sql 服务器配置管理器并:
configured the named instance to use a static port (number is not important as long as it's available). Path to configuration: Protocols for named instance, right click on the TCP/IP, properties, IP Addresses, clear all TCP dynamic ports content, set the port number of your choice to all TCP port properties.
创建别名: sql 本机客户端配置-> 别名-> 新别名。服务器是你的数据库服务器名，端口是上面提到的那个，我选择的别名和没有服务器名的实例名是一样的(例如 server1 sqlsrv2017: server = server1，alias = sqlsrv2017)
按提示重新启动实例服务

如果启用了防火墙，则不用说端口必须使用防火墙清除

小开

我在使用人脸识别登录 Windows10时也遇到了同样的问题。解决办法是按住 shift 并右键单击 SSMS，使用“以不同用户身份运行”并提供用户名和密码。

小开

I had the same problem for SQL Server 2014 and all I had to do was to run the application as an administrador.

小开

Database in the connection string didn't exist. I thought it did but it hadn't been created yet.

小开

我找到了, Michael Hotek 在这个 MSDN 帖子中回答了这个问题。

如果 SQLServer 仅配置为 Windows 身份验证，则连接到它的唯一方法是使用域凭据。由于您的笔记本电脑上没有域凭据，因此无法连接。如果要使用 SQLServer 登录名进行连接，则需要将实例的安全模型更改为 Windows 和 SQLServer 身份验证。然后，您将能够使用标准的 SQLServer 登录名而不是域凭据。如果这是不可能的，那么一个真正简单的解决方案是将 VPN 安装到办公室，然后将 RDP 安装到安装了 SQLServer 工具的机器上。然后使用您的凭据登录到域中，并且可以直接使用 RDP 到的机器上的工具。

事实证明，如果您不在域上，那么必须使用 Mixed mode Auth。

小开

我一直无法以令人满意的方式解决这个问题。如果我以本地 Windows 帐户从客户端登录，Windows 身份验证可以正常工作。然而，如果我尝试从 Microsoft 帐户登录(这对我来说更好，因为同步功能) ，我得到“不正确的主体”消息。MS-SQL 日志中没有出现失败登录的记录，这意味着失败发生得非常早。

小开

我知道这个问题可能有各种各样的原因, 在我的例子中，我的 ActiveDirectory 用户帐户被锁定(当我登录到那个主机 VM 时) ，登出然后解锁我的 AD 帐户解决了这个问题。希望这能帮到其他人。

小开

在阅读了所有发布的答案并尝试了其中的大部分后，我仍然不能解决这个问题(不是说它们没有用，但是我没有设法使它工作)。

对我有效的解决方案是使用 SQL 身份验证而不是 Windows 身份验证。在创建为“ host”的服务器中，创建一个具有登录访问权限的 SQL 用户(有一个默认的名为“ sa”的用户，你可以在首次使用 Windows 身份验证登录后更改其密码) ，然后使用同一个用户的凭证从其他计算机登录，这应该建立连接。

希望它能帮到别人! ！