自从前一段时间在我的开发计算机上迁移到Vista以来，从SSMS之类的客户端工具连接到DMZ活动目录域中的SQL Server的工作就没有以前那样了。在XP中，只要我以某种方式在服务器上进行了身份验证(例如，将Explorer定向到\ server.dmzdomain \ c $并在登录提示符下输入有效凭据)，SSMS就会使用这些缓存的凭据进行连接。

但是，由于切换到Vista，当尝试将SSMS连接到DMZ域中的服务器时，我收到消息"用户登录失败"。该用户未与受信任的SQL Server连接相关联。如果将连接选项更改为使用命名管道而不是默认的TCP / IP，则会发送我的缓存凭据，并且一切正常。无论Windows防火墙处于打开还是关闭状态，并且与我们内部域(与我的开发PC所在的域相同)中的服务器的连接都可以通过TCP / IP或者命名管道正常工作。

我不太介意将命名管道用于这些连接，这是一种解决方法，但是似乎TCP / IP是推荐的连接方法，而且我不喜欢不理解为什么它无法按预期运行。有任何想法吗？

解决方案

回答

我们是否尝试过以提升模式运行SSMS，并且在客户端上安装了最新的SP？

回答

我认为这是因为Vista彼此隔离地运行大多数应用程序。

我建议我们或者设置DMZ用户名和密码以匹配内部域用户名和密码，或者使用命名管道进行连接。

回答

"用户''登录失败，该用户未与可信SQL Server连接关联"。

在这种情况下，客户端可能会进行tcp连接，此外，无论是否注册了SPN，SQL Server都无法识别客户端凭据，无论它是在本地管理员帐户还是非管理员计算机帐户下运行的。

解决方法是：

在目标SQL Server计算机上使用相同的密码在客户端计算机上创建与该帐户相同的帐户，然后向该帐户授予适当的权限。

让我们更详细地解释一下：

当我们在两者上创建相同的NT帐户(我们将其称为usr1)时
工作站，我们实际上是连接并模拟了本地帐户
连接站。也就是说，当我们从站点1连接到站点2时，
我们正在通过station2的帐户进行身份验证。因此，如果我们将
SQL Server的启动帐户(假设它在station2上运行)是
当我们使用station1的usr1从station1连接到SQL时，station2的usr1
登录后，SQL会将我们验证为station2的usr1.

现在，在SQL中，我们绝对可以访问station1的资源。虽然，如何
大量访问将取决于station1的usr1权限。

到目前为止，SQL只处理属于sysadmin角色的用户
SQL Server。为了允许其他用户(非sysamdin)访问网络资源，
我们将必须设置代理帐户。看一下这篇文章
添加信息。
摘自http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx