Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03330.jsonl.gz/261

Im heutigen Blogbeitrag möchte ich über tückische Zusammenhänge der im Titel genannten Features berichten:
Man beauftragte mich in einer Umgebung bestehend aus Windows Servern der Generationen W2K8 bis W2K12 Powershell-Remoting einzuführen. Eine Vorgabe besagte, das PS-Remoting auf Grund von Sicherheitsrichtlinien ausschliesslich verschlüsselt, d. h. über HTTPS kommunizieren darf.
Auf den meisten der älteren Server war WinRM, dass ja bekanntlich Voraussetzung für PS-Remoting ist, deaktiviert und auf den neuen Servergenerationen war WinRM per default aktiviert.
Powershell war das Tool der Wahl um den Auftrag umzusetzen. Was musste das Script tun?
- Herausfinden, ob WinRM auf einem Server aktiviert ist, und falls ja, ob es über http oder https kommuniziert. Dazu eignet sich folgendes WinRM Command: „winrm enumerate winrm/config/listener“
- Falls WinRM auf http konfiguriert ist, den Listener auf Port 5985 und die Windows Firewall Rule, die eingehende Verbindung auf Port 5985 zulässt, löschen. Ist WinRM über https konfiguriert, kann das Script an der Stelle abbrechen.
- WinRM for https konfigurieren, wiederrum mit einem WinRM command: „winrm create winrm/config/listener?Address=*+Transport=HTTPS“. Damit wird der Listener und die Firewall für Port 5986 konfiguriert.
Bevor man WinRM for https konfigurieren kann, braucht jeder Server noch ein Maschinenzertifikat, das im Subject den FQDN des Servers trägt und der Zweck Server Authentikation ist. Welch Glück, ein solches Zertifikat war auf jedem der Server vorhanden, da überall ein SCCM Client lief und dieser ein Zertifikat mit gleichen Voraussetzungen benötigt.
Es empfiehlt sich zu überprüfen, ob eine GPO existiert und auf die Server angewendet wird, über die WinRM konfiguriert wird. In dem Fall wäre WinRM für http konfiguriert, da Gruppenrichtlinien nur eine Konfiguration von WinRM für http vorsehen, nicht aber für https. Gäbe es eine solche GPO, so könnte das Script den Listener und die Firewall Regel nicht löschen.
Alle Voraussetzungen waren gegeben, das Script lief auf jedem Server, mit dem Ergebnis, das nirgends WinRM für http und überall WinRM für https akiv war. Auf einige Server konnte man sich aber nicht per PS-Remoting via https verbinden. Ich schaute mir die Server an, der Listener war korrekt konfiguriert, die Firewall Rule für eingehende Verbindungen auf Port 5986 war vorhanden, der WinRM Service lief, aber trotzdem bekam ich eine Fehlermeldung wenn ich ein Enter-Pssession auf diese Server initiierte. Dann fiel mir auf, dass die Server, auf denen PS-Remoting nicht funktionierte, eines gemeinsam hatten: Sie alle hatten mehr als einen Netzwerkadapter. Der 2. Netzwerkadapter war jeweils als „Private Network“ konfiguriert, die Firewall Rule für Port 5986 war jedoch nur für „Domain Networks“ konfiguriert. Also musste ich diese Rule noch für „Private Network“ erweitern, anschliessend waren auch diese Server per PS-Remoting https erreichbar. Auftrag erfüllt, dachte ich.
Keine 20 Minuten später standen die ersten Kollegen auf der Matte. Der Erste konnte die Server seiner RDS Farm nicht mehr über den Servermanager verwalten. Auch die anderen Kollegen hatten das Problem, dass sie Server, die sie in den Server Manager eines Verwaltungsservers importiert hatten um sie remote zu verwalten, nicht mehr managen konnten. Im Servermanager sahen alle folgende Fehlermeldung:
Es lag auf der Hand, dass es etwas mit meiner WinRM Umsetzung zu tun hatte. Ich wusste, dass der Servermanager WinRM benötigt um Remote Server verwalten zu können. Ich konnte mir jedoch nicht vorstellen, dass er zwingend den Listener auf Port 5985 braucht.
Die Internetsuche liess mich dann auf folgenden Artikel stossen:
Sicherheitshalber habe ich bei Microsoft direkt nachgefragt, und auch dort bestätigte man mir, dass alle Server, die remote verwalten oder remote verwaltet werden sollen, den Listener zwingend auf Port 5985 konfiguriert haben müssen.
Conclusion: Wer per Servermanager andere Server remote verwalten will, muss WinRM für http auf jeden Fall in der Standardkonfiguratin belassen. Man kann natürlich zusätzlich noch WinRM for https einrichten und die IT Mannschaft darauf hinweisen, dass Powershell Remoting nur über HTTPS gestattet ist. Es wäre jedoch zu wünschen, das Microsoft in Zukunft die Verwendung von WinRM für https im Zusammenhang mit dem Server Manager ermöglicht.