Ansible Teil 8 – Windows Maschinen als Clients hinzufügen (über WinRM)

In einem vorangegangenen Beitrag bin ich auf die Möglichkeit eingegangen, Windows Maschinen mit Ansible über SSH zu kontaktieren.
Neben der Verbindung über SSH hält Ansible jedoch noch die Möglichkeit bereit, (das bei Windows bereits vorinstallierte) WinRM zu verwenden. Dabei stehen uns mit WinRM nochmals weitere unterschiedliche Authentifizierungsmöglichkeiten zur Auswahl.
Wie die Einrichtung und Konfiguration mit der Basis-/ und der Kerberos-Authentifizierungsmethode aussieht und durchgeführt wird, ist im folgenden beschrieben.

Vorbereitungen

Auf dem Windows-Client

Wie bereits erwähnt, sollte auf jeder Windows-Installation der WinRM-Dienst bereits installiert und gestartet sein. Ist dies nicht der Fall ist, lässt er sich über die Powershell-Kommandozeile (als Administrator ausgeführt) folgendermaßen starten:

winrm quickconfig

Auf dem Ansible-Server

Auf dem Ansible-Server müssen als erstes folgende Pakete installiert werden:

### Über den APT-Paketmanager
apt install gcc python-devel krb5-devel krb5-workstation python-devel
### bzw. den YUM-Paketmanager
yum install gcc python-devel krb5-devel krb5-workstation python-devel

Zudem benötigen wir das Python-Modul pywinrm.

pip3 install pywinrm
pip3 install pywinrm[kerberos]

Um die Verbindung hinterher zu überprüfen, soll das folgende Playbook dienen, welches uns lediglich den WInRM-Service Status wiedergibt.

---
- hosts: windows
  tasks:
  - name: Show WinRM configuration
    win_shell: winrm get winrm/config/service
    register: output
  - debug: var=output.stdout_lines

Basis-Authentifizierung

Als erstes gehe ich auf die Möglichkeit der Basis-Authentifizierung ein. Hierfür legen wir uns einen lokalen Benutzer auf der Maschine an, über den wir uns hinterher mit Ansible anmelden werden. Hierfür drücken wir auf die Windows Start-Schaltfläche in der linken unteren Ecke und geben …

lusrmgr.msc

… ein. Im neu auftauchenden Fenster navigieren wir zu Users -> rechtsklicken auf eine freie Fläche und wählen New User. Hier legen wir uns einen neuen Benutzer, beispielsweise mit dem Namen ansible, an und geben diesem ein Passwort.
Als nächstes starten wir die Powershell als Administrator und aktivieren die Option der Basis-Authentifizierung:

Set-Item -Path WSMan:\localhost\Service\Auth\Basic -Value $true

Alternativ kann auch dieser Befehl verwendet werden.

winrm set winrm/config/service/auth @{Basic="true"}

Die gesetzten Einstellungen lassen sich im Anschluß mit dem folgenden Befehl überprüfen:

winrm get winrm/config/service

In der Ausgabe sollte …

Auth Basic = true

auftauchen.
Als nächstes wechseln wir auf den Ansible-Server und fügen der Ansible-Hosts Datei die WIndows-Zielmaschine hinzu:

nano /etc/ansible/hosts

Im folgenden Beispiel wird die Windows-Maschine der Gruppe windows hinzugefügt und mit einigen Variablen ausgestattet:

[windows]
windows-zielmaschine.domain.name

[windows:vars]
ansible_user=ansible
ansible_password=Pa$$wort-vom-lokalen-ansible-benutzer
ansible_connection=winrm
ansible_port=5985
ansible_winrm_transport=basic

Wichtig für unsere Zwecke ist der Parameter ansible_winrm_transport=basic, der die Art der Authentifizierung definiert.
Als nächstes lässt sich das Playbook wie gewohnt starten:

ansible-playbook /pfad/zum/playbook/get_winrm_config.yml

Möchtet ihr das Passwort nicht im Klartext in einer YAML-Datei ablegen, könnt ihr die entsprechende Variable auch weglassen und den ansible-playbook-Befehl mit dem Parameter -k ergänzen. Dieser gibt euch die Möglichkeit, eurem Playbook Aufruf ein Passwort mitzugeben.

ansible-playbook /pfad/zum/playbook/get_winrm_config.yml -k

Kerberos-Authentifizierung

Die wesentlich sicherere Authentifizierungsmethode ist die über Kerberos. Selbstverständlich muss eure Windows-Zielmaschine Teil einer Domäne sein.
Auf der Windows-Maschine wird zunächst sichergestellt, ob die Kerberos-Authentifizierung eingeschaltet ist. Dies lässt sich mittels einer administrativ ausgeführten Powershell herausfinden:

winrm get winrm/config/service

Dort sollte …

Kerberos = true

… auftauchen. Ist dies nicht der Fall, lässt sich dies im selben Powershell-Fenster hinzuschalten:

winrm set winrm/config/service/auth @{Kerberos="true"}

Alternativ kann auch der folgende Befehl verwendet werden:

Set-Item -Path WSMan:\localhost\Service\Auth\Kerberos -Value $true

Wir wechseln auf den Ansible-Server und passen die Kerberos-Konfigurationsdatei an.

nano /etc/krb5.conf

Diese kann in etwa so aussehen (die individuelle Konfiguration kann natürlich je nach Anwendungsfall unterschiedlich ausfallen):

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = DOMAIN.NAME
 forwardable = true
 dns_lookup_realm = false
 rdns = false

[realms]
 DOMAIN.NAME = {
 kdc = domain.name
 admin_server = domain.name
 }

[domain_realm]
 .domain.name = DOMAIN.NAME
 domain.name = DOMAIN.NAME

Fügt entsprechend der kontaktierten Domäne den korrekten Namen ein und achtet dabei auf Groß- und Kleinschreibung.
Als nächstes überprüfen wir, ob unser Ansible-Server bereits im Besitz eines gültigen Kerberos-Tickets ist:

klist

Ist dies nicht der Fall, können wir uns eines hiermit besorgen:

kinit domain-user@DOMAIN.NAME

Achtet darauf, dass der angegebene Domänen-Benutzer die entsprechenden Berechtigungen besitzt und ihr im Eingabeprompt das korrekte Passwort eingebt.
Nun fügen wir die Windows-Zielmaschine noch der Ansible-Hosts Datei hinzu …

nano /etc/ansible/hosts

… und definieren folgenden Inhalt:

[windows]
windows-zielmaschine.domain.name

[windows:vars]
ansible_user=domain-user@DOMAIN.NAME
ansible_password=Pa$$wort-von-domain-user
ansible_connection=winrm
ansible_port=5985
ansible_winrm_transport=kerberos

Die entscheidende Zeile ist diesmal die ansible_winrm_transport=kerberos. Die Zielmaschine muss zwingend als Namen angegeben werden, da Kerberos unter normalen Umständen keine IP-Adressen akzeptiert.
Ist alles erledigt, kann schlußendlich das Playbook gestartet werden:

ansible-playbook /pfad/zum/playbook/get_winrm_config.yml

Und wie zuvor erwähnt gilt auch hier: Soll das Passwort nicht im Klartext in der YAML-Datei abgelegt werden, kann der Parameter entfernt werden und das Playbook mit dem Zusatzparameter -k aufgerufen werden.

ansible-playbook /pfad/zum/playbook/get_winrm_config.yml -k