WinRM & Ansible –
Wege der Authentifizierung und Verschlüsselung

Mit Ansible kann man auf einfache Art und Weise eine Vielzahl von Systemen konfigurieren. Die meisten Unternehmen nutzen dies, um ihre Linux-basierten Systeme zu organisieren.

Bei Windows-basierten Systemen ist diese Praxis noch nicht sehr verbreitet. Der Einsatz von Ansible auf Windows gilt nach wie vor als Ausnahme, wobei die Hürde zur Anwendung nicht im technischen Bereich liegt. Windows verfügt über alles, was nötig ist, um mit Ansible konfiguriert und gemanagt zu werden. Mit dem von Windows mitgelieferten Tool „WinRM“ ist dies einfach und ohne zusätzliche Softwareinstallationen möglich.

In diesem Blogeintrag möchten aufzeigen, welche Authentifizierungsmöglichkeiten Ansible für die Anmeldung auf Windows-Systemen nutzt. Zudem präsentieren wir Optionen zur Verschlüsselung der Kommunikation.

Hier möchten wir drei Möglichkeiten der Authentifizierung und Verschlüsselung kurz vorstellen:

1: Basic-Authentifizierung

Auf dem Zielsystem wird ein lokaler User für die Anmeldung verwendet. Passwort und Daten werden unverschlüsselt über HTTP übertragen.

2: Domain-User-Authentifizierung

Zur Anmeldung wird ein Domain User Account verwendet. Die Authentifizierung findet via Kerberos statt. Die Nutzdaten werden weiterhin unverschlüsselt über HTTP übertragen.

3: Zertifikatsbasierte Authentifizierung

Voraussetzung hierfür ist, dass das Zielsystem ein eigenes Serverzertifikat besitzt. Sowohl die Anmeldung als auch die Daten werden in diesem Fall verschlüsselt über HTTPS übertragen.

Voraussetzungen

Ein Windows 2016 oder 2019 Server mit laufendem WinRM-Dienst
Firewall-Freischaltungen für die Ports „TCP 5985 (HTTP)“ und „TCP 5986 (HTTPS)“
Ein Ansible „Master“ Server, z.B. CentOS 7, mit installiertem WinRM(-pywinrm)-Modul
Ein Ansible Test Script bzw. eine Ansible-Test-Rolle, z.B.:

main.yml

---

- name: Test

hosts: all

tasks:

- name: Get WinRM Config

win_shell: winrm get winrm/config/service

register: output

- debug: var=output.stdout_lines

Basic-Authentifizierung

Bei einer Windows-Standardinstallation wird der WinRM-Dienst automatisch mitinstalliert und gestartet. Die WinRM-Konfigurationen „Auth BASIC“ und „AllowUnencrypted“ werden auf TRUE gesetzt. Somit sind hier keine Anpassungen mehr nötig.

Dennoch ist es sinnvoll, die Einstellungen zu kontrollieren.

Command auf dem Windows Host:

C:> winrm get winrm/config/service

Output:

C: srcset= winrm get winrm/config/service“ width=“695″ height=“408″ />

Somit kann man auf dem Ansible Server direkt das Test Script gegen diesen Host verwenden.

Command auf dem Ansible Server:

# ansible-playbook main.yml -i "winansi.windows.atix," -c winrm -u ansibleuser -k -e "ansible_winrm_port=5985"

Output:

Domain-User-Authentifizierung

Voraussetzung für diese Art der Authentifikation ist ein AD (Service) User. Dieser muss auf dem Zielsystem in der Gruppe der lokalen Administratoren hinzugefügt sein.

Weiterhin müssen die WinRM-Konfiguration „Auth Kerberos“ auf TRUE und „AllowUnencryptet“ auf FALSE eingestellt sein.

Commands auf dem Windows Host:

C:> winrm set winrm/config/service @{AllowUnencrypted="false"}
C:> winrm set winrm/config/service/auth @{Basic="false"}
C:> winrm set winrm/config/service/auth @{Kerberos="true"}
C:> winrm get winrm/config/service

Output:

C: srcset= winrm set winrm/config/service“ width=“605″ height=“360″ />

Auf dem Ansible Server (CentOS) muss die Kerberos Library installiert und konfiguriert sein.

Installation:

$ sudo yum install gcc python-devel krb5-devel krb5-workstation python-devel
$ pip install pywinrm[kerberos]

Anpassen der krb5.con:

# vi /etc/krb5.conf

krb5.con:

# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/

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

[libdefaults]
 dns_lookup_realm = false
ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
 default_realm = WINDOWS.ATIX
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
WINDOWS.ATIX = {
  kdc = kerberos.windows.atix
  admin_server = kerberos.windows.atix
 }

[domain_realm]
 .windows.atix = WINDOWS.ATIX
 windows.atix = WINDOWS.ATIX

Anmerkung:
Die blauen Zeilen müssen zumindest angepasst werden. Dabei ist zwingend auf die Groß-/Kleinschreibung zu achten.

Kerberos Testen auf dem Ansible Server

kinit initiert eine Session (z.B. kinit ansiblead@WINWODS.ATIX)

klist zeigt eine Liste aktueller Session Keys

kdestroy löscht die Liste der aktuellen Sessions

Nachdem die Kerberos-Konfiguration eingerichtet ist, kann darüber die Ansible-Authentifizierung laufen.

Command auf dem Ansible Server:

ansible-playbook main.yml -i "winansi.windows.atix," -c winrm -u ansiblead@WINDOWS.ATIX -k -e "ansible_winrm_port=5985"

Output:

Zertifikatsbasierte Authentifizierung

Voraussetzung hierbei ist eine funktionierende Kerberos-Authentifizierung.

Des Weiteren muss das Zielsystem/der Zielserver ein Serverzertifikat besitzen.

Um ein selbstsigniertes Zertifikat auf dem Windows Host zu erstellen und den WinRM Listener einzurichten, sind folgende drei Powershell-Kommandos notwendig.

1: Zertifikat erstellen (erstellt das selbstsignierte Zertifikat mit dem FQDN und einem FriendlyName)

New-SelfSignedCertificate –DnsName ([System.Net.Dns]::GetHostByName($env:computerName)).Hostname -CertStoreLocation “cert:LocalMachineMy”  -FriendlyName Ansible

2: Auslesen des Thumbprint des Zertifikats (liest den Thumbprint des Zertifikates aus)

$dump = Get-ChildItem Cert:LocalMachineMy | where FriendlyName -eq Ansible | select Thumbprint

3: WinRM HTTPS Listener erstellen (erstellt einen WinRM HTTPS Listener mit FQDN und Thumbprint)

New-WSManInstance -ResourceURI winrm/config/Listener -SelectorSet @{address="*";transport="https"} -ValueSet @{Hostname=[System.Net.Dns]::GetHostByName(($env:computerName)).Hostname;CertificateThumbprint=$dump.thumbprint}

TIPP:
Sollten im Windows-Netzwerk keine CA-signierten Serverzertifikate (z.B. über eine Group Policy) verteilt werden, so kann man den oben genannten Dreizeiler in ein Powershell Script verpacken und dies im Deployment der Windows Server automatisiert ausführen lassen.

Ob der Listener korrekt eingetragen wurde, kann mit folgendem Befehl überprüft werden.

C:> winrm e winrm/config/listener

Als letztes muss die WinRM Konfiguration „Auth Certificate“ auf TRUE gesetzt werden.

C:> winrm set winrm/config/service/auth @{Certificate=“true“}

C: srcset= winrm set winrm/config/service/auth“ width=“606″ height=“358″ />
Nachdem alle Konfigurationen eingerichtet sind, kann nun die Ansible Authentifizierung darüber laufen.

Command auf dem Ansible Server:

ansible-playbook main.yml -i "winansi.windows.atix," -c winrm -u ansiblead@WINDOWS.ATIX -k -e "ansible_winrm_port=5986" -e „ansible_server_cert_validation=ignore“

Output:

Fazit

Die Methode der „Basic-Authentifizierung“ ist schnell und einfach eingerichtet. Für produktive Umgebungen empfiehlt es sich, zumindest die Authentifizierung über Kerberos zu machen. Die Verschlüsselung der Kommunikation mit Serverzertifikaten über HTTPS sollte spätestens dann verwendet werden, wenn die Kommunikation zwischen Master und Client über das sichere interne Netz hinaus geht.

Weitere Möglichkeiten der Authentifizierung, die in diesem Artikel nicht angesprochen wurden, sind CredSSP und die Authentifizierung über User-Zertifikate. Weitere Infos zu dem Thema finden Sie auf der offiziellen Ansible-Website „https://docs.ansible.com/“

Ansible-Schulung

ATIX bietet Ansible-Schulungen für Anfänger und Fortgeschrittene an, in denen Teilnehmer:innen lernen, wie man Ansible als Konfigurationsmanagement-Tool nutzt. So können sie ihre Infrastruktur mit Ansible-Rollen effizienter verwalten und finden heraus, wie sie Ansible-Rollen, Inventories und Playbooks bestmöglich erstellen, nutzen und pflegen.

Mehr erfahren