Tags: PowerShell, Zertifikate, Remote-Verwaltung
Verbindungen, die man über Enter-PSSession und Invoke-Command aufbaut, kommunizieren standardmäßig über HTTP. Allerdings verschlüsselt dabei WinRM die übertragenen Daten. Zusätzliche Sicherheit erlangt man speziell in Workgroups durch HTTPS, wobei ein selbstsignierten SSL-Zertifikat in der Regel reicht.
Tatsächlich bestätigt die Dokumentation von Microsoft für Invoke-Command, dass WS-Management alle übertragenen PowerShell-Daten verschlüsselt. Leider ist PowerShell Remoting, wenn es nicht ordnungsgemäß konfiguriert ist, unsicher und in einigen Fällen müssen Sie die Standardkonfiguration ändern.
Aktuelle Konfiguration prüfen
Um zu überprüfen, wie Ihre Maschinen konfiguriert sind, können Sie diesen Befehl ausführen:
winrm get winrm/config
Alternativ liefert PowerShell das gleiche Ergebnis:
dir WSMan:\localhost\Service | ? Name -eq AllowUnencrypted
bzw. für den Client mit
dir WSMan:\localhost\Client | ? Name -eq AllowUnencrypted
Zusätzlicher Schutz für Workgroup-Umgebungen
Das zweite und meiner Meinung nach größere Problem ist, dass Sie keine Vertrauensbeziehung zu den entfernten Computern haben, wenn Sie mit Maschinen arbeiten, die sich nicht in einer Active Directory-Domäne befinden.
Es greift dann nur noch die symmetrische Verschlüsselung von WSMan, so dass Man-in-the-Middle-Angriffe theoretisch möglich sind, da zuerst der Schlüssel übertragen werden muss.
An dieser Stelle kommt PowerShell Remoting via SSL ins Spiel. Zum einen ist der HTTPS-Verkehr immer verschlüsselt, und da SSL eine asymmetrische Verschlüsselung und Zertifikate verwendet, können Sie sicher sein, dass Sie mit Ihrem Remote-Computer verbunden sind und nicht mit dem eines Angreifers.
Auf der anderen Seite ist die Konfiguration von PowerShell Remoting für die Verwendung mit SSL etwas schwieriger, weil man dafür mehr tun muss als bloß Enable-PSRemoting auszuführen. Das Hauptproblem ist, dass Sie ein SSL-Zertifikat benötigen.
Wenn Sie nur einige eigenständige Server oder Workstations verwalten möchten, werden Sie wahrscheinlich kein öffentlich signiertes Zertifikat erwerben und stattdessen mit einem selbstsignierten Zertifikat arbeiten.
HTTPS auf dem Remote-Computer aktivieren
Das erste, was wir tun müssen, ist, ein SSL-Zertifikat zu erstellen. Diese Anleitung konzentriert sich auf die Verwendung eines selbstsignierten Zertifikats. Wenn Sie ein öffentlich signiertes Zertifikat haben, ist die Sache einfacher und Sie können dafür
Set-WSManQuickConfig -UseSSL
verwenden.
Seit PowerShell 4 brauchen wir für das Ausstellen eines selbstsignierten Zertifikats keine Tools von Drittanbietern mehr, das Cmdlet New-SelfSignedCertificate übernimmt seitdem diese Aufgabe.
$Cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName "myHost"
Es ist wichtig, den Namen des Computers, den Sie remote verwalten möchten, an den Parameter DnsName zu übergeben. Wenn der Computer einen DNS-Namen hat, sollten Sie den voll qualifizierten Domänennamen (FQDN) verwenden.
Falls Sie möchten, können Sie mit der überprüfen, ob das Zertifikat korrekt gespeichert wurde. Fügen Sie dort das Snap-In Zertifikate für ein Computerkonto und dann den lokalen Computer hinzu. Das Zertifikat sollte sich im Ordner Eigene Zertifikate\Zertifikate befinden.
Wir müssen das Zertifikat nun in eine Datei exportieren, damit wir es später auf unserem lokalen Rechner importieren können. Das lässt sich auch mit dem MMC-Snap-In erledigen, aber wir werden dazu PowerShell verwenden:
Export-Certificate -Cert $Cert -FilePath C:\temp\cert
Wir benötigen das Zertifikat, um den HTTPS Listener von WS-Management zu starten. Aber zuerst sollten wir PowerShell Remoting auf dem Host aktivieren:
Enable-PSRemoting -SkipNetworkProfileCheck -Force
SkipNetworkProfileCheck stellt sicher, dass PowerShell sich nicht beschwert, wenn Ihr Netzwerkverbindungstyp auf Öffentlich gesetzt ist.
Enable-PSRemoting startet auch einen WS-Management-Listener, allerdings nur für HTTP. Wenn Sie möchten, können Sie dies überprüfen, indem Sie den Inhalt des WSMan-Laufwerks lesen:
dir wsman:\localhost\listener
Um sicherzustellen, dass niemand HTTP zur Verbindung mit dem Computer verwendet, können Sie den HTTP-Listener auf diese Weise entfernen:
dir WSMan:\Localhost\listener | where Keys -eq "Transport=HTTP" |`
Remove-Item -Recurse
Als nächstes fügen wir unseren HTTPS-Listener hinzu:
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * `
-CertificateThumbPrint $Cert.Thumbprint -Force
Wir verwenden die Variable $Cert, die wir zuvor definiert haben, um den Thumbprint zu lesen. Er ermöglicht dem Cmdlet New-Item, das Zertifikat in unserem Speicher zu finden.
Das Letzte, was wir tun müssen, ist, die Firewall auf dem Host zu konfigurieren, da das Cmdlet Enable-PSRemoting nur Regeln für HTTP hinzugefügt hat:
New-NetFirewallRule -DisplayName "Windows Remote Management (HTTPS-In)" -Name "Windows Remote Management (HTTPS-In)" -Profile Any -LocalPort 5986 -Protocol TCP
Beachten Sie hier, dass wir eingehenden Datenverkehr auf Port 5986 erlauben. WinRM 1.1 (aktuell ist 3.0) verwendet noch den allgemeinen HTTPS-Port 443. Sie können diesen weiterhin nutzen, wenn sich der Host hinter einer Gateway-Firewall befindet, die den Port 5986 blockiert:
Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener -Value true
Natürlich müssen Sie dann den Port 443 in der Windows Firewall öffnen. Beachten Sie, dass dieser Befehl nicht funktioniert, wenn der Netzwerkverbindungstyp auf Öffentlich eingestellt ist. In diesem Fall müssen Sie den Verbindungstyp auf privat ändern:
Set-NetConnectionProfile -NetworkCategory Private
Aus Sicherheitsgründen sollten Sie die Firewall-Regel für HTTP deaktivieren, die von Enable-PSRemoting hinzugefügt wurde:
Disable-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)"
Unser entfernter Rechner ist nun bereit für PowerShell Remoting über HTTPS, und wir können den lokalen Computer konfigurieren.
HTTPS auf dem lokalen Computer aktivieren
Die Dinge sind hier etwas einfacher. Zuerst müssen Sie die zuvor erstellte Zertifikatsdatei auf den lokalen PC kopieren. Mit diesem Befehl können Sie dann das Zertifikat importieren:
Import-Certificate -Filepath "C:\temp\cert" -CertStoreLocation "Cert:\LocalMachine\Root"
Beachten Sie, dass wir das Zertifikat hier im Ordner Vertrauenswürdige Stammzertifizierungsstellen speichern müssen und nicht im Ordner Eigene Zertifikate, wie wir es auf dem Remote-Computer getan haben.
Ihr Computer vertraut allen Maschinen, die ihre Authentizität mit Hilfe ihrer privaten Schlüssel (die auf dem Host gespeichert sind) und der hier gespeicherten Zertifikate nachweisen können.
Wir müssen den entfernten Rechner nun nicht zur Liste der TrustedHosts hinzufügen. Im Gegensatz zu PowerShell Remoting über HTTP können wir sicher sein, dass der Remote-Computer derjenige ist, der er vorgibt zu sein. Das ist der Hauptgrund dafür, HTTPS anstelle von HTTP zu verwenden.
Sitzung über HTTPS starten
Wir sind nun bereit, eine PowerShell-Sitzung auf dem Remote-Computer über HTTPS zu öffnen:
Enter-PSSession -ComputerName myHost -UseSSL -Credential (Get-Credential)
Der entscheidende Parameter hier ist UseSSL. Natürlich müssen wir uns noch auf dem entfernten Rechner mit einem Administratorkonto authentifizieren.
Auch das Cmdlet Invoke-Command unterstützt den Parameter UseSSL:
Invoke-Command -ComputerName myHost -UseSSL -ScriptBlock {Get-Process} -Credential (Get-Credential)
Fazit
Zugegeben, der Beitrag wurde etwas länger als geplant. Sobald Sie jedoch wissen, wie es funktioniert, können Sie den gesamten Vorgang zur Konfiguration von PowerShell Remoting über HTTPS in wenigen Minuten abschließen.
Sie erstellen einfach ein selbstsigniertes SSL-Zertifikat auf dem Host und starten mit diesem Zertifikat einen HTTPS-Listener. Anschließend erstellen Sie die entsprechende Firewall-Regel und exportieren das Zertifikat. Auf dem lokalen Computer müssen Sie nur das Zertifikat importieren.
HTTPS fügt nicht nur eine weitere Verschlüsselungsebene hinzu, sondern dient vor allem dazu, die Authentizität des entfernten Rechners zu überprüfen und so Man-in-the-Middle-Angriffe zu verhindern.
Daher benötigen Sie HTTPS nur, wenn Sie PowerShell Remoting über ein unsicheres Netzwerk durchführen. Innerhalb Ihres lokalen Netzwerks, mit Vertrauensbeziehungen zwischen Mitgliedern einer Active Directory-Domäne, ist WSMan über HTTP sicher genug.
Täglich Know-how für IT-Pros mit unserem Newsletter
Michael Pietroforte verfügt über 30 Jahre Erfahrung in IT-Projekten, ist seit fünf Jahren Microsoft MVP Windows IT Pro und Betreiber der Website 4sysops für IT Professionals.
Verwandte Beiträge
- ThinPrint 13 unterstützt Microsofts V4-Druckertreiber und MMC
- PowerShell 7.3: JEA über SSH, Cmdlet für Setup, erweiterte ARM-Unterstützung
- Second-Hop-Problem: CredSSP für PowerShell-Remoting konfigurieren
- Lets Encrypt-Zertifikat mit ACME2-Client ausstellen, installieren, automatisch erneuern
- Alle Windows-Server auf ablaufende Zertifikate prüfen mit PowerShell
Weitere Links