在 PowerShell 远程处理中进行第二步

“第二跳问题”是指如下情况：

1. 您已登录到ServerA。
2. 从ServerA，您启动远程 PowerShell 会话以连接ServerB。
3. 您通过 PowerShell Remoting 会话在 ServerB 上运行的命令尝试访问 ServerC 上的资源。
4. 对 ServerC 上的资源的访问被拒绝，因为用于创建 PowerShell Remoting 会话的凭据未从 ServerB 传递到 ServerC。

有几种方法可以解决这个问题。下表按优先顺序列出了这些方法。

平衡易用性和安全性

安全性更高，配置更简单

安全性高但需要域管理员

不推荐

可以提供最好的安全性，但需要更详细的配置

配置更简单，但需要凭证管理

使用最简单，但您必须提供凭据

信用SSP

您可以使用凭据安全支持提供程序 (CredSSP) 进行身份验证。 CredSSP 在远程服务器 (ServerB) 上缓存凭据，因此使用它会使您面临凭据盗窃攻击。如果远程计算机受到威胁，攻击者就可以访问用户的凭据。默认情况下，CredSSP 在客户端和服务器计算机上均处于禁用状态。您应该仅在最受信任的环境中启用 CredSSP。例如，域管理员连接到域控制器，因为该域控制器高度可信。

有关使用 CredSSP 进行 PowerShell 远程处理时的安全问题的更多信息，请参阅意外破坏：谨防 CredSSP。

有关凭证盗窃攻击的更多信息，请参阅缓解哈希传递 (PtH) 攻击和其他凭证盗窃。

有关如何启用和使用 CredSSP 进行 PowerShell 远程处理的示例，请参阅使用 CredSSP 启用 PowerShell“第二跳”功能。

优点

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

缺点

• 存在安全漏洞。
• 需要配置客户端和服务器角色。
• 不适用于受保护的用户组。有关更多信息，请参阅受保护的用户安全组。

Kerberos 约束委派

您可以使用旧版约束委派（不是基于资源的）来进行第二跃点。使用“使用任何身份验证协议”选项配置 Kerberos 约束委派以允许协议转换。

优点

• 不需要特殊编码
• 不存储凭据。

缺点

• 不支持 WinRM 的第二跃点。
• 需要域管理员访问权限才能配置。
• 必须在远程服务器 (ServerB) 的 Active Directory 对象上进行配置。
• 仅限于一个域。不能跨域或森林。
• 需要更新对象和服务主体名称 (SPN) 的权限。
• ServerB 可以代表用户获取到 ServerC 的 Kerberos 票证，无需用户干预。

笔记

无法委派设置了帐户敏感且无法委派属性的 Active Directory 帐户。有关详细信息，请参阅安全焦点：分析特权帐户的“帐户敏感且无法委派”以及 Kerberos 身份验证工具和设置。

基于资源的 Kerberos 约束委派

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

优点

• 不存储凭据。
• 使用 PowerShell cmdlet 配置。无需特殊编码。
• 不需要域管理员访问权限即可配置。
• 跨域和林工作。

缺点

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

笔记

无法委派设置了帐户敏感且无法委派属性的 Active Directory 帐户。有关详细信息，请参阅安全焦点：分析特权帐户的“帐户敏感且无法委派”以及 Kerberos 身份验证工具和设置。

例子

让我们看一个 PowerShell 示例，该示例在 ServerC 上配置基于资源的约束委派，以允许从 ServerB 委派凭据。此示例假设所有服务器都运行受支持的 Windows Server 版本，并且每个受信任域至少有一个 Windows 域控制器。

在配置约束委派之前，您必须添加RSAT-AD-PowerShell 功能来安装 Active Directory PowerShell 模块，然后将该模块导入到您的会话中：

Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Get-Command -ParameterName PrincipalsAllowedToDelegateToAccount

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

CommandType Name                 ModuleName
----------- ----                 ----------
Cmdlet      New-ADComputer       ActiveDirectory
Cmdlet      New-ADServiceAccount ActiveDirectory
Cmdlet      New-ADUser           ActiveDirectory
Cmdlet      Set-ADComputer       ActiveDirectory
Cmdlet      Set-ADServiceAccount ActiveDirectory
Cmdlet      Set-ADUser           ActiveDirectory

PrincipalsAllowedToDelegateToAccount 参数设置 Active Directory 对象属性 msDS-AllowedToActOnBehalfOfOtherIdentity，其中包含一个访问控制列表 (ACL)，指定哪些帐户有权将凭据委派给关联帐户 (在我们的示例中，它将是 ServerA 的计算机帐户）。

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

# Set up variables for reuse
$ServerA = $env:COMPUTERNAME
$ServerB = Get-ADComputer -Identity ServerB
$ServerC = Get-ADComputer -Identity ServerC

默认情况下，WinRM（以及 PowerShell 远程处理）作为计算机帐户运行。您可以通过查看 winrm 服务的 StartName 属性来查看这一点：

Get-CimInstance Win32_Service -Filter 'Name="winrm"' | Select-Object StartName

StartName
---------
NT AUTHORITY\NetworkService

为了使 ServerC 允许从 ServerB 上的 PowerShell 远程会话进行委派，我们必须将 ServerC 上的 PrincipalsAllowedToDelegateToAccount 参数设置为ServerB 的计算机对象：

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

# Check the value of the attribute directly
$x = Get-ADComputer -Identity $ServerC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
$x.'msDS-AllowedToActOnBehalfOfOtherIdentity'.Access

# Check the value of the attribute indirectly
Get-ADComputer -Identity $ServerC -Properties PrincipalsAllowedToDelegateToAccount

Kerberos 密钥分发中心 (KDC) 将拒绝访问尝试（负缓存）缓存 15 分钟。如果ServerB之前曾尝试访问ServerC，则需要通过调用以下命令清除ServerB上的缓存：

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

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

清除缓存后，您可以成功运行从ServerA到ServerB到ServerC的代码：

# Capture a credential
$cred = Get-Credential Contoso\Alice

# Test kerberos double hop
Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
    Test-Path \$($using:ServerC.Name)\C$
    Get-Process lsass -ComputerName $($using:ServerC.Name)
    Get-EventLog -LogName System -Newest 3 -ComputerName $($using:ServerC.Name)
}

在此示例中，$using 变量用于使 $ServerC 变量对 ServerB 可见。有关 $using 变量的更多信息，请参阅 about_Remote_Variables。

要允许多个服务器将凭据委托给 ServerC，请将 ServerC 上的 PrincipalsAllowedToDelegateToAccount 参数的值设置为数组：

# Set up variables for each server
$ServerB1 = Get-ADComputer -Identity ServerB1
$ServerB2 = Get-ADComputer -Identity ServerB2
$ServerB3 = Get-ADComputer -Identity ServerB3
$ServerC  = Get-ADComputer -Identity ServerC

$servers = @(
    $ServerB1,
    $ServerB2,
    $ServerB3
)

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $servers

如果要跨域进行第二跃点，请使用 Server 参数指定 ServerB 所属域的域控制器的完全限定域名 (FQDN) :

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

要删除将凭据委派给 ServerC 的功能，请将 ServerC 上的 PrincipalsAllowedToDelegateToAccount 参数值设置为 $null：

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

有关基于资源的 Kerberos 约束委派的信息

• Kerberos 身份验证的新增功能
• Windows Server 2012 如何减轻 Kerberos 约束委派的痛苦，第 1 部分
• Windows Server 2012 如何减轻 Kerberos 约束委派的痛苦，第 2 部分
• 了解具有集成 Windows 身份验证的 Microsoft Entra 应用程序代理部署的 Kerberos 约束委派
• [MS-ADA2 Active Directory 架构属性 M2.210 属性 msDS-AllowedToActOnBehalfOfOtherIdentity]MS-ADA2
• [MS-SFU Kerberos 协议扩展：用户服务和约束委派协议 1.3.2 S4U2proxy]MS-SFU
• 使用PrincipalsAllowedToDelegateToAccount 进行无约束委派的远程管理

Kerberos 委托（无约束）

您还可以使用 Kerberos 无约束委派来进行第二跃点。与所有 Kerberos 方案一样，不会存储凭据。此方法不支持 WinRM 的第二跃点。

警告

此方法无法控制委派凭据的使用位置。它的安全性不如 CredSSP。此方法只能用于测试场景。

足够的管理（JEA）

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

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

优点

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

缺点

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

使用 RunAs 的 PSSessionConfiguration

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

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

优点

• 适用于任何具有 WMF 3.0 或更高版本的服务器。

缺点

• 需要在每个中间服务器 (ServerB) 上配置 PSSessionConfiguration 和 RunAs。
• 使用域 RunAs 帐户时需要维护密码

在 Invoke-Command 脚本块内传递凭据

您可以在调用 Invoke-Command cmdlet 的 ScriptBlock 参数内传递凭据。

优点

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

缺点

• 需要一种笨拙的代码技术。
• 如果运行 WMF 2.0，则需要不同的语法来将参数传递到远程会话。

例子

以下示例显示如何在脚本块中传递凭据：

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

参见

PowerShell 远程处理安全注意事项