PowerShell リモート処理での次ホップの実行

"2 番目のホップの問題" は、次のような状況を指します。

1. ServerA にログインしています。
2. ServerA から、リモート PowerShell セッションを開始して ServerB に接続します。
3. PowerShell リモート処理セッションを介して ServerB で実行するコマンドは、 ServerC 上のリソースへのアクセスを試みます。
4. PowerShell リモート処理セッションの作成に使用した資格情報が ServerB から ServerC に渡されないため、ServerC 上のリソースへのアクセスは拒否されます。

この問題に対処するには、いくつかの方法があります。 次の表に、好みの順序でメソッドを示します。

クレドSSP

認証には資格情報セキュリティ サポート プロバイダー (CredSSP) を使用できます。 CredSSP はリモート サーバー (ServerB) に資格情報をキャッシュするため、これを使用すると資格情報の盗難攻撃が発生します。 リモート コンピューターが侵害されると、攻撃者はユーザーの資格情報にアクセスできます。 CredSSP は、既定では、クライアント コンピューターとサーバー コンピューターの両方で無効になっています。 CredSSP は、最も信頼性の高い環境でのみ有効にしてください。 たとえば、ドメイン コントローラーが高い信頼を持っているため、ドメイン コントローラーに接続しているドメイン管理者などです。

PowerShell リモート処理に CredSSP を使用する場合のセキュリティ上の問題の詳細については、「 偶発的な破壊活動: CredSSP に注意する」を参照してください。

資格情報の盗難攻撃の詳細については、「 Pass-the-Hash (PtH) 攻撃とその他の資格情報の盗難の軽減」を参照してください。

PowerShell リモート処理に CredSSP を有効にして使用する方法の例については、「 CredSSP を使用して PowerShell の "秒ホップ" 機能を有効にする」を参照してください。

利点

• Windows Server 2008 以降のすべてのサーバーで機能します。

短所

• セキュリティの脆弱性があります。
• クライアント ロールとサーバー ロールの両方の構成が必要です。
• は、Protected Users グループでは機能しません。 詳細については、「 保護されたユーザーのセキュリティ グループ」を参照してください。

Kerberos の制約付き委任

(リソース ベースではなく) レガシ制約付き委任を使用して、2 番目のホップを作成できます。 [Use any authentication protocol]\(任意の認証プロトコルを使用する\) オプションを使用して Kerberos の制約付き委任を構成して、プロトコルの移行を許可します。

利点

• 特別なコーディングは必要ありません
• 資格情報は格納されません。

短所

• WinRM の 2 番目のホップはサポートされていません。
• 構成するにはドメイン管理者アクセスが必要です。
• リモート サーバー (ServerB) の Active Directory オブジェクトで構成する必要があります。
• 1 つのドメインに制限されます。 ドメインまたはフォレストをまたがることはできません。
• オブジェクトとサービス プリンシパル名 (SPN) を更新する権限が必要です。
• ServerB は、ユーザーの介入なしに、ユーザーに代わって ServerC への Kerberos チケットを取得できます。

リソース ベースの Kerberos の制約付き委任

リソースベースの Kerberos 制約付き委任 (Windows Server 2012 で導入) を使用して、リソースが存在するサーバー オブジェクトに資格情報の委任を構成します。 上記の 2 番目のホップ シナリオでは、委任された資格情報を受け入れる場所を指定するように ServerC を構成します。

利点

• 資格情報は格納されません。
• PowerShell コマンドレットを使用して構成します。 特別なコーディングは必要ありません。
• 構成にドメイン管理者アクセスは必要ありません。
• ドメインとフォレスト間で機能します。

短所

• Windows Server 2012 以降が必要です。
• WinRM の 2 番目のホップはサポートされていません。
• オブジェクトとサービス プリンシパル名 (SPN) を更新する権限が必要です。

例

ServerB からの委任された資格情報を許可するように ServerC でリソースベースの制約付き委任を構成する PowerShell の例を見てみましょう。 この例では、すべてのサーバーがサポートされているバージョンの Windows Server を実行しており、信頼されたドメインごとに少なくとも 1 つの Windows ドメイン コントローラーがあることを前提としています。

制約付き委任を構成する前に、 RSAT-AD-PowerShell 機能を追加して Active Directory PowerShell モジュールをインストールし、そのモジュールをセッションにインポートする必要があります。

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

使用可能ないくつかのコマンドレットに 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 を設定します。これには、関連付けられているアカウントに資格情報を委任するアクセス許可を持つアカウント (この例では、ServerA のマシン アカウント) を指定するアクセス制御リスト (ACL) が含まれます。

次に、サーバーを表すために使用する変数を設定します。

# 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 に委任できるようにするには、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

ドメイン間で 2 番目のホップを作成する場合は、 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 Protocol Extensions: Service for User and Constrained Delegation Protocol 1.3.2 S4U2proxy]MS-SFU
• PrincipalsAllowedToDelegateToAccount を使用した制約付き委任のないリモート管理

Kerberos 委任 (制約なし)

Kerberos の制約のない委任を使用して、2 番目のホップを作成することもできます。 すべての Kerberos シナリオと同様に、資格情報は格納されません。 このメソッドは、WinRM の 2 番目のホップをサポートしていません。

Just Enough Administration (JEA)

JEA を使用すると、管理者が PowerShell セッション中に実行できるコマンドを制限できます。 これは、第 2 ホップの問題を解決するために使用できます。

JEA の詳細については、「 Just Enough Administration」を参照してください。

利点

• 仮想アカウントを使用する場合、パスワードのメンテナンスは行われません。

短所

• WMF 5.0 以降が必要です。
• すべての中間サーバー (ServerB) での構成が必要です。

PSSessionConfiguration の RunAs 使用

ServerB でセッション構成を作成し、その RunAsCredential パラメーターを設定できます。

PSSessionConfiguration と RunAs を使用して 2 番目のホップの問題を解決する方法については、「マルチホップ PowerShell リモート処理の別のソリューション」を参照してください。

利点

• WMF 3.0 以降の任意のサーバーで動作します。

短所

• すべての中間サーバー (ServerB) で PSSessionConfiguration と RunAs を構成する必要があります。
• ドメイン の RunAs アカウントを使用する場合は、パスワードのメンテナンスが必要です

Invoke-Command スクリプト ブロック内で資格情報を渡す

Invoke-Command コマンドレットの呼び出しの 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 リモート処理のセキュリティに関する考慮事項