在 PowerShell 远程处理中形成第二个跃点Making the second hop in PowerShell Remoting

  • 已登录到 ServerA。
  • 在 ServerA 中，启动远程 PowerShell 会话，以连接到 ServerB。
  • 通过 PowerShell 远程处理会话在 ServerB 上运行的命令尝试访问 ServerC 上的资源。
  • 已拒绝访问 ServerC 上的资源，因为用于创建 PowerShell 远程处理会话的凭据未从 ServerB 传递到 ServerC。
    有几种方法可以解决此问题：在本主题中，我们将了解第二个跃点问题的几种最受欢迎的解决方案。

可以使用 进行身份验证。CredSSP 会将凭据缓存在远程服务器 (ServerB) 上，因此使用它会给你带来凭据被盗攻击的风险。如果远程计算机被攻破，攻击者将有权访问用户的凭据。默认情况下，CredSSP 在客户端和服务器计算机上都处于禁用状态。应该仅在最受信任的环境中启用 CredSSP。例如，连接到域控制器的域管理员，因为域控制器是高度可信任的。

若要详细了解在使用 CredSSP 进行 PowerShell 远程处理时需要注意的安全问题，请参阅 Accidental Sabotage: Beware of CredSSP（非蓄意破坏：当心 CredSSP）。

有关凭据被盗攻击的详细信息，请参阅。

有关如何启用和使用 CredSSP 进行 PowerShell 远程处理的示例，请参阅使用 CredSSP 解决第二个跃点问题。

优点Pros

  • 它适用于运行 Windows Server 2008 或更高版本的所有服务器。

缺点Cons

  • 可能会造成安全漏洞。
  • 需要客户端和服务器角色的配置。

Kerberos 委派（非约束）Kerberos delegation (unconstrained)

还可以使用 Kerberos 非约束委派来形成第二个跃点。但是，此方法无法控制使用委派凭据的位置。

优点Pros

  • 无需特殊编码。

缺点Cons

  • 不支持 WinRM 的第二个跃点。
  • 无法控制使用凭据的位置，因此产生安全漏洞。

可以使用旧的约束委派（而非基于资源的委派）形成第二个跃点。"使用任何身份验证协议"选项配置 Kerberos 约束委派以允许协议转换。

备注

无法委派具有“敏感帐户，不能被委派”属性集的 Active Directory 帐户。有关详细信息，请参阅 Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts（安全聚焦：对特权帐户分析“敏感帐户，不能被委派”）和 .aspx)（Kerberos 身份验证工具和设置）

优点Pros

  • 无需特殊编码
  • 必须对远程服务器 (ServerB) 的 Active Directory 对象进行配置。
  • 限于一个域。不能跨域或林。
  • 需要权限才能更新对象和服务主体名称 (SPN)。

基于资源的 Kerberos 约束委派Resource-based Kerberos constrained delegation

通过使用（Windows Server 2012 中引入的）基于资源的 Kerberos 约束委派，在资源驻留的服务器对象上配置凭据委派。在上述第二个跃点场景中，配置 ServerC 以指定从何处接受委派凭据。

注意： 无法委派具有敏感帐户，不能被委派属性集的 Active Directory 帐户。 有关详细信息，请参阅 Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts（安全聚焦：对特权帐户分析“敏感帐户，不能被委派”）和 .aspx)（Kerberos 身份验证工具和设置）

优点Pros

  • 不存储凭据。
  • 使用 PowerShell cmdlet 进行配置相对容易 - 无需任何特殊编码。
  • 无需特殊域访问权限。
  • 可跨域和林使用。
  • PowerShell 代码。

缺点Cons

  • 要求 Windows Server 2012 或更高版本。
  • 不支持 WinRM 的第二个跃点。
  • 需要权限才能更新对象和服务主体名称 (SPN)。

示例Example

在配置约束委派前，必须先添加 功能以安装 Active Directory PowerShell 模块，然后将该模块导入会话：

现在多个可用的 cmdlet 具有 PrincipalsAllowedToDelegateToAccount 参数：

  1. PS C:\> Get-Command -ParameterName PrincipalsAllowedToDelegateToAccount
  3. CommandType Name                 ModuleName
  4. ----------- ----                 ----------
  5. Cmdlet      New-ADComputer       ActiveDirectory
  6. Cmdlet      New-ADServiceAccount ActiveDirectory
  7. Cmdlet      New-ADUser           ActiveDirectory
  8. Cmdlet      Set-ADComputer       ActiveDirectory
  9. Cmdlet      Set-ADServiceAccount ActiveDirectory
  10. Cmdlet      Set-ADUser           ActiveDirectory

PrincipalsAllowedToDelegateToAccount 参数可设置 Active Directory 对象属性 msDS AllowedToActOnBehalfOfOtherIdentity，其中包含一份访问控制列表 (ACL)，指定了哪些帐户有权向关联帐户委派凭据（在本示例中，该帐户为 Server 的计算机帐户）。

现在，我们来设置用于表示服务器的变量：

  1. # Set up variables for reuse
  2. $ServerA = $env:COMPUTERNAME
  3. $ServerB = Get-ADComputer -Identity ServerB
  4. $ServerC = Get-ADComputer -Identity ServerC

默认情况下，WinRM（由此还有 PowerShell 远程处理）作为计算机帐户运行。可通过查看 winrm 服务的 StartName 属性看到：

为了 ServerC 允许来自 ServerB 上的 PowerShell 远程处理会话的委派，我们通过将 ServerC 上的 PrincipalsAllowedToDelegateToAccount 参数设为 ServerB 的计算机对象来授予权限：

  1. # Grant resource-based Kerberos constrained delegation
  4. # Check the value of the attribute directly
  5. $x = Get-ADComputer -Identity $ServerC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
  6. $x.'msDS-AllowedToActOnBehalfOfOtherIdentity'.Access
  8. # Check the value of the attribute indirectly
  9. Get-ADComputer -Identity $ServerC -Properties PrincipalsAllowedToDelegateToAccount

Kerberos .aspx) 缓存拒绝访问尝试（负缓存）长达 15 分钟。如果 ServerB 先前已尝试访问 ServerC，则需要通过调用以下命令清除 ServerB 上的缓存：

  1. Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
  2.     klist purge -li 0x3e7
  3. }

还可以重启计算机，或等待至少 15 分钟，以清除缓存。

清除缓存之后，可以通过 ServerB 到 ServerC成功运行来自 ServerA 的代码：

若要允许多个服务器向 ServerC 委派凭据，在 ServerC 上将 PrincipalsAllowedToDelegateToAccount 参数的值设为数组：

  1. $ServerB1 = Get-ADComputer -Identity ServerB1
  2. $ServerB2 = Get-ADComputer -Identity ServerB2
  4. $ServerC  = Get-ADComputer -Identity ServerC
  6. # Grant resource-based Kerberos constrained delegation
  7. Set-ADComputer -Identity $ServerC `
  8.     -PrincipalsAllowedToDelegateToAccount @($ServerB1,$ServerB2,$ServerB3)

如果想要跨域形成第二个跃点，添加 ServerB 所属域的域控制器的完全限定域名 (FQDN)：

  1. # For ServerC in Contoso domain and ServerB in other domain
  2. $ServerB = Get-ADComputer -Identity ServerB -Server dc1.alpineskihouse.com
  3. $ServerC = Get-ADComputer -Identity ServerC
  4. Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

若要删除向 ServerC 委派凭据的功能，在 ServerC 上将 PrincipalsAllowedToDelegateToAccount 参数的值设为 $null：

基于资源的 Kerberos 约束委派的相关信息Information on resource-based Kerberos constrained delegation

可以在 ServerB 上创建会话配置并设置其 RunAsCredential 参数。

有关使用 PSSessionConfiguration 和 RunAs 解决第二个跃点问题的信息，请参阅 （多跃点 PowerShell 远程处理的另一种解决方案）。

优点Pros

  • 兼容任何运行 WMF 3.0 或更高版本的服务器。
  • 需要在每个中间服务器 (ServerB) 上配置 PSSessionConfiguration 和 RunAs。
  • 使用域 RunAs 帐户时要求密码维护

Just Enough Administration (JEA)Just Enough Administration (JEA)

JEA 允许限制管理员在 PowerShell 会话期间可以运行的命令。它可用于解决第二个跃点问题。

有关 JEA 的信息，请参阅 Just Enough Administration。

优点Pros

  • 使用虚拟帐户时无需密码维护。

缺点Cons

  • 需要 WMF 5.0 或更高版本。
  • 需要在每个中间服务器 (ServerB) 上进行配置。

可以在对 cmdlet 的调用的 ScriptBlock 参数内传递凭据。

优点Pros

  • 无需特殊服务器配置。
  • 适用于任何运行 WMF 2.0 或更高版本的服务器。

缺点Cons

  • 需要繁琐的代码技术。
  • 运行 WMF 2.0 时，需要不同的语法将参数传递到远程会话。

示例Example

以下示例演示了如何在 Invoke-command 脚本块中传递凭据：

  1. # This works without delegation, passing fresh creds
  2. # Note $Using:Cred in nested request
  3. $cred = Get-Credential Contoso\Administrator
  4. Invoke-Command -ComputerName ServerB -Credential $cred -ScriptBlock {
  5.     hostname
  6.     Invoke-Command -ComputerName ServerC -Credential $Using:cred -ScriptBlock {hostname}

另请参阅See also