powershell - 使用 Kerberos 进行机器身份验证时 CredSSP PowerShell session 失败

Question

我们正在尝试对 multi-hop PowerShell remoting 使用 CredSSP 身份验证，并且我们的一个客户遇到了一个障碍，阻止他们在指定目标服务器的 FQDN 时使用 CredSSP 创建 PSSession。服务器和客户端都加入了同一个域，不相交的命名空间没有什么特别的。

在调试的过程中，我们把能想到的相关安全选项都打开了；具体来说:

• 我们已启用 GP 设置以允许使用通配符 SPN wsman/* 委派新凭据(标准和“仅使用 NTLM”)
• 我们已通过 *.domain.com 启用 WSMan 可信主机设置
• 我们(当然)在服务器和客户端上为 CredSSP 启用了 WSMan
• 我们在服务器上设置了 LocalAccountTokenFilterPolicy

打开所有这些设置后，这是我们在为 PSSession 尝试不同的身份验证方法时得到的结果:

• 使用 Kerberos 通过显式域凭据进行委派工作正常。
• 使用带有显式域凭据的委派协商效果很好。
• 使用 CredSSP 进行授权:
  • 使用域凭据连接到服务器的 FQDN 失败，错误为 There are currently no logon servers available to service the logon request
  • 使用域凭据，仅连接到服务器的主机名，失败并出现相同的错误
  • 使用服务器上本地帐户的凭据(我相信因此强制使用 NTLM 进行服务器身份验证)，连接到服务器的 FQDN，效果很好
  • 使用域凭据，连接到服务器的 IP 地址(从而强制使用 NTLM 进行服务器身份验证)，效果很好

因此，简而言之，只要我们使用 NTLM 进行服务器身份验证，CredSSP 就可以工作，而当我们使用 Kerberos 时，CredSSP 就会失败，但如果我们也使用 Kerberos 进行委派，则 Kerberos 绝对可以正常工作。这怎么可能，我们可以做些什么来使 CredSSP+Kerberos 起作用？

Answer 1

在微软部分工程师的帮助下，我们解决了这个问题:客户站点的域 Controller 是Server 2003，不支持CredSSP(需要Server 2008或更高版本)。

也就是说，带有 NTLM 的 CredSSP 可以工作，因为 NTLM 不涉及域 Controller ——它只是在客户端 (Windows 7 x64) 和服务器 (Server 2008 R2 x64) 之间。当您将 CredSSP 与 Kerberos 一起使用时，您现在涉及域 Controller (KDC)，它不知道如何处理 CredSSP 连接，因此失败。

因此，在客户可以升级他们的域 Controller 之前，他们将使用本地用户帐户通过我们的部署工具进行远程操作，从而将域排除在外。