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

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.

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

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.

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.

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

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.

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

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

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