3

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

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

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

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

  • 使用 Kerberos 进行具有显式域凭据的委派工作正常。
  • 使用 Negotiate 进行具有显式域凭据的委派工作正常。
  • 使用 CredSSP 进行委派：
    • 使用域凭据连接到服务器的 FQDN 失败并显示错误当前没有可用于服务登录请求的登录服务器
    • 使用域凭据，仅连接到服务器的主机名，失败并出现相同的错误
    • 使用服务器上本地帐户的凭据（我相信因此强制 NTLM 进行服务器身份验证），连接到服务器的 FQDN，工作正常
    • 使用域凭据，连接到服务器的 IP 地址（从而强制 NTLM 进行服务器身份验证），工作正常

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

4

1 回答 1

0

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

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

因此，在客户可以升级他们的域控制器之前，他们将使用本地用户帐户通过我们的部署工具进行远程操作，从而将域从图片中删除。

于 2012-09-14T16:58:16.327 回答