自从前一段时间在我的开发计算机上迁移到Vista以来,从SSMS之类的客户端工具连接到DMZ活动目录域中的SQL Server一直没有像以前那样工作。在XP中,只要我以某种方式在服务器上进行了身份验证(例如,将Explorer定向到\ server.dmzdomain \ c $并在登录提示中输入有效凭据),SSMS就会使用这些缓存的凭据进行连接。
但是,由于切换到Vista,当尝试将SSMS连接到DMZ域中的服务器时,我收到消息“用户登录失败”。该用户未与受信任的SQL Server连接相关联。 如果将连接选项更改为使用命名管道而不是默认的TCP / IP,则会发送我的缓存凭据,并且一切正常。无论Windows防火墙处于打开还是关闭状态,并且与我们内部域(我的开发PC所在的域相同)中的服务器的连接都可以通过TCP / IP或命名管道正常工作。
我不太介意将命名管道用于这些连接,这是一种解决方法,但似乎TCP / IP是推荐的连接方法,而且我不喜欢不理解为什么它无法按预期运行。有任何想法吗?
“用户''登录失败,该用户未与受信任的SQL Server连接关联”。
在这种情况下,客户端可能会进行tcp连接,此外,无论是否注册了SPN,客户端凭据都显然无法被SQL Server识别,并且可以在本地管理员或非管理员计算机帐户下运行。
解决方法是:
在目标SQL Server计算机上使用相同的密码在客户端计算机上创建一个与该帐户相同的帐户,然后向该帐户授予适当的权限。
让我们更详细地解释一下:
在两个工作站上创建相同的NT帐户(我们将其称为usr1)时,实际上是连接并模拟了连接站的本地帐户。即,当您从station1连接到station2时,您正在通过station2的帐户进行身份验证。因此,如果将SQL Server的启动帐户(假设它在station2上运行)设置为station2的usr1,则当您使用station1的usr1登录名从station1连接到SQL时,SQL会将您的身份验证为station2的usr1。
现在,在SQL中,您绝对可以访问station1的资源。但是,多少访问将取决于station1的usr1权限。
到目前为止,SQL只处理属于SQL Server中sysadmin角色的用户。若要允许其他用户(非sysamdin)访问网络资源,则必须设置代理帐户。看一下文章以获取更多信息。摘自http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。