在 PowerShell 遠端操作中建立第二次跳躍

「第二躍點問題」是指類似下列情況：

1. 您已登入 ServerA。
2. 從 ServerA 開啟一個遠端 PowerShell 工作階段，以連線至 ServerB。
3. 您透過 PowerShell 遠端工作階段在 ServerB 上執行的命令會嘗試存取 ServerC 上的資源。
4. 拒絕存取 ServerC 上的資源，因為您用來建立 PowerShell 遠端會話的認證不會從 ServerB 傳遞至 ServerC。

有數種方式可以解決這個問題。 下表列出依喜好設定順序的方法。

設定	備註
CredSSP	平衡易於使用和安全性
以資源為基礎的 Kerberos 限制委派	使用更簡單的組態提高安全性
Kerberos 限制委派	高安全性，但需要網域管理員
Kerberos 委派 （不受限制）	不建議使用
Just Enough Administration （JEA）	可以提供最佳的安全性，但需要更詳細的設定
使用 RunAs 的 PSSessionConfiguration	設定更簡單，但需要認證管理
在 Invoke-Command 腳本區塊內傳遞認證資格	最簡單的使用，但您必須提供認證

CredSSP

您可以使用 認證安全性支援提供者 （CredSSP） 進行驗證。 CredSSP 會在遠端伺服器（ServerB）上快取認證，因此使用它會使您面臨認證竊取攻擊的風險。 如果遠端電腦遭到入侵，攻擊者就能存取使用者的認證。 用戶端和伺服器電腦上的 CredSSP 都預設停用。 只有在最受信任的環境中才應啟用 CredSSP。 例如，域系統管理員會連接到域控制器，因為域控制器受到高度信任。

如需有關在 PowerShell 遠端處理時使用 CredSSP 的安全性考量的更多資訊，請參閱 意外破壞：注意 CredSSP。

如需認證竊取攻擊的詳細資訊，請參閱 減輕傳遞哈希 （PtH） 攻擊和其他認證竊取。

如需如何啟用和使用 CredSSP 進行 PowerShell 遠端處理的範例，請參閱 使用 CredSSP 啟用 PowerShell「第二躍點」功能。

優點

• 它適用於所有具有 Windows Server 2008 或更新版本的伺服器。

缺點

• 有安全性弱點。
• 需要設定客戶端和伺服器角色。
• 不適用於受保護的使用者群組。 如需詳細資訊，請參閱 受保護的使用者安全組。

Kerberos 限制委派

您可以使用傳統限制式委派（而非以資源為基礎）來實現第二跳。 使用 [使用任何驗證通訊協定] 選項設定 Kerberos 限制委派，以允許通訊協議轉換。

優點

• 不需要特殊編碼
• 認證不會儲存。

缺點

• 不支援 WinRM 的第二個躍點。
• 需要網域系統管理員存取權才能進行設定。
• 必須在遠端伺服器的 Active Directory 物件上設定 （ServerB）。
• 限制為一個網域。 無法跨網域或樹系。
• 需要更新物件和服務主體名稱 （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 屬性來看到這一點：

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，請將 PrincipalsAllowedToDelegateToAccount 參數的值在 ServerC 上設定為一個陣列：

# 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 應用程式 Proxy 部署的 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 不安全。 這個方法只應用於測試案例。

Just Enough Administration （JEA）

JEA 可讓您限制系統管理員可以在PowerShell工作階段期間執行的命令。 它可以用來解決第二個躍點問題。

如需 JEA 的相關信息，請參閱 Just Enough Administration。

優點

• 使用虛擬帳戶時，不會進行密碼維護。

缺點

• 需要 WMF 5.0 或更新版本。
• 需要在每個中繼伺服器 （ServerB） 上進行設定。

使用 RunAs 的 PSSessionConfiguration

您可以在 ServerB 上建立工作階段組態，並設定其 RunAsCredential 參數。

如需使用 PSSessionConfiguration 和 RunAs 來解決第二個躍點問題的相關資訊，請參閱 多躍點 PowerShell 遠端的另一個解決方案。

優點

• 可與任何使用 WMF 3.0 或更新版本的伺服器協作。

缺點

• 需要在每個中繼伺服器上設定 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 遠端安全性考慮