PowerShell Remoting (Teil 1)

Hiermit möchte ich eine kleine Artikel-Serie starten, welche das Thema PowerShell Remoting behandelt, das meiner Meinung nach eines der besten PowerShell-Features ist.

Seit Windows PowerShell 2.0 gibt es die Funktion des sogenannten PowerShell Remoting, welches auf Windows Remote Management (WinRM) mit dem WSMan Protokoll basiert, verwendet wird hier dann im Grunde XML über HTTP/S.

In den nachfolgenden Beispielen werde ich immer die verschlüsselte Variante über HTTPS verwenden. Eine unverschlüsselte Verbindung ergibt gerade im administrativen Bereich wenig Sinn, zudem entstehen abgesehen von ein wenig mehr Konfigurationsaufwand durch die Einbindung oder spätere Aktualisierung des Zertifikats auch keine weiteren Nachteile. Für die Demonstrationszwecke verwende ich hier jedoch nur ein selbstsigniertes Zertifikat, für den produktiven Einsatz wäre ein CA-Zertifikat zu empfehlen. Ebenfalls beschränke ich mich auf eine IPv4 Verbindung, IPv6 wird jedoch auch vollständig unterstützt.

Seit Windows Server 2012 macht das New-SelfSignedCertificate Cmdlet die Erstellung eines selbstsignierten Zertifikats einfach. Die Angabe von Server FQDN sowie der Speicherort im Windows Zertifikatsspeicher reichen aus und man erhält ein 1 Jahr gültiges Zertifikat.

New-SelfSignedCertificate -DnsName Hostname.example.test -CertStoreLocation cert:\LocalMachine\My

Bei den Vorversionen kann man entweder den IIS Manager verwenden oder man kann sich das Microsoft Windows SDK herunterladen, welches das bekannte MakeCert.exe enthält. Dieses bietet weiterhin umfangreiche Optionen an, durch die alle Einstellungen der Zertifikats-Eigenschaften möglich sind. Hier ist wichtig, den enhanced key usage (eku) mit dem richtigen object identifier auf Serverauthentifizierung einzustellen. Der Parameter „r“ aktiviert die Selbstsignierung.

.\makecert -r -n "CN=Hostname.example.test" -a sha1 -eku "1.3.6.1.5.5.7.3.1" -ss My -sr LocalMachine

Sollte der Dienst Windows-Remoteverwaltung (WinRM) noch nicht gestartet sein, muss dieses mit Set-Service nachgeholt werden, ebenfalls ist zu empfehlen den Starttyp auf Automatisch zu stellen.

Set-Service WinRM -Status Running -StartupType Automatic

Es gibt verschiedene Möglichkeiten für die Erstellung des benötigten HTTPS Listeners. Diese gehen vom Cmdlet Enable-PSRemoting über „Winrm quickconfig“ bis zur Konfiguration mit Gruppenrichtlinien. Die genannten Varianten haben jedoch den Nachteil, dass sie meistens mehr aktivieren und einstellen als man benötigt. Deshalb zeige ich hier, wie man direkt über den WSMan Provider mit New-Item einen neuen Listener anlegt. Nur die angegebene IP-Adresse wird abgehört und es wird der Port 443 verwendet. Die Default Ports wurden von Microsoft vor einigen Jahren geändert, Näheres hierzu im Windows Management Infrastructure Blog. Die Verschlüsselung ist durch HTTPS und die Einbindung des vorher erstellten Zertifikats ebenfalls sichergestellt. Das Zertifikat wird mit Get-ChildItem über den Certificate Provider ausgelesen, eine Filterung mit Where-Object stellt sicher, dass das richtige Zertifikat ausgewählt wird.

ni WSMan:\localhost\Listener -Address IP:192.168.20.2 -Transport HTTPS -Port 443 -HostName Hostname.example.test -CertificateThumbPrint (ls Cert:\LocalMachine\My | ?{$_. Subject -like "CN=Hostname*"}).Thumbprint -f

Verwendet man wie in meinem Beispiel einen Port, welcher auch noch von anderen Diensten verwendet wird, sodass keine Regel über eine Firewall eingestellt werden kann, hat man mit dem folgenden Set-Item Befehl die Möglichkeit, einen IP-Adressen-Filter zu setzen, der einzelne Adressen oder wie in diesem Beispiel ganze Subnetze enthalten kann.

si WSMan:\localhost\Service\IPv4Filter 192.168.1.0-192.168.254.0

Die Windows-Firewall enthält keine vordefinierte Regel für WinRM HTTPS, erstellen kann man diese jedoch ganz einfach über das bekannte Tool Netsh.exe.

netsh advfirewall firewall add rule name="Windows-Remoteverwaltung - Kompatibilitätsmodus (HTTPS eingehend)" protocol=TCP dir=in localport=443 action=allow

Seit Windows Server 2012 gibt es auch das NetSecurity Module für die Windows-Firewall Verwaltung, dieses wird in einem späteren Artikel von mir noch gesondert behandelt.

PowerShell Remoting bedient sich einer neuen Authentifizierungsmethode, das sogenannte CredSSP ermöglicht eine Weitergabe der Anmeldeinformationen an einen Remoteclientcomputer. Dieses bedeutet, dass z.B. ein Zugriff auf eine Freigabe, welche auf einem zweiten Server liegt, direkt möglich ist. Aktiviert wird CredSSP mit Enable-WSManCredSSP, der Role-Parameter ist in diesem Fall Server und der Force-Parameter verhindert eine sonst benötigte Bestätigung.

Enable-WSManCredSSP -r Server -f

Die aktuelle Konfiguration bekommt man mit dem Cmdlet Get-WSManCredSSP angezeigt. Eine Deaktivierung von CredSSP kann mit Disable-WSManCredSSP wie folgt durchgeführt werden.

Disable-WSManCredSSP -r Server

Möchte man den Listener wieder löschen, kann dieses mit Remove-Item durchgeführt werden. Hierbei ist zu beachten, dass die ID hinter „Listener_“ immer unterschiedlich ist, hier sollte die Tab-Vervollständigung weiterhelfen oder man schaut vorher mit einem Get-ChildItem nach der richtigen Bezeichnung.

ri WSMan:\localhost\Listener\Listener_1085132740 -r

In meinem zweiten Teil der Serie „PowerShell Remoting“ werde ich auf die Verwendung der verschiedenen Remote-Verbindungen und ihre Besonderheiten eingehen.