在 PowerShell 遠端中建立第二個躍點

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

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

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

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

CredSSP

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

如需使用 CredSSP 進行 PowerShell 遠端處理時的安全性考慮詳細資訊，請參閱 意外破壞：注意 CredSSP。

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

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

優點

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

缺點

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

Kerberos 限制委派

您可以使用舊版限制委派（而非以資源為基礎）來建立第二個躍點。 使用 [使用任何驗證通訊協定] 選項設定 Kerberos 限制委派，以允許通訊協議轉換。

優點

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

缺點

• 不支援 WinRM 的第二個躍點。
• 需要網域 管理員 istrator 存取權才能進行設定。
• 必須在遠端伺服器的 Active Directory 物件上設定 （ServerB）。
• 限制為一個網域。 無法跨網域或樹系。
• 需要更新物件和服務主體名稱 （SPN） 的許可權。
• ServerB 可以代表使用者取得 ServerC 的 Kerberos 票證，而不需使用者介入。

注意

具有 帳戶且無法委派屬性集且無法委派 的 Active Directory 帳戶。 如需詳細資訊，請參閱安全性焦點：分析特殊許可權帳戶和 Kerberos 驗證工具和 設定「帳戶是敏感性且無法委派」。

以資源為基礎的 Kerberos 限制委派

使用以資源為基礎的 Kerberos 限制委派（在 Windows Server 2012 中引進），您可以在資源所在的伺服器對象上設定認證委派。 在上述的第二個躍點案例中，您會設定 ServerC 指定接受委派認證的所在位置。

優點

• 認證不會儲存。
• 使用 PowerShell Cmdlet 進行設定。 不需要特殊編碼。
• 不需要網域 管理員 istrator 存取權進行設定。
• 跨網域和樹系運作。

缺點

• 需要 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 遠端處理） 預設會以電腦帳戶的形式執行。 您可以藉由查看 服務的 StartName 屬性 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 分鐘以清除快取。

清除快取之後，您可以透過 ServerB 成功執行 ServerA到 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 應用程式 Proxy 部署的 Kerberos 限制委派
• [MS-ADA2 Active Directory 架構屬性 M2.210 屬性 msDS-AllowedToActOnBehalfOfOtherIdentity]MS-ADA2
• [MS-SFU Kerberos 通訊協定延伸模組：使用者和限制委派通訊協定 1.3.2 S4U2proxy 的服務]MS-SFU
• 使用 PrincipalsAllowedToDelegateToAccount 不受限制委派的遠端 管理員 istration

Kerberos 委派 （不受限制）

您也可以使用 Kerberos 不受限制的委派來建立第二個躍點。 與所有 Kerberos 案例一樣，認證不會儲存。 此方法不支援 WinRM 的第二個躍點。

警告

此方法不會控制使用委派認證的位置。 它比 CredSSP 不安全。 這個方法只應用於測試案例。

Just Enough Administration (JEA)

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

如需 JEA 的相關信息，請參閱 Just Enough 管理員 istration。

優點

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

缺點

• 需要 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 遠端安全性考慮