Ausführen des zweiten Hops in PowerShell-Remoting

Das sogenannte „zweite Hop-Problem“ bezieht sich auf folgende Situation:

1. Sie sind bei ServerA angemeldet.
2. Sie starten von ServerA aus eine PowerShell-Remotesitzung, um eine Verbindung mit ServerB herzustellen.
3. Ein auf ServerB über Ihre PowerShell-Remotesitzung ausgeführter Befehl versucht, auf eine Ressource auf ServerC zuzugreifen.
4. Der Zugriff auf die Ressource auf ServerC wird verweigert, da die Anmeldeinformationen, die Sie zum Erstellen der PowerShell-Remotesitzung verwendet haben, nicht von ServerB an ServerC übergeben werden.

Es gibt verschiedene Möglichkeiten, um dieses Problem zu lösen. In der folgenden Tabelle werden die Methoden in der Reihenfolge ihrer Präferenz aufgelistet.

CredSSP

Sie können den Credential Security Support Provider (CredSSP) für die Authentifizierung verwenden. CredSSP speichert Anmeldeinformationen auf dem Remoteserver ServerB. Der Server wird dadurch der Gefahr von Angriffen zum Diebstahl der Anmeldeinformationen ausgesetzt. Wenn der Remotecomputer kompromittiert ist, hat der Angreifer Zugriff auf die Anmeldeinformationen des Benutzers. CredSSP ist standardmäßig sowohl auf Client- als auch auf Servercomputern deaktiviert. Sie sollten CredSSP nur in absolut vertrauenswürdigen Umgebungen aktivieren. Beispielsweise wenn ein Domänenadministrator eine Verbindung mit einem Domänencontroller herstellt, weil der Domänencontroller hochgradig vertrauenswürdig ist.

Weitere Informationen zu Sicherheitsaspekten bei der Verwendung von CredSSP für PowerShell-Remoting finden Sie unter Versehentliche Sabotage: Vorsicht vor CredSSP.

Weitere Informationen zu Angriffen zum Diebstahl von Anmeldeinformationen finden Sie unter Abschwächen von Pass-the-Hash-Angriffen (PtH) und anderen Techniken zum Diebstahl von Anmeldeinformationen.

Ein Beispiel zum Aktivieren und Verwenden von CredSSP für PowerShell-Remoting finden Sie unter Enable PowerShell "Second-Hop" Functionality with CredSSP (Aktivieren der PowerShell-Funktion für zweiten Hop mit CredSSP).

Vorteile

• Die Lösung eignet sich für alle Server mit Windows Server 2008 oder höher.

Nachteile

• birgt Sicherheitsrisiken
• erfordert die Konfiguration von Client- und Serverrollen
• Funktioniert nicht mit der Gruppe „Geschützte Benutzer“. Weitere Informationen finden Sie unter Sicherheitsgruppe „Geschützte Benutzer“.

Eingeschränkte Kerberos-Delegierung

Sie können eingeschränkte Legacydelegierung (nicht ressourcenbasiert) verwenden, um den zweiten Hop auszuführen. Konfigurieren Sie die eingeschränkte Kerberos-Delegierung mit der Option „Beliebiges Authentifizierungsprotokoll verwenden“, um den Protokollübergang zu ermöglichen.

Vorteile

• erfordert keine besondere Codierung
• Die Anmeldeinformationen werden nicht gespeichert.

Nachteile

• Keine Unterstützung für den zweiten Hop für WinRM
• Erfordert Domänenadministratorzugriff für die Konfiguration
• muss auf dem Active Directory-Objekt des Remoteservers konfiguriert werden (ServerB)
• auf einen Server begrenzt; Kann Domänen oder Gesamtstrukturen nicht überschreiten
• erfordert Rechte zum Aktualisieren von Objekten und Dienstprinzipalnamen (SPN)
• ServerB kann ein Kerberos-Ticket für ServerC im Auftrag des Benutzers abrufen, ohne dass ein Benutzereingriff erforderlich ist.

Ressourcenbasierte eingeschränkte Kerberos-Delegierung

Mithilfe von ressourcenbasierter eingeschränkter Kerberos-Delegierung (in Windows Server 2012 eingeführt) können Sie die Delegierung der Anmeldeinformationen für das Serverobjekt konfigurieren, in dem sich Ressourcen befinden. Im zuvor beschriebenen zweiten Hop-Szenario konfigurieren Sie ServerC und geben an, von wo aus Anmeldeinformationen akzeptiert werden.

Vorteile

• Die Anmeldeinformationen werden nicht gespeichert.
• Konfiguriert mithilfe von PowerShell-Cmdlets Keine besondere Codierung erforderlich
• Erfordert keinen Domänenadministratorzugriff für die Konfiguration
• domänen- und gesamtstrukturübergreifende Funktionsweise

Nachteile

• erfordert Windows Server 2012 oder höher
• Keine Unterstützung für den zweiten Hop für WinRM
• erfordert Rechte zum Aktualisieren von Objekten und Dienstprinzipalnamen (SPN)

Beispiel

Sehen wir uns ein PowerShell-Beispiel an, bei dem ServerC für eine ressourcenbasierte eingeschränkte Delegierung konfiguriert wird, um delegierte Anmeldeinformationen von einem ServerB zu ermöglichen. In diesem Beispiel wird davon ausgegangen, dass alle Server unterstützte Versionen von Windows Server ausführen und dass für jede vertrauenswürdige Domäne mindestens ein Windows-Domänencontroller vorhanden ist.

Bevor Sie die eingeschränkte Delegierung konfigurieren können, müssen Sie das RSAT-AD-PowerShell-Feature hinzufügen, um das Active Directory-PowerShell-Modul zu installieren und anschließend dieses Modul in die Sitzung zu importieren:

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

Mehrere verfügbare Cmdlets haben jetzt einen PrincipalsAllowedToDelegateToAccount-Parameter:

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

Der Parameter PrincipalsAllowedToDelegateToAccount legt das Active Directory-Objektattribut MsDS-AllowedToActOnBehalfOfOtherIdentity fest, das eine Zugriffssteuerungsliste (access control list, ACL) enthält. Diese gibt an, welche Konten die Berechtigung zum Delegieren von Anmeldeinformationen für das zugehörige Konto haben (in unserem Beispiel das Computerkonto für ServerA).

Richten Sie nun die Variablen ein, die wir verwenden, um die Server darzustellen:

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

WinRM (und somit die PowerShell-Remoting) wird standardmäßig als Computerkonto ausgeführt. Dies sehen Sie anhand der StartName-Eigenschaft des winrm-Diensts:

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

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

Damit ServerC die Delegierung aus einer PowerShell-Remoting-Sitzung auf ServerB zulässt, vergeben wir Zugriffsrechte, indem wir den Parameter PrincipalsAllowedToDelegateToAccount von ServerC auf das Computerobjekt von ServerB festlegen:

# 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

Das Kerberos-Schlüsselverteilungscenter (KDC) speichert verweigerte Zugriffsversuche (negativer Cache) über einen Zeitraum von 15 Minuten. Wenn ServerB zuvor versucht hat, auf ServerC zuzugreifen, müssen Sie zum Löschen des Caches auf ServerB folgenden Befehl aufrufen:

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

Sie können den Computer auch neu starten oder mindestens 15 Minuten warten, bevor Sie den Cache löschen.

Nach dem Löschen des Cache können Sie erfolgreich Code vom ServerA über ServerB auf ServerC ausführen:

# 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)
}

In diesem Beispiel wird die $using-Variable verwendet, um die $ServerC-Variable für ServerB sichtbar zu machen. Weitere Informationen zur $using-Variable finden Sie unter About Remote Variables (Informationen zu Remote-Variablen).

Damit mehrere Server Anmeldeinformationen an ServerC delegieren können, müssen Sie den Wert des Parameters PrincipalsAllowedToDelegateToAccount auf ServerC auf ein Array festlegen:

# 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

Wenn Sie den zweiten Hop zwischen Domänen vornehmen möchten, verwenden Sie den Parameter Server, um den vollqualifizierten Domänennamen (Fully-Qualified Domain Name, FQDN) des Domänencontrollers jener Domäne anzugeben, zu der ServerB gehört:

# 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

Um die Delegierung von Anmeldeinformationen an ServerC zu löschen, müssen Sie den Wert des Parameters PrincipalsAllowedToDelegateToAccount auf ServerC auf $null festlegen:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informationen zu ressourcenbasierter eingeschränkter Kerberos-Delegierung

• Neues bei der Kerberos-Authentifizierung
• How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 1 (Wie Windows Server 2012 bei den Problemen mit der eingeschränkten Kerberos-Delegierung Abhilfe schafft, Teil 1)
• How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2 (Wie Windows Server 2012 bei den Problemen mit der eingeschränkten Kerberos-Delegierung Abhilfe schafft, Teil 2)
• Grundlegendes zur eingeschränkten Kerberos-Delegierung für Microsoft Entra-Anwendungsproxybereitstellungen mit integrierter Windows-Authentifizierung
• [MS-ADA2: Active Directory-Schemaattribute M2.210 msDS-AllowedToActOnBehalfOfOtherIdentity-Attribut]MS-ADA2
• [MS-SFU: Kerberos-Protokollerweiterungen: Protokoll 1.3.2 S4U2proxy für Service-for-User und eingeschränkte Delegierung]MS-SFU
• Remote Administration Without Constrained Delegation Using PrincipalsAllowedToDelegateToAccount (Remoteverwaltung ohne eingeschränkte Delegierung mit PrincipalsAllowedToDelegateToAccount)

Kerberos-Delegierung (uneingeschränkt)

Sie können auch die uneingeschränkte Kerberos-Delegierung verwenden, um den zweiten Hop auszuführen. Wie in allen Kerberos-Szenarios werden Anmeldeinformationen nicht gespeichert. Diese Methode unterstützt nicht den zweiten Hop für WinRM.

Just Enough Administration (JEA)

Mit JEA können Sie einschränken, welche Befehle ein Administrator während einer PowerShell-Sitzung ausführen darf. Das Toolkit kann verwendet werden, um das zweite Hop-Problem zu lösen.

Informationen zu JEA finden Sie unter Just Enough Administration.

Vorteile

• keine Kennwortverwaltungsaufgaben bei Verwendung eines virtuellen Kontos

Nachteile

• erfordert WMF 5.0 oder höher
• erfordert die Konfiguration auf jedem Zwischenserver (ServerB).

PSSessionConfiguration mithilfe von RunAs

Sie können eine Sitzungskonfiguration auf ServerB erstellen und ihren RunAsCredential-Parameter festlegen.

Weitere Informationen zur Verwendung von PSSessionConfiguration und RunAs, um das zweite Hop-Problem zu lösen, finden Sie unter Eine weitere Lösung für Multi-Hop-PowerShell-Remoting.

Vorteile

• funktioniert mit jedem Server mit WMF 3.0 oder höher

Nachteile

• erfordert die Konfiguration von PSSessionConfiguration und RunAs auf jedem Zwischenserver (ServerB)
• erfordert Kennwortverwaltungsaufgaben bei Verwendung eines Domänen-RunAs-Kontos

Übergeben von Anmeldeinformationen innerhalb eines Invoke-Command-Skriptblocks

Anmeldeinformationen können innerhalb des ScriptBlock-Parameters für einen Aufruf des Invoke-Command-Cmdlet übergeben werden.

Vorteile

• Erfordert keine spezielle Serverkonfiguration
• funktioniert auf jedem Server mit WMF 2.0 oder höher

Nachteile

• erfordert eine umständliche Codetechnik
• Wenn WMF 2.0 ausgeführt wird, wird eine andere Syntax zum Übergeben von Argumenten an eine Remotesitzung benötigt.

Beispiel

Das folgende Beispiel zeigt, wie Anmeldeinformationen in einem -Skriptblock übergeben werden:

# 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}
}

Weitere Informationen

Sicherheitsaspekte von PowerShell-Remoting