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.
✉️ Immer einen Schritt voraus – mit unserem Newsletter!
Mit unserem Newsletter erhalten Sie regelmäßig Informationen zu aktuellen IT-Themen und Open-Source-Lösungen – kompakt und relevant.
👉 Jetzt kostenlos anmelden
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.
Möglichkeiten der Authentifizierung und Verschlüsselung
Hier möchten wir drei Möglichkeiten der Authentifizierung und Verschlüsselung kurz vorstellen:
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:
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:
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“}
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/“
