自从前段时间在我的开发机器上迁移到 Vista 以来，从 SSMS 等客户端工具连接到我们 DMZ 活动目录域中的 SQL Server 并没有像以前那样工作。在 XP 中，只要我以某种方式在服务器上进行了身份验证（例如将 Explorer 定向到 \server.dmzdomain\c$ 并在登录提示中输入有效凭据），SSMS 就会使用这些缓存的凭据进行连接。
但是，自从切换到 Vista 后，当尝试将 SSMS 连接到 DMZ 域中的服务器时，我收到消息Login failed for user ''。用户未与受信任的 SQL Server 连接关联。 如果我将连接选项更改为使用命名管道而不是默认的 TCP/IP，则会发送我缓存的凭据并且一切正常。无论 Windows 防火墙是关闭还是打开，情况都是如此，并且与我们内部域（我的开发 PC 所在的域）中的服务器的连接通过 TCP/IP 或命名管道正常工作。
我不太介意为这些连接使用命名管道作为解决方法，但似乎 TCP/IP 是推荐的连接方法，我不喜欢不理解为什么它不能像我预期的那样工作。有任何想法吗？
"Login Failed for user ' ', the user is not associated with a trusted SQL Server connection".
In this scenario, client may make tcp connetion, plus, running under local admin or non-admin machine account, no matter SPN is registered or not, the client credential is obviously not recognized by SQL Server.
The workaround here is:
Create the same account as the one on the client machine with same password on the target SQL Server machine, and grant appropriate permission to the account.
Let's explain in more detail:
When you create the same NT account (let's call it usr1) on both workstations, you essentially connect and impersonate the local account of the connecting station. I.e when you connect from station1 to station2, you're being authenticated via the station2's account. So, if you set the startup account for SQL Server (let's assume it's running on station2) to be station2's usr1, when you connect to SQL from station1 with station1's usr1 login, SQL will authenticate you as station2's usr1.
Now, within SQL, you can definitely access station1's resources. Though, how much access will depend on station1's usr1 permission.
So far, SQL only deal with an user who is part of the sysadmin role within SQL Server. To allow other users (non-sysamdin) access to network resources, you will have to set the proxy account. Take a look at the article for additional info. taken from http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
我认为这是因为 Vista 运行大多数应用程序时都与其他应用程序隔离开来。
我建议您将 DMZ 用户名和密码设置为与内部域用户名和密码匹配，或者使用命名管道进行连接。
您是否尝试过在提升模式下运行 SSMS，并且您是否在客户端上安装了最新的 SP？