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