Es ist noch gar nicht so lange her, da waren die Fronten in Sachen Betriebssystem klar: Linux ist ein UNIX-artiges Betriebssystem, das durch seine eingebaute Rechteverwaltung fein justierbar und mit POSIX weitgehend kompatibel ist, dazu arbeitet es stabil und zuverlässig. Windows hingegen stürzt oft ab, ist aus der Ferne nicht sinnvoll zu administrieren und jeder Computer mit Windows ist ein dauerhaftes Problem in Sachen Sicherheit.

Doch heute ist die Welt freilich nicht annähernd so schwarz und weiß. Seit Microsoft den MS-DOS-Unterbau von Windows XP weggeworfen und den alten NT-Kernel aufgemöbelt hat, liefert auch Microsoft ein vollständig POSIX-kompatibles Betriebssystem aus. Und das kann mehr als manchem Linux-Admin bewusst ist: In Sachen Fernverwaltung lässt Windows sich heute ebenso per SSH steuern wie ein Linux-System.

Daraus ergeben sich im Alltag praktische Konsequenzen von großem Nutzen. So war es für die Entwickler der Automationsumgebung Ansible [1] vergleichsweise einfach, ihr Werkzeug so zu erweitern, dass es auch Aufgaben in Windows automatisch durchführt. Dies macht vor allem der Umstand möglich, dass ein Login aus der Ferne auf Windows-Systemen per SSH heute problemlos möglich ist und dabei sogar die Authentifizierung per SSH-Schlüssel funktioniert. Ansible bietet etliche Module, mit denen sich Standardaufgaben in Windows erledigen lassen, etwa die Installation von Software per MSI-Paket, das Ausrollen von Windows-Updates oder die Ablage von Dateien.

Der Ansatz richtet sich vor allem an Unternehmen, die bereits eine umfassende Zentralisierung in ihrer Windows-Infrastruktur umgesetzt haben und auf das Active Directory setzen, in ihrem aktuellen Setup aber nicht alle nötigen Funktionen finden. Auch Firmen, die auf der Linux-Seite bereits umfangreich Ansible nutzen und Windows nun mit denselben Werkzeugen bearbeiten wollen, erhalten auf diese Weise dazu die Möglichkeit.

In diesem Workshop zeigen wir, wie sich Windows-Systeme unter die Ägide von Ansible stellen lassen und welche Konfigurationsanpassungen dafür notwendig sind. Unser Testaufbau setzt dabei auf Windows 11 Professional als Client und nutzt Ubuntu Linux 24.04 für Ansible. Doch eine wichtige Vorbedingung muss erfüllt sein, damit Ansible auf Windows-Systemen überhaupt Änderungen durchführen darf, benötigt es administrativen Zugriff auf die jeweilige Maschine. Der Zugang per SSH muss also als Benutzer erfolgen, der mit den Rechten eines lokalen Administrators ausgestattet ist. Auch ein Domänenadministrator kommt infrage, wenn das jeweilige Windows-System an eine Windows-Domäne angeschlossen ist und die jeweiligen Rechte des Nutzers auf das System durchpropagieren.

Wer es sich hier allerdings besonders einfach machen und mit den Rechten des Benutzers "Administrator" arbeiten möchte, greift ins Leere: Sowohl der lokale Nutzer dieses Namens (falls vorhanden) als auch der Domänenadministrator gelten unter Windows als Superbenutzer mit besonderen Voraussetzungen. Für diesen lässt sich in Windows nicht ohne Weiteres der Login per SSH-Schlüssel konfigurieren. Bevor die Automation starten kann, ist es deshalb nötig, auf dem Zielsystem einen separaten Benutzer mit Administratorrechten anzulegen, der eben nicht "Administrator" heißt. Dem IT-Verantwortlichen, der Ansible und Windows zusammenbringen will, müssen die Zugangsdaten eben dieses Users zum System oder zur Domäne zudem vorliegen.

Unser erster Schritt besteht in der Aktivierung des in Windows 11 verfügbaren SSH-Servers. Dabei handelt es sich im Wesentlichen um dieselbe Software, die auch unter Linux verfügbar ist. Allerdings liefert Microsoft OpenSSH nicht als Standardkomponente in Windows 11 aus. Stattdessen müssen Sie den Dienst nachträglich installieren. Dazu loggen Sie sich zunächst auf dem jeweiligen System ein und klicken auf das Startsymbol in der Taskleiste. In das Suchfeld tippen Sie danach "Optionale Features" ein, um den Installationsdialog für Zusatzkomponenten zu öffnen. Es folgt ein Klick auf "Optionale Features hinzufügen" und ein weiterer auf "OpenSSH Server", bevor Sie über "Installieren" den Vorgang starten. Dies ist nur als Administrator in Windows möglich, zu diesem Zeitpunkt müssen Sie also bereits als Nutzer mit administrativen Rechten unter Windows agieren.

Die Installation mittels Remoteverbindung über RDP ist übrigens ebenfalls problemlos möglich. Hierzu müssen Sie allerdings sicherstellen, dass Sie sich per RDP auf dem System anmelden dürfen und dass das Protokoll an sich aktiviert ist. Beides ist ab Werk nicht der Fall: RDP ist nicht aktiv und selbst Nutzer mit lokalen Admin-Rechten dürfen sich nicht per se via RDP an Windows anmelden.

Ist der OpenSSH-Server installiert, folgt ein Klick auf das Startsymbol in der Taskleiste gefolgt von der Eingabe "services. msc", um den Dienstedialog von Windows zu öffnen. Für "OpenSSH Server" und "OpenSSH Authentication Agent" setzen Sie dann den Starttyp jeweils auf "Automatisch". Bei der Installation des OpenSSH-Servers hinterlegt Windows automatisch eine Firewallregel, die den Zugriff über Port 22 per TCP/IP-Protokoll ermöglicht. Um zu überprüfen, ob diese Policy ordnungsgemäß arbeitet, nutzen Sie den Befehl Get-NetFirewallRule -Name *SSH*  in einer als Administrator ausgeführten PowerShell.

OpenSSH ermöglicht auch unter Windows den Login per SSH-Schlüssel. Generell sollten Sie diesem Ansatz stets Vorrang vor dem Login per Passwort geben. Denn einerseits ist ein SSH-Schlüssel sicherer als die allermeisten Passwörter und andererseits erleichtert der Login per SSH-Schlüssel die Nutzung von Ansible. Das lässt sich zwar auch so einrichten, dass es sich per Passwort an einem Host anmeldet. Wer aber seine Ansible-Infrastruktur in Git verwaltet, müsste dann das Passwort für den Login im Klartext in Git hinterlegen oder zu einer mühsamen Verschlüsselung per Ansible Vault greifen, um den Zugang zu sichern. All das ist mit SSH-Schlüsseln nicht erforderlich.

Ein weiterer Grund für SSH-Schlüssel ist, dass diese auch unter Windows relativ leicht anzulegen und einzurichten sind. Hier gibt es zwei Möglichkeiten: Entweder besitzen Sie bereits den öffentlichen Teil eines SSH-Schlüssels, den Sie wiederverwenden möchten. Dann ist lediglich dieser Schlüssel nötig, der unter Linux meist in "$HOME/ .ssh/id_rsa.pub" oder "$HOME/.ssh/ id_ed25519.pub" zu finden ist. Falls noch kein SSH-Schlüssel existiert, lässt dieser sich aber auch unter Windows anlegen. Dazu starten Sie die PowerShell und rufen das Kommando ssh-keygen -t ed25519  auf.

Ist dieser Schritt erledigt, richten Sie das System noch so ein, dass sich der jeweilige Nutzer mit eben diesem Schlüssel ohne Passworteingabe remote an Windows anmelden darf. Hier unterscheidet sich das Vorgehen abhängig von der Frage, ob der Login als normaler Benutzer ohne administrative Rechte oder als Admin erfolgen soll. Für den Zugang als normaler Benutzer fügen Sie den öffentlichen SSH-Schlüssel in die Datei "C:\Users\username\.ssh\authorized_keys" auf dem Win- dows-System ein. Aus der Ferne lässt sich das mittels PowerShell auch erledigen, wenn auf dem jeweiligen System SSH ebenfalls zur Verfügung steht:

Soll der Login mit administrativen Rechten geschehen, wie für Ansible nötig, ist dazu der öffentliche SSH-Schlüssel des Nutzers in der Datei "C:\ProgramData\ ssh\administrators_authorized_keys" zu platzieren. Auch das lässt sich mittels PowerShell aus der Ferne erledigen:

Aber Achtung: Falls das Zielsystem keine deutschsprachige Lokalisierung von Windows nutzt, ist die Zeichenkette "Administratoren" entsprechend zu ersetzen, etwa durch "Administrators" für Win-dows-11-Systeme in Englisch. Alternativ lässt sich auch die SID der Gruppe angeben, diese ermitteln Sie über:

Im Anschluss sollte der Login vom Ansible-Host aus wie üblich durch Aufruf von ssh <Benutzer>@<Server>  klappen. Falls eine Passwortabfrage erscheint, prüfen Sie, ob diese sich auf das Passwort des SSH-Schlüssels bezieht. In diesem Fall empfiehlt es sich, auf dem Linux-System einen SSH-Agenten so einzurichten, dass die Eingabe des Schlüssels nur beim ersten Login am System nach einem Neustart nötig ist und der Zugang ansonsten passwortlos erfolgt.

Wollen Sie sich über einen Jump Host vom eigenen System aus mit Windows verbinden, benötigen Sie den SSH-Agenten zwingend. Hier ist beim SSH-Aufruf zudem darauf zu achten, den Parameter "-A" anzugeben, der das Forwarding für den SSH-Agenten aktiviert. Sonst wäre es nötig, auf dem Jump Host den geheimen Teil des SSH-Schlüssels zu hinterlegen, was in Sachen Sicherheit natürlich bedenklich ist.

Ist das Windows-Zielsystem passend konfiguriert, steht das Ansible-Setup unter Linux auf dem Programm. Hierzu richten Sie idealerweise eine virtuelle Instanz mit Ubuntu 24.04 ein. In dieser installieren Sie per

aus dem offiziellen Ansible-PPA die jeweils neueste verfügbare Version. Danach loggen Sie sich als regulärer Benutzer auf dem System ein und erstellen im Homeverzeichnis einen Ordner namens "ansible". Dies wird für die Windows-Automatisierung das Hauptarbeitsverzeichnis. Entsprechend erzeugen Sie im Ordner zunächst eine Inventardatei "hosts" mit dem folgenden Inhalt:

"Hostname" ist dabei durch den vollständigen Namen des entfernten Windows-Systems zu ersetzen und "ansible" am Ende der Zeile durch den Benutzernamen des Users, der auf dem Windows-System zum Einsatz kommen soll. Die Windows-Systeme sind dabei in der Gruppe "win-dows" zusammengefasst, sodass diese sich auch gebündelt per Ansible ansprechen lassen. Hat das Setup bis hierhin funktioniert, sorgt das Kommando

im Anschluss dafür, dass Ansible sich in Windows per SSH einloggt. Die Ausgabe sollte folgender ähneln:

Insbesondere der "SUCCESS"-Teil ist relevant, denn dieser verrät, dass das Setup funktioniert hat.

Ab diesem Punkt ist die Ansible-Infrastruktur für Windows einsatzbereit und lässt sich für diverse Aufgaben nutzen. Wir wollen dies mit einigen einfachen Beispielen verdeutlichen. Ihnen ist gemein, dass in der einfachsten Erscheinungsform für Ansible stets ein Playbook nötig ist. Dies ist eine Datei im YAML-Format mit spezifischer Syntax, die beschreibt, welche Arbeiten auf welchen Hosts Ansible durchführen soll. Ein einfaches Beispiel für das Ausführen eines Kommandos in Windows:

Den gesamten Inhalt hinterlegen Sie in einer Datei namens "devel-directory.yml" direkt im Ansible-Ordner. Anhand des Beispiels lässt sich die Anatomie eines Ansible-Playbooks gut aufzeigen: "name" definiert den Titel des Playbooks, "hosts" gibt an, auf welchen Systemen Ansible die Arbeiten durchführt (im Beispiel also auf den Systemen der Gruppe "windows"). Hier ließe sich alternativ auch direkt der Hostname angeben, wenn die Arbeiten nur auf einem einzelnen System durchzuführen sind. Dann folgt der Absatz "tasks", der alle anstehenden Aufgaben enthält.

Eine Task-Anweisung in Ansible folgt einer sehr ähnlichen Syntax wie das Playbook selbst und kommt stets in derselben Form daher: "name" definiert den Titel der Aufgabe und die nächste Zeile enthält das Ansible-Modul, das aufzurufen ist. Unter dem eigentlichen Modulaufruf finden sich dessen Parameter. Der Beispielcode bringt Ansible dazu, auf dem Zielrechner den Ordner "C:\Development" anzulegen. Haben Sie die Datei "devel-directory.yml" angelegt, starten Sie den Vorgang mit:

Erscheint im Nachgang wieder die Meldung "SUCCESS", findet sich auf dem Windows-System im Anschluss der gewünschte Ordner.

Mit dem bisher angelegten Ansible-Code lassen sich bereits die allermeisten Ansible-Funktionen für Windows nutzen. Entscheidend ist dabei jeweils, die passenden Ansible-Module aufzurufen. Die für Windows verfügbaren Module listen die Ansible-Entwickler in ihrer Dokumentation [2] auf. Zur Verfügung stehen etliche Methoden und beispielsweise lässt sich ein Windows-System dazu bringen, alle Updates, die Microsoft selbst als "kritisch" einstuft oder die Sicherheitsbezug haben, auf einem System einzuspielen und dieses falls nötig im Anschluss auch gleich neu zu starten:

Dabei kommt eine weitere praktische Eigenschaft von Ansible zum Tragen: Das Arbeiten mit Rückgabewerten der aufgerufenen Module. Das "win_updates"-Modul setzt die Umgebungsvariable "reboot_ required", falls ein Update die Anweisung enthält, nach seiner Installation das System neu zu starten. Per "register"-Anweisung im ersten Task speichert Ansible den Rückgabewert und wertet ihn dann per "when"-Anweisung im zweiten Task aus.

Mittels des öffentlichen Chocolatey-Verzeichnisses [3] steht eine Möglichkeit zur Verfügung, auf Windows-Systemen zusätzliche Software zu installieren. Dabei ist es nicht notwendig, zuvor eine MSI- oder EXE-Datei auf das System zu laden. Mit dem folgenden Task spielen Sie beispielsweise das Programm 7zip unter Windows ein:

Die Installation eines Werkzeugs per MSI-Datei ist ebenfalls möglich. Der Ablauf besteht hier jedoch aus mehreren Schritten: Erst gelangt die Datei auf das Zielsystem, dann erfolgt die Installation per Ansible-Modul. Die folgenden beiden Tasks laden die Datei "anwendung.msi" nach "C:\temp" und führen im Anschluss die Installation durch:

Damit der Aufruf des entsprechenden Playbooks klappt, legen Sie Ihre MSI-Datei im Ordner "files" im Ansible-Arbeitsordner ab.

Unter Ansible sind Rollen im Wesentlichen separate Sammlungen von Anweisungen mit diversen Zusatzfunktionen. In Rollen lassen sich beispielsweise Templates ausspielen, Dateien ausliefern oder Anweisungen hinzufügen, um nach der Installation von Software diese zu starten oder zu stoppen, ohne alles in ein einzelnes Playbook wie in unseren bisherigen Beispielen zu schreiben.

Die Rollennutzung ist dabei denkbar einfach. Im ersten Schritt legen Sie innerhalb des Ansible-Arbeitsordners ein Verzeichnis "roles" an und darin einen separaten Unterordner pro Rolle, etwa "update" für eine Windows-Update-Rolle.

Innerhalb von "update" entsteht dann ein Ordner "tasks" mit der Datei "main.yml". Deren Inhalt entspricht dem "tasks"-Abschnitt eines Playbooks, allerdings ohne vorangestelltes "tasks:" und entsprechend ohne Einrückung am Beginn der "-name:"-Zeilen. Im Gegenzug entfernen Sie den "tasks"-Abschnitt aus dem eigentlichen Playbook und fügen stattdessen einen Verweis auf die Rolle ein:

Der anschließende Aufruf von "ansible-playbook" wendet die Tasks aus den Rollen so an, als stünden sie direkt im Playbook, führt aber auch die anderen Funk- tionen der Rollen aus.

Ansible bietet eine funktionale, einfache und schnell aufzusetzende Möglichkeit, Arbeiten unter Windows automatisiert durchzuführen. Sowohl als eigenständige Automatisierung für Windows als auch als Ergänzung zu anderen Werkzeugen lässt es sich hervorragend einsetzen. Wer größere Flotten von Windows-Systemen betreut, sollte ergänzende Werkzeuge wie Red Hats Ansible Automation Platform, Spacelift oder Semaphore in Betracht ziehen, um ein RBAC für Compliance und Sicherheit zu erhalten.

Fernab davon eröffnet die Ansible-Integration für Windows zahllose Möglichkeiten: Wer etwa den Prometheus-Node-Exporter in Windows installieren möchte, um Faktoren wie CPU-Nutzung, RAM oder die gegebenen Datenträger direkt in Prometheus und Grafana zu überwachen, kann das mittels Ansible leicht und schnell erledigen.