Second-Hop-Problem: CredSSP für PowerShell-Remoting konfigurieren

    Remote-ManagementCredential Security Support Provider (CredSSP) ist ein Mecha­nismus, um Anmelde­daten von einem Rechner an weitere Maschinen zu dele­gieren. Er erlaubt so den Zugriff aus einer PowerShell-Remote-Session auf Ressourcen anderer PCs. CredSSP lässt sich über PowerShell oder Gruppen­richt­linien konfi­gurieren.

    Beim Einsatz von CredSSP ist oft die Rede vom Second-Hop-Problem, das sich immer dann ergibt, wenn man aus einer Remote-Sitzung auf andere Rechner zugreifen möchte, etwa um Dateien von einem File-Share zu laden.

    Dies würde normaler­weise scheitern, weil Server B, mit dem man über eine Remote-Sitzung ver­bunden ist, die Creden­tials an Server C nicht durch­reicht und so die Authen­tifi­zierung scheitert.

    Eine Lösung für das Second-Hop-Problem ist CredSSPCredSSP löst dieses Problem, aber nur für einen zusätz­lichen Hop. Es lässt sich relativ einfach konfi­gurieren und funk­tioniert auch in Workgroups, ist aber unsicher, da die Credentials auf der Zwischen­station im Cache vorge­halten werden.

    Microsoft nutzt CredSSP selbst zum Bei­spiel im Windows Admin Center, rät aber dazu, nach dem Abschluss der ent­sprechenden Arbeiten dieses Proto­koll wieder zu deak­tivieren.

    CredSSP läuft über WinRM und setzt somit voraus, dass dieses auf dem Client und dem Server akti­viert wurde. Dies lässt sich über die Komman­do­zeile oder Gruppen­richt­linien bewerk­stelli­gen.

    Status von CredSSP abfragen

    Ist diese Bedingung erfüllt, dann kann man mit dem PowerShell-Cmdlet Get-WSManCredSSP prüfen, ob und in welcher Form CredSSP aktiviert ist. Per Voreinstellung ist es abgeschaltet. Ist es hingegen bereits eingerichtet, dann kann man es mit Disable-WSManCredSSP für Client und Server getrennt abschalten:

    Disable-WSManCredSSP -Role <Client|Server>

    CredSSP-Konfiguration abfragen mit dem PowerShell-Cmdlet Get-WSManCredSSP

    Client und Server konfigurieren

    Auch die Konfiguration von CredSSP erfolgt separat für die Rollen Client und Server. Der Client ist der Rechner, von dem aus die Remote-Session ursprünglich geöffnet wurde (Computer A in der obigen Grafik), während der First Hop den CredSSP-Server repräsentiert (Computer B).

    Am Client aktiviert man CredSSP immer für bestimmte Ziele, zuständig ist dafür ein Aufruf von Enable-WSManCredSSP nach diesem Muster:

    Enable-WSManCredSSP -Role Client `
    -DelegateComputer server1.contoso.com, server2.contoso.com -Force

    In diesem Beispiel könnte der Client die Anmelde­daten an die zwei aufgeführten Server der Domäne contoso.com weitergeben. Der Schalter Force unterbindet die sonst erforderliche Bestätigung der Aktion durch den Benutzer.

    CredSSP auf dem Client aktivieren mit Enable-WSManCredSSP

    Anstatt mehrere Rechner aufzuzählen, kann man auch Wildcards in der Form *. contoso.com verwenden. Bei dieser Variante muss man aber nachher bei der CredSSP-Authentifizierung immer den vollständigen FQDN angeben.

    Beim Server beschränkt sich der Befehl auf

    Enable-WSManCredSSP -Role "Server"

    Eine Angabe von bestimmten Clients ist hier nicht vorgesehen.

    CredSSP über Gruppenrichtlinien konfigurieren

    Für den Fall, dass man in einer geschützten Umgebung CredSSP nicht nur temporär für bestimmte Aufgaben aktivieren möchte, kann man dafür die Gruppen­richtlinien nutzen. Erwartungs­gemäß erfolgt auch hier die Konfiguration getrennt nach Client und Server. Dabei liegt es nahe, jeweils separate GPOs zu verwenden, weil Rechner in der Regel nicht beide Rollen übernehmen.

    CredSSP aktiviert man über die Einstellung CredSSP-Authentifizierung zulassen unter Computer­konfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows-Remoteverwaltung (Windows Remote Management, WinRM). Sie findet sich sowohl unter WinRM-Client als auch WinRM-Dienst, wobei Letzterer für den Server steht.

    CredSSP für den Client mittels Gruppenrichtlinien aktivieren. Die gleiche Einstellung gibt es für den Server unter WinRM-Dienst.

    Client über GPO konfigurieren

    Während es für den Server reicht, diese Einstellung zu aktivieren, ist es für den Client zusätzlich notwendig, die Rechner anzugeben, an welche er die Credentials delegieren darf. Diese Angaben entsprechen jenen, die man über den Parameter DelegateComputer an Enable-WSManCredSSP übergibt.

    Das Pendant bei den Gruppen­richtlinien heißt Delegierung von aktuellen Anmelde­informationen zulassen und findet sich unter Computer­konfiguration => Richtlinien => Administrative Vorlagen => System => Delegierung und Anmeldeinformationen.

    Nach der Aktivierung dieser Einstellung fügt man die Rechner in die Liste ein, die man über den Button Anzeigen öffnen kann. Dabei verwendet man folgende Form:

    WSMAN/myserver.mydomain.com

    Rechner bestimmen, an die der Client die Credentials weitergeben darf.

    Auch hier kann man wieder Wildcards verwenden, um mehrere Hosts zu adressieren. Die Option Betriebs­systemstandards mit vorheriger Eingabe verknüpfen bedeutet, dass die vom Admin eingegebenen Server zur Liste der Rechner hinzugefügt wird, die per Default auf dem System bereits existiert.

    Die in manchen Anleitungen erwähnte Einstellung Vertrauenswürdige Hosts unter Computer­konfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows-Remoteverwaltung (Windows Remote Management, WinRM) => WinRM-Client wird zwischen Windows-Rechnern, die Mitglied einer AD-Domäne sind, nicht benötigt.

    CredSSP-Authentifizierung mit PowerShell

    Wenn man im obigen Beispiel in einer Remote-Session von Computer B aus auf Computer C zugreifen möchte, dann würde man nach erfolgter Aktivierung von CredSSP eine Session von Computer A zu Computer B so aufbauen:

    Enter-PSSession -ComputerName ComputerB.contoso.com `
    -Credential contoso\admin -Authentication Credssp

    Entscheidend ist hier der Parameter Authentication mit dem Wert Credssp.

    Anschließend kann man etwa mit Invoke-Command einen Befehl auf dem Drittrechner absetzen. Der folgende Screenshot zeigt eine erfolgreiche Delegierung der Credentials von hv-node-1 zu ws2019-core-en und anschließend einen fehl­geschlagenen Zugriff, wenn man auf die CredSSP-Authentifizierung verzichtet.

    Nur aus einer Session, die mit CredSSP-Authentifizierung erzeugt wurde, lassen sich Ressourcen eines weiteren Rechners nutzen.

    Neben Enter-PSSession akzeptieren auch weitere Cmdlets für das PowerShell-Remoting den Parameter Authentication:

    Get-Command -ParameterType *authentication* -noun *pssession

    Cmdlets für das PowerShell-Remoting, die den Parameter Authentication akzeptieren

    Dieser Aufruf von Get-Command fördert alle Cmdlets zum Aufbau oder Wieder­aufnahme einer Session zutage.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Keine Kommentare