我们在通过 SSPI 连接到 SQL Server（2008 R2）时遇到了问题。
我们的团队最近从基于域的设置转变为基于分散工作组的设置。每个开发人员都可以访问 VPN，从而让他们可以访问运行 SQL Server 2008 R2 的数据库服务器。
我们以前使用过 Windows 身份验证，使用我们的用户名从加入域的 PC 登录DOMAIN\user.name，将具有相同用户名和密码（但不是域）的远程 SQL 服务器（在工作组中）的帐户添加到 Windows 安全组，并授予该组在 SQL 服务器上的权限。
但是，自从从我们的域切换以来，我们就无法使用 SSPI 进行连接。
当尝试通过 TCP/IP 使用 Windows 身份验证访问数据库时，我们收到以下错误消息：
登录失败。登录来自不受信任的域，无法与 Windows 身份验证一起使用。（Microsoft SQL Server，错误：18452）
指定 SQL Server 登录名按预期工作，但使用 SSPI 失败。检查 SQL Server 端的事件日志，我们看到以下内容：
建立集成安全性连接时，SSPI 握手失败，错误代码为 0x8009030c，状态为 14；连接已关闭。原因：AcceptSecurityContext 失败。Windows 错误代码指示失败原因。[客户端：192.168.xxx.xxx]。
我们的托管服务提供商已将工作组名称设置为数字 - 我们将假装该工作组名为 12345678（实际名称是我们的帐号）。我已经尝试将本地工作组更改为相同的数字，但这并没有解决问题。
其他用户建议的许多解决方案都引用了一个名为的工具setspn，并使用该工具列出并查找我们帐户中使用的 SPN – 使用该工具不会显示任何异常。
我们通过使用以下方法解决该限制：
runas /netonly /user:REMOTEPCNAME\user.name "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"
我们是否必须使用这种方式进行身份验证？
答案1
十一年前，我曾解决过类似的问题，方法是将工作站上的驱动器号映射到远程计算机，并在另一台计算机上提供我的凭据。对您来说，这看起来像这样（从 CMD 或 PSH shell）：
net use x: \\REMOTEPCNAME\c$ /user:REMOTEPCNAME\john.doe
显然，这使用了您可能无权访问的“管理员共享”。这对我来说不是问题，因为我是该框的管理员组的成员。如果您没有管理员访问权限，则可能必须设置一个公共共享（由具有足够权限的人设置）并使用它，我相信尽管我还没有尝试过，但它可能会有效。
在当时，这种技巧非常常见，因为当时域名还很少见，AD 也还比较新奇。尽管现在这种技巧已经不常见了，但我不记得微软放弃或破坏过这种解决方法。
我从未见过在没有完整设置 Active Directory 的情况下使用 SPN。如果我没记错的话，SPN 需要 Kerberos，而 Kerberos 需要域。我怀疑 SPN 的线索是转移注意力的借口。祝你好运。