Melpomene - Fotolia
Mit PowerShell das zweite Hop-Problem vermeiden
PowerShell Remoting eignet sich hervorragend zur Verwaltung von Remote-Servern – bis man mit dem Double-Hop-Problem konfrontiert werden. Eine Lösung für das Problem.
PowerShell Remoting, also das Ausführen von Remote-Befehlen per PowerShell, eignet sich hervorragend zur Verwaltung von Remote-Servern – bis Sie mit dem gefürchteten Double-Hop-Problem beziehungsweise zweite Hop-Problem konfrontiert werden.
In einem typischen Szenario arbeiten Sie auf einem Remote-Computer und versuchen, einen PowerShell-Befehl auf einem anderen Server auszuführen. Bekommen Sie die Nachricht Access Denied, also Zugriff verweigert, haben Sie das Double-Hop-Problem. Zwar können Sie Credential Security Support Provider (CredSSP) verwenden, um das Problem zu umgehen. Aber es gibt eine wesentlich elegantere Lösung, die Sie ausprobieren sollten.
Warum das zweite Hop-Problem auftritt
Nachdem Sie sich via PowerShell Remoting mit einem Remote-Computer verbunden haben und Befehle an eine Ressource außerhalb Ihres Computers gegeben haben, erhalten Sie möglicherweise diese Meldung:
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
Vielleicht gehen Sie davon aus, dass der Befehl hätte funktionieren müssen. Schließlich haben Sie die Anmeldeinformationen auf dem Remote-Computer authentifiziert und diese Anmeldeinformationen geben Ihnen die Berechtigung, auf den zweiten Remote-Computer zuzugreifen. Der Haken ist, dass Active-Directory-Domänen Kerberos für die Authentifizierung verwenden. Und dieses erlaubt die Weitergabe von Anmeldeinformationen über den ersten Computer hinaus nicht, um böswillige Aktivitäten zu verhindern.
Einige Administratoren lösen das zweite Hop-Problem wie angesprochen mit CredSSP. CredSSP ist eine weniger sichere Methode, die zusätzliche Konfigurationsarbeiten erfordert. Aber es gibt noch eine andere Möglichkeit. Sie können eine Anmeldeinformationen an eine PowerShell-Sitzungskonfiguration binden und die Konfiguration für alle zukünftigen Verbindungen wiederverwenden.
Legen Sie neue PowerShell-Sitzungskonfigurationen fest, um Anmeldeinformationen zu akzeptieren
In diesem Beispiel arbeiten wir mit einem Server namens SRV1 und erstellen auf diesem System eine neue Sitzungskonfiguration mit dem Cmdlet Register-PSSessionConfiguration. Der folgende Befehl erstellt eine Sitzung namens Demo und verwendet den Parameter RunAsCredential, um die Session auszuführen.
Invoke-Command -ComputerName SRV1 -ScriptBlock { Register-PSSessionConfiguration -Name Demo -RunAsCredential 'domain\mydomainaccount' -Force }
Dieser Befehl generiert eine neue Sitzungskonfiguration auf dem Remote-Computer. Das Kommando zwingt diesen, immer mit der angegebenen Berechtigung zu laufen, wenn er verbunden ist.
Geben Sie anschließend die Konfiguration mit dem Parameter ConfigurationName an, wenn Sie Invoke-Command ausführen. Verwenden Sie den gleichen Befehl wie oben, aber mit der Demo-Konfiguration. Verwenden Sie diese Sitzungskonfiguration, wenn Sie das nächste Mal einen Befehl auf einem Remote-Computer ausführen, der sich mit einem dritten Computer verbindet.
Invoke-Command -ComputerName 'SRV1' -ScriptBlock { Get-ChildItem -Path \\SRV2\c$ } -ConfigurationName Demo
Directory: \\SRV1\c$
Mode LastWriteTime Length Name PSComputerName
---- ------------- ------ ---- --------------
d----- 11/30/2016 11:35 AM Program Files SRV1
d----- 5/25/2017 11:32 AM Windows SRV1
<snip>
Anstelle der Zugriffsverweigerung wird nun der Befehl wie erwartet ausgeführt. Sie sehen: Um das Double-Hop-Problem zu vermeiden, muss CredSSP auf dem Client oder Server nicht eingesetzt werden. 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.
Rufen Sie automatisch den Parameter ConfigurationName auf
Nachdem wir das Problem gelöst haben, können Sie den Prozess nun effizienter gestalten. Mit der automatischen Variablen $PSDefaultParameterValues lässt es sich vermeiden, den Parameter ConfigurationName jedes Mal verwenden zu müssen. Sie können PowerShell programmieren, um einen bestimmten Parameter zu verwenden, wenn Sie einen bestimmten Befehl verwenden.
Verwenden Sie den Parameter ConfigurationName und geben Sie den Wert der Session Demo bei jedem Aufruf von Invoke-Command an. Dazu erstellen Sie die $PSDefaultParameterValues Hash-Tabelle und weisen ihr - wie unten gezeigt - einen Schlüssel von Invoke-Command:ConfigurationName und einen Wert von Demo zu.
$PSDefaultParameterValues = @{'Invoke-Command:ConfigurationName'='Demo' }
Alle diese Techniken helfen Ihnen, effizienter zu arbeiten, wenn Sie PowerShell für die Arbeit mit Remote-Computern verwenden.
