WinRM

Als ich vor 14 Jahren die Verantwortung für Windows Embedded Standard 7 Installationen übernahm, stellte sich vor allem die Frage:

Wie kann man die Systeme aus der Ferne verwalten.

RDP und VNC mit voller UI ist zwar nett, aber nicht wirklich automatisierbar. Hier kam dann WinRM ins Spiel.

WinRM ist die “kurze” Microsoft-Antwort auf SSH aus der Unix Welt.

Es handelt sich dabei um ein SOAP-über-HTTP Protokoll, welches eine “Aufgabe” auf ein Zielsystem senden kann, und das Ergebnis zurückliefert.

Der kleinste gemeinsame Nenner zwischen SSH und WinRM ist das starten von Prozessen, man kann z.B. cmd.exe auf dem Zielsystem starten und vom lokalen System per Tastatur steuern.

Im restlichen Featureset unterscheiden sich die beiden Techniken aber. SSH kann Dateien verwalten (SFTP) und TCP-Ports weiterleiten (tunneln), was WinRM nicht kann.
Dafür gibt WinRM einem Zugriff auf alles, was durch WMI erreichbar ist, was wiederum den Unix-Derivaten fremd ist.

WinRM einrichten

WinRM ist ein Windows Systemdienst, der seit Windows Vista/7 deaktiviert ausgeliefert wird. Für Windows XP und Server 2003 gab es Upgrades um es auch dort nachzusinstallieren.

Aktivieren kann man den Dienst durch folgende Befehl als Administrator auf der Konsole:

winrm quickconfig -force -q

Diese Befehlszeile ist auf beiden Systemen (also dem lokalen System und dem zu verwaltenden System) auszuführen.

Das -q (quiet) Flag verhindert die Nachfrage, ob man wirklich Änderungen durchführen will.

Lokalen WinRM Client einrichten

Per Standard erfordert WinRM die Kommunikation über HTTPS auf Port 5986, doch da wir hierfür gültige Zertifikate und eine Public-Key Infrastruktur benötigen, richte ich für Tests (oder in anders gesicherten Netzen) WinRM via HTTP ohne Zertifikatzwang auf Standard-Port 5985 ein.

Außerdem muss der Client explizit wissen, welche Server er ansprechen darf. Das lässt sich aber mit dem Wildcard-Eintrag * auf “alle” Systeme ausweiten.

Folgende Kommandos sind also nötig:

winrm set winrm/config/client @{AllowUnencrypted="true"}
winrm set winrm/config/client @{TrustedHosts="*"}

WinRM Service auf dem Zielsystem einrichten

Am Zielcomputer ist ebenfalls die Kommunikation auf “UnEncrypted” zu stellen:

winrm set winrm/config/service @{AllowUnencrypted="true"}

Auf einem Windows Server ohne User-Account-Control wäre man jetzt fertig und könnte sich mit einem Administrator Account+Passwort einloggen.
Doch unsere heutigen Windows Clients entfernen ja die Administrationsrechte beim Login, und somit wird der Zugang zu WinRM verweigert.

Man erhält eine Fehlermeldung wie:

Winrs error:Access is denied.

Hierfür müssen wir einer anderen Gruppe die nötigen Rechte erteilen und unseren Login-Account in diese Gruppe aufnehmen. Die Gruppe “Remote Management Users” bietet sich herfür perfekt an.

Mit dem Aufruf von

winrm configSDDL default

öffnet sich der Dialog zum Editieren der Zugriffsrechte und hier kann man die Gruppe Remote Management Users mit Lese- und Ausführungsrechten hinzufügen.

Remote Shell starten

winrs ist das Werkzeug, mit dem die Verbindung zur Konsole des Zielsystems hergestellt wird. Die Befehlszeile lautet:

winrs -r:http://remote_ip:5985 -u:remote_login -p:remote_password cmd.exe

Lässt man den -p: Eintrag weg, wird man zur Eingabe des Passworts aufgefordert.

Und mit etwas Glück sieht man dann auch schon den Inhalt des entfernten Systems und kann es mit üblichen Windows-Konsolenkommandos bearbeiten.

Sonderfall Domain-Mitgliedschaften

Ist das Zielsystem in einer Domäne, braucht man den Domänennamen vor dem Account, also:

winrs -r:http://remote_ip:5985 -u:mydomain\my_dom_account cmd.exe

Und wenn man auf einem Domänen-PC einen lokalen Account erreichen will, kann man das mit einem vorangestellten Backslash erreichen (oder man stellt den PC-Namen statt der Domäne vorne an):

winrs -r:http://remote_ip:5985 -u:\my_local_account cmd.exe

Fazit

Die Aktivierung von WinRM auf Indistrie-Terminals hat mir schon ein paar Mal “den Arsch gerettet”, denn so konnten Fehlkonfigurationen im Hintergrund behoben werden, ohne dass man die Arbeit am Terminal per RDP oder VNC unterbrechen musste, was den Anwender oft irritierte.

Die Remote-Shell ist zwar kein gleichwertiger Alternative zu einem SSH Dienst, aber ein wirklich hilfreiches Werkzeug, das bei jeder Standard-Windows Installation vorhanden ist und nur aktiviert werden muss.