Ausführen des zweiten Hops in PowerShell-Remoting

  • Artikel

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.

Konfiguration Hinweis
CredSSP Ausgeglichene Benutzerfreundlichkeit und Sicherheit
Ressourcenbasierte eingeschränkte Kerberos-Delegierung Höhere Sicherheit mit einfacherer Konfiguration
Eingeschränkte Kerberos-Delegierung Hohe Sicherheit, erfordert jedoch einen Domänenadministrator
Kerberos-Delegierung (uneingeschränkt) Nicht empfohlen
Just Enough Administration (JEA) Kann die beste Sicherheit bieten, erfordert jedoch eine ausführlichere Konfiguration
PSSessionConfiguration mithilfe von RunAs Einfachere Konfiguration, erfordert jedoch Verwaltung von Anmeldeinformationen
Übergeben von Anmeldeinformationen innerhalb eines Invoke-Command-Skriptblocks Am einfachsten zu verwenden, jedoch müssen Anmeldeinformationen bereitgestellt werden

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.

Hinweis

Active Directory-Konten, für die die Eigenschaft Konto ist vertraulich und kann nicht delegiert werden festgelegt ist, können nicht delegiert werden. Weitere Informationen finden Sie unter Sicherheit im Fokus: Analyse von „Konto ist vertraulich und kann nicht delegiert werden“ für privilegierte Konten und Kerberos-Authentifizierungstools und -Einstellungen.

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)

Hinweis

Active Directory-Konten, für die die Eigenschaft Konto ist vertraulich und kann nicht delegiert werden festgelegt ist, können nicht delegiert werden. Weitere Informationen finden Sie unter Sicherheit im Fokus: Analyse von „Konto ist vertraulich und kann nicht delegiert werden“ für privilegierte Konten und Kerberos-Authentifizierungstools und -Einstellungen.

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

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.

Warnung

Diese Methode bietet keine Kontrolle darüber, wo die delegierten Anmeldeinformationen verwendet werden. Sie ist weniger sicher als CredSSP. Diese Methode sollte nur für Testszenarios verwendet werden.

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