Freigeben über

Ausführen des zweiten Hops in PowerShell-Remoting

Das "zweite Hopproblem" bezieht sich auf eine Situation wie die folgenden:

  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 Zum Erstellen der PowerShell-Remoting-Sitzung verwendeten Anmeldeinformationen nicht von ServerB an ServerC übergeben werden.

Es gibt mehrere Möglichkeiten, dieses Problem zu beheben. In der folgenden Tabelle sind die Methoden in der Reihenfolge der Voreinstellung aufgeführt.

Konfiguration Hinweis
CredSSP Ausgewogene Benutzerfreundlichkeit und Sicherheit
Ressourcenbasierte eingeschränkte Kerberos-Delegierung Höhere Sicherheit mit einfacherer Konfiguration
Eingeschränkte Kerberos-Delegierung Hohe Sicherheit, erfordert jedoch Domänenadministrator
Kerberos-Delegierung (nicht eingeschränkt) Nicht empfohlen
Just Enough Administration (JEA) Kann die beste Sicherheit bereitstellen, erfordert jedoch eine detailliertere Konfiguration
PSSessionConfiguration mit RunAs Einfacher zu konfigurieren, erfordert jedoch die Verwaltung von Anmeldeinformationen
Übergeben von Anmeldeinformationen innerhalb eines Invoke-Command Skriptblocks Am einfachsten zu verwenden, aber Sie müssen Anmeldeinformationen angeben

CredSSP

Sie können den Credential Security Support Provider (CredSSP) für die Authentifizierung verwenden. CredSSP speichert Anmeldeinformationen auf dem Remoteserver (ServerB) zwischen, sodass Sie mit diesem Zugriff auf Anmeldeinformationendiebstahlangriffe geöffnet werden. 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 ist ein Domänenadministrator, der eine Verbindung mit einem Domänencontroller herstellt, da der Domänencontroller sehr vertrauenswürdig ist.

Weitere Informationen zu Sicherheitsbedenken bei der Verwendung von CredSSP für PowerShell Remoting finden Sie unter "Versehentliches Sabotage: Vorsicht vor CredSSP".

Weitere Informationen zu Diebstahl von Anmeldeinformationen finden Sie unter "Verringern von Pass-the-Hash(PtH)-Angriffen und anderen Diebstahl von Anmeldeinformationen".

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

Vorteile

  • Es funktioniert für alle Server mit Windows Server 2008 oder höher.

Nachteile

  • Hat Sicherheitsrisiken.
  • Erfordert die Konfiguration von Client- und Serverrollen.
  • funktioniert nicht mit der Gruppe "Geschützte Benutzer". Weitere Informationen finden Sie in der Sicherheitsgruppe "Geschützte Benutzer".

Eingeschränkte Kerberos-Delegierung

Sie können die ältere eingeschränkte Delegierung (nicht ressourcenbasiert) verwenden, um den zweiten Hop zu erstellen. Konfigurieren Sie die eingeschränkte Kerberos-Delegierung mit der Option "Beliebiges Authentifizierungsprotokoll verwenden", um den Protokollübergang zuzulassen.

Vorteile

  • Erfordert keine spezielle Codierung
  • Anmeldeinformationen werden nicht gespeichert.

Nachteile

  • Unterstützt nicht den zweiten Hop für WinRM.
  • Erfordert den Domänenadministratorzugriff, um die Konfiguration zu konfigurieren.
  • Muss für das Active Directory-Objekt des Remoteservers (ServerB) konfiguriert werden.
  • Auf eine Domäne beschränkt. Domänen- oder Gesamtstrukturen können nicht überschritten werden.
  • Erfordert Rechte zum Aktualisieren von Objekten und Dienstprinzipalnamen (Service Principal Names, SPNs).
  • ServerB kann ein Kerberos-Ticket für ServerC im Namen des Benutzers ohne Benutzereingriff erwerben.

Hinweis

Active Directory-Konten mit dem Konto sind vertraulich und können nicht delegiert werden . Weitere Informationen finden Sie unter Security Focus: 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 der ressourcenbasierten kerberos-eingeschränkten Delegierung (eingeführt in Windows Server 2012) konfigurieren Sie die Delegierung von Anmeldeinformationen für das Serverobjekt, in dem sich Ressourcen befinden. Im zweiten oben beschriebenen Hopszenario konfigurieren Sie ServerC so, dass sie angibt, wo delegierte Anmeldeinformationen akzeptiert werden.

Vorteile

  • Anmeldeinformationen werden nicht gespeichert.
  • Konfiguriert mithilfe von PowerShell-Cmdlets. Keine spezielle Codierung erforderlich.
  • Erfordert keinen Domänenadministratorzugriff, um die Konfiguration zu konfigurieren.
  • Funktioniert über Domänen und Gesamtstrukturen hinweg.

Nachteile

  • Erfordert Windows Server 2012 oder höher.
  • Unterstützt nicht den zweiten Hop für WinRM.
  • Erfordert Rechte zum Aktualisieren von Objekten und Dienstprinzipalnamen (Service Principal Names, SPNs).

Hinweis

Active Directory-Konten mit dem Konto sind vertraulich und können nicht delegiert werden . Weitere Informationen finden Sie unter Security Focus: 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, das ressourcenbasierte eingeschränkte Delegierung auf ServerC konfiguriert, um delegierte Anmeldeinformationen von einem ServerB zuzulassen. In diesem Beispiel wird davon ausgegangen, dass alle Server unterstützte Versionen von Windows Server ausführen und für jede vertrauenswürdige Domäne mindestens einen 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 dann dieses Modul in Ihre Sitzung importieren:

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

Mehrere verfügbare Cmdlets verfügen jetzt über einen Parameter "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

Der Parameter PrincipalsAllowedToDelegateToAccount legt das Active Directory-Objektattribut msDS-AllowedToActOnBehalfOfOtherIdentity fest, das eine Zugriffssteuerungsliste (Access Control List, ACL) enthält, die angibt, welche Konten über die Berechtigung zum Delegieren von Anmeldeinformationen an das zugeordnete Konto verfügen (in unserem Beispiel ist es das Computerkonto für ServerA).

Nun richten wir die Variablen ein, die wir für die Darstellung der Server verwenden:

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

WinRM (und daher PowerShell-Remoting) wird standardmäßig als Computerkonto ausgeführt. Sie können dies sehen, indem Sie sich die StartName-Eigenschaft des winrm Diensts ansehen:

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

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

Damit ServerC die Delegierung aus einer PowerShell-Remotingsitzung auf ServerB zulässt, müssen wir den Parameter PrincipalsAllowedToDelegateToAccount auf 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 Key Distribution Center (KDC) speichert 15 Minuten lang Denied-Access-Versuche (negativer Cache). Wenn ServerB zuvor versucht hat, auf ServerC zuzugreifen, müssen Sie den Cache auf ServerB löschen, indem Sie den 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, um den Cache zu löschen.

Nach dem Löschen des Caches können Sie Code von ServerA über ServerB auf ServerC erfolgreich 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 der Using: Bereichsmodifizierer verwendet, um die $ServerC Variable für ServerB sichtbar zu machen. Weitere Informationen zum Using: Bereichsmodifizierer finden Sie unter about_Remote_Variables.

Damit mehrere Server Anmeldeinformationen an ServerC delegieren können, legen Sie den Wert des Parameters PrincipalsAllowedToDelegateToAccount auf ServerC auf ein Array fest:

# 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 über Domänen hinweg durchführen möchten, verwenden Sie den Serverparameter , um vollqualifizierten Domänennamen (FQDN) des Domänencontrollers der 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 Möglichkeit zum Delegieren von Anmeldeinformationen an ServerC zu entfernen, legen Sie den Wert des Parameters PrincipalsAllowedToDelegateToAccount auf ServerC auf $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informationen zur ressourcenbasierten eingeschränkten Kerberos-Delegierung

Kerberos-Delegierung (nicht eingeschränkt)

Sie können auch die nicht eingeschränkte Kerberos-Delegierung verwenden, um den zweiten Hop zu machen. Wie alle Kerberos-Szenarien werden Anmeldeinformationen nicht gespeichert. Diese Methode unterstützt den zweiten Hop für WinRM nicht.

Warnung

Diese Methode bietet keine Kontrolle darüber, wo delegierte Anmeldeinformationen verwendet werden. Es ist weniger sicher als CredSSP. Diese Methode sollte nur für Testszenarien verwendet werden.

Just Enough Administration (JEA)

MIT JEA können Sie einschränken, welche Befehle ein Administrator während einer PowerShell-Sitzung ausführen kann. Es kann verwendet werden, um das zweite Hopproblem zu lösen.

Informationen zu JEA finden Sie unter Just Enough Administration.

Vorteile

  • Keine Kennwortwartung bei Verwendung eines virtuellen Kontos.

Nachteile

  • Erfordert WMF 5.0 oder höher.
  • Erfordert konfiguration auf jedem Zwischenserver (ServerB).

PSSessionConfiguration mit RunAs

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

Informationen zur Verwendung von PSSessionConfiguration und RunAs zur Lösung des zweiten Hopproblems 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 Kennwortwartung bei Verwendung eines Domänen-RunAs-Kontos

Übergeben von Anmeldeinformationen innerhalb eines Invoke-Command Skriptblocks

Sie können Anmeldeinformationen innerhalb des ScriptBlock-Parameters eines Aufrufs des Invoke-Command-Cmdlets übergeben.

Vorteile

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

Nachteile

  • Erfordert eine ungünstige Codetechnik.
  • Wenn WMF 2.0 ausgeführt wird, ist eine andere Syntax erforderlich, um Argumente an eine Remotesitzung zu übergeben.

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

Siehe auch

Überlegungen zur PowerShell-Remotingsicherheit