Melpomene - Fotolia
So vermeiden Sie Probleme beim zweiten Hop mit PowerShell
Wenn Sie über eine Remote-Sitzung in PowerShell auf ein drittes Gerät zugreifen möchten, treten manchmal Probleme auf. Wir stellen CredSSP und andere Lösungswege vor.
PowerShell-Remoting eignet sich hervorragend zum Verwalten von Remoteservern. Das geht solange gut, bis Sie auf das gefürchtete Double-Hop-Problem (Zweiter Hop) stoßen.
Klassischerweise tritt der Fehler auf, wenn Sie auf einem Remotecomputer arbeiten und versuchen, einen PowerShell-Befehl auf einem anderen Server auszuführen. Sie erhalten aber eine Meldung, dass der Server Ihnen den Zugriff verweigert. Dieser Fehler durch einen zweiten Hop entsteht klassischerweise so:
- Ein Administrator meldet sich bei Server 1 an.
- Sobald er sich auf Server 1 befindet, startet der Administrator eine Remote-PowerShell-Sitzung und stellt eine Verbindung zu Server 2 her.
- Ein auf Server 2 (über PowerShell-Remoting) ausgeführter Befehl versucht, auf Server 3 zuzugreifen.
In einer solchen Situation ist der Zugriff auf die Ressourcen von Server 3 blockiert, da die Anmeldeinformationen zum Aufbau der PowerShell-Remoteverbindung zwischen Server 1 und Server 2 nicht an Server 3 weitergegeben werden. CredSSP ist ein Weg, um dieses Double-Hop-Problem zu umgehen, aber es gibt eine bessere Lösung, die Sie ausprobieren können.
Warum das Double-Hop-Problem auftritt
Nachdem Sie eine Verbindung zu einem Remotecomputer mit PowerShell hergestellt haben und versuchen, Befehle an eine Ressource außerhalb dieses Computers zu senden, erhalten Sie möglicherweise die folgende Ausgabe:
Invoke-Command -ComputerName SRV1 -ScriptBlock { Get-ChildItem -Path \\SRV2\c$ }
Access is denied
+CategoryInfo: PermissionDenied: (\\SRV2\c$:String) [Get-ChildItem], UnauthorizedAccessException
+ FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand
+ PSComputerName: SRV1
Cannot find path '\\SRV2\c$' because it does not exist.
+ CategoryInfo : ObjectNotFound: (\\SRV2\c$:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
+ PSComputerName: SRV1
Man könnte meinen, dass es funktionieren müsste, weil Sie die Anmeldeinformationen auf dem Remotecomputer authentifiziert haben und diese Anmeldeinformationen über die Berechtigung zum Zugriff auf den zweiten Remotecomputer verfügen. Active-Directory-Domänen verwenden jedoch Kerberos für die Authentifizierung, was die Weitergabe von Anmeldeinformationen über den ersten Computer hinaus nicht erlaubt, um Angriffe zu verhindern.
Einige Administratoren lösen das Double-Hop-Problem mit CredSSP, einer weniger sicheren Methode, die einige zusätzliche Konfigurationsarbeiten erfordert. Aber es gibt noch eine andere Möglichkeit. Sie können einen Berechtigungsnachweis mit einer PowerShell-Sitzungskonfiguration verknüpfen und die Konfiguration für alle zukünftigen Verbindungen wiederverwenden.
Einrichten neuer PowerShell-Sitzungskonfigurationen zur Annahme von Anmeldeinformationen
In diesem Beispiel arbeiten wir mit einem Server namens SRV1 und erstellen eine neue Sitzungskonfiguration auf diesem Computer mit dem Cmdlet Register-PSSessionConfiguration. Der folgende Befehl erstellt eine Sitzung mit dem Namen Demo und verwendet den RunAsCredential-Parameter, um die Sitzung auszuführen.
Invoke-Command -ComputerName SRV1 -ScriptBlock { Register-PSSessionConfiguration -Name Demo -RunAsCredential 'domain\mydomainaccount' -Force }
Mit diesem Befehl erstellt das System eine neue Sitzungskonfiguration auf dem Remotecomputer und erzwingt bei der Verbindung, dass sie immer die angegebenen Anmeldeinformation nutzen.
Als nächstes geben Sie die Konfiguration mit dem Parameter ConfigurationName an, wenn Sie Invoke-Command ausführen. Verwenden Sie denselben Befehl wie oben, aber mit der Demo-Konfiguration. Wenden Sie diese Sitzungskonfiguration an, wenn Sie das nächste Mal einen Befehl auf einem Remotecomputer ausführen, der eine Verbindung zu einem dritten Computer herstellt.
Invoke-Command -ComputerName 'SRV1' -ScriptBlock { Get-ChildItem -Path \\SRV2\c$ } -ConfigurationName
Demo
Verzeichnis: \\SRV1\c$
Modus LastWriteTime Länge Name PSComputerName
---- ------------- ------ ---- --------------
d----- 11/30/2016 11:35 AM Programmdateien SRV1
d----- 5/25/2017 11:32 AM Windows SRV1
Anstelle einer Meldung Zugriff verweigert führt der Remote-Servern den Befehl wie erwartet aus. Es besteht keine Notwendigkeit, CredSSP-Rollen auf dem Client oder dem Server zu verwenden, um das Double-Hop-Problem zu vermeiden. Die Konfiguration bleibt auf unbestimmte Zeit auf dem Remote-Server erhalten. Verwenden Sie einfach jedes Mal den Parameter ConfigurationName, wenn Sie Invoke-Command oder Enter-PSSession verwenden.
Automatisches Aufrufen des ConfigurationName-Parameters
Nachdem wir nun dieses PowerShell-Remoting-Problem gelöst haben, können wir das ganze etwas eleganter umsetzen. Mit der automatischen Variablen $PSDefaultParameterValues vermeiden Sie das Verwenden des ConfigurationName-Parameters von Vornherein. Programmieren Sie PowerShell so, dass es einen festgelegten Parameter für bestimmte Befehle nutzt.
Verwenden Sie den ConfigurationName-Parameter, und geben Sie bei jedem Aufruf von Invoke-Command den Wert der Sitzungsdemo an. Erstellen Sie dazu die Hash-Tabelle $PSDefaultParameterValues, und weisen Sie ihr den Schlüssel Invoke-Command:ConfigurationName und den Wert Demo zu, wie im Folgenden gezeigt:
$PSDefaultParameterValues = @{'Invoke-Command:ConfigurationName'='Demo' }
Alle diese Techniken sollten Ihnen helfen, effizienter zu arbeiten, wenn Sie PowerShell für die Arbeit mit Remotecomputern verwenden.
Andere Lösungen für das Double-Hop-Problem
CredSSP gilt als der einfachste Weg zum Überwinden des PowerShell-Double-Hop-Problems angesehen, aber es gibt auch andere Lösungen oder Umgehungen, darunter die folgenden:
- Das eingeschränkte Kerberos-Delegieren bietet eine bessere Sicherheit, erfordert jedoch einen Domänenadministrator, damit es funktioniert.
- Das ressourcenbasierte eingeschränkte Kerberos-Delegieren bietet zusätzliche Sicherheit und eine einfachere Konfiguration, wenn Sie Kerberos verwenden.
- Just Enough Administration-Techniken (JEA) bieten eine hohe Sicherheit, erfordern aber auch mehr Konfigurationsaufwand.
Andere Techniken wie PSSessionConfiguration und die Übergabe von Anmeldeinformationen innerhalb eines Invoke-Command-Skriptblocks sind relativ einfach zu konfigurieren und zu verwenden. Beide erfordern jedoch eine sorgfältige Verwaltung der Anmeldeinformationen, was für kleine Unternehmen oder unerfahrene Administratoren schwierig sein kann.
