WinRM & Ansible – Wege der Authentifizierung und Verschlüsselung

Ansible wird verwendet, um auf einfache Art und Weise eine Vielzahl von Systemen zu konfigurieren.  Die meisten Unternehmen nutzen dies, um ihre Linux-basierten Systeme zu managen.

Bei Windows basierten Systemen ist diese Praxis noch nicht sehr verbreitet. Der Einsatz von Ansible auf Windows gilt nach wie vor als Ausnahme. Die Hürde zur Anwendung liegt bei Systemadministratoren jedoch mehr im mentalen als im technischen Bereich. Denn Windows bringt alles Nötige mit, um mit Ansible konfiguriert und gemanagt zu werden. Mit dem von Windows mitausgelieferten Tool „WinRM“ ist dies einfach und ohne zusätzliche Software Installationen möglich.

In diesem Blogeintrag möchten wir Ihnen zeigen, welche Authentifizierungsmöglichkeiten Ansible für die Anmeldung auf Windows Systemen nutzt. Zudem werden Optionen zur Verschlüsselung der Kommunikation gezeigt.

Drei Möglichkeiten der Authentifizierung und Verschlüsselung sollen hier kurz vorgestellt werden.

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 ist, dass das Zielsystem ein eigenes Serverzertifikat besitzt. Sowohl die Anmeldung als auch die Daten werden in diesem Fall verschlüsselt über HTTPS übertragen.

Voraussetzung

  • 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 / Rolle. Zum Beispiel:

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 Standard Installation wird der WinRM Dienst automatisch mitinstalliert und gestartet. Die WinRM Konfigurationen „Auth BASIC“ und „AllowUnencrypted“ werden auf TRUE gesetzt. Somit sind hier keine initialen 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 auf dem Ansible Server direkt das Test-Script gegen diesen Host verwendet werden.

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 Ziel System in der Gruppe der lokalen Administratoren hinzugefügt sein.

Weiterhin muss sichergestellt sein, dass die WinRM Konfiguration „Auth Kerberos“ auf TRUE eingestellt ist und „AllowUnencryptet“ auf FALSE eingestellt ist.

Command‘s 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.conf

# vi /etc/krb5.conf

krb5.conf

# 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 mindestens angepasst werden. Dabei ist zwingend auf die Groß.- / Kleinschreibung zu achten.

Kerberos Testen auf dem Ansible Server

kinit -> Initiert eine Session (Beispiel: 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 / Server 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:\LocalMachine\My”  -FriendlyName Ansible

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

$dump = Get-ChildItem Cert:\LocalMachine\My\ | 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 dieses 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 Server Zertifikaten ü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/

The following two tabs change content below.
Daniel Schumacher

Daniel Schumacher

Daniel Schumacher

Neueste Artikel von Daniel Schumacher (alle ansehen)

This post is also available in: English