Verwenden von Kerberos für Windows in Ansible Automation Platform 2

Kerberos ist häufig die bevorzugte Authentifizierungsmethode für die Verwaltung von Windows-Servern in einer Domain-Umgebung. In Red Hat Ansible Automation Platform können Kunden seit einigen Jahren die Kerberos-Authentifizierung nutzen. Warum also dieses Thema erneut aufgreifen? 

Ansible Automation Platform 2 wurde im Juli 2021 veröffentlicht und umfasste eine umfassende Neugestaltung der Plattformarchitektur. Eine der grundlegenden Änderungen war die Einführung von Ausführungsumgebungen für die Automatisierung  – die Verwendung von Containern, um Ansible Playbooks konsistent zu paketieren, zu verteilen und auszuführen. Ohne ins Detail zu gehen, bestehen Ausführungsumgebungen für die Automatisierung aus einem RHEL Basis-Image, Ansible Core und den Abhängigkeiten, die für die Ausführung unserer Ansible-Automatisierung erforderlich sind. Dabei handelt es sich in der Regel um Ansible Content Collections und Python Libraries. 

Die Umstellung auf Container bedeutet, dass wir manchmal bedenken müssen, dass „localhost“ jetzt ein Container ist. Es gibt einen ausgezeichneten Blog-Beitrag, in dem ausführlich darauf eingegangen wird, warum „localhost“ nicht das ist, was es scheint, wenn es um Ausführungsumgebungen für die Automatisierung geht.

Anhand eines Beispiels möchten wir erläutern, wie Sie die Kerberos-Authentifizierung in Ansible Automation Platform 2 konfigurieren, die Konfiguration testen und Automation Controller für die Verwendung von Kerberos konfigurieren.

Beispielkonfiguration

Um Kerberos mit Ansible zu nutzen, benötigen wir eine Kerberos-Konfigurationsdatei. Der Inhalt der Konfigurationsdatei hängt von Faktoren wie der DNS-Konfiguration, der KDC-Erkennung und der Anzahl der Domains ab. In diesem Beispiel verwenden wir eine einzige Domain namens DEMOLAB.LOCAL, die für unseren Automation Controller-Server nicht erkennbar ist.

Hier ist unser Beispiel für eine Kerberos-Client-Konfiguration. Ein ähnliches Beispiel finden Sie im Automation Controller-Administrations-Guide.

 [libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }  

Jetzt müssen wir Ausführungsumgebungen für die Automatisierung betrachten und uns daran erinnern, dass „localhost“ nicht das ist, was es scheint! Wenn Automation Controller ein Ansible Playbook ausführt, ruft er ein Container Image auf, das keinen Zugriff auf das zugrunde liegende Dateisystem des Controller-Knotens hat. Wir müssen überprüfen, ob die Ausführungsumgebung Zugriff auf die Kerberos-Client-Konfiguration hat. Hierzu gibt es 2 Möglichkeiten.

1. Wir können die Kerberos-Client-Konfiguration der laufenden Ausführungsumgebung von Automation Controller zuordnen.
2. Wir können unsere eigene Ausführungsumgebung mit Ansible Builder anpassen und erstellen und die Datei „krb5.conf“ zum Image hinzufügen.

In diesem Beispiel ordne ich die Kerberos-Client-Konfiguration der laufenden Ausführungsumgebung zu, da ich keine weiteren Änderungen vornehmen muss. 

Um die Datei der Ausführungsumgebung zuzuordnen, schreiben wir die Konfiguration in das Konfigurationsverzeichnis des Kerberos-Clients auf dem Automation Controller-Server namens /etc/krb5.conf.d/DEMOLAB.LOCAL.conf.

 # cat /etc/krb5.conf.d/DEMOLAB.LOCAL.conf 

[libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }   

Tests über die Befehlszeile ausführen

Jetzt können Sie die Konfiguration über die Befehlszeile überprüfen. Sehen wir uns zunächst an, mit welchen Ausführungsumgebungen wir Tests durchführen können. Auf dem Automation Controller-Server können wir zum Benutzer awx wechseln und die Images der Ausführungsumgebung auflisten. Hier können wir sehen, dass die Ausführungsumgebung ee-supported-rhel8 verfügbar ist. Das ist das Image, mit dem ich die Tests ausführen möchte.

 $ su - awx 
$ podman images 
REPOSITORY                                                         TAG     IMAGE ID   CREATED   SIZE 
registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8  latest   024856bccc5f  4 weeks ago  1.66 GB

Wenn Sie einen Test mit einem anderen Image durchführen müssen, verwenden Sie „podman pull“, um das relevante Image aus einer Container Registry zu kopieren.

Jetzt müssen wir prüfen, ob wir das Konfigurationsverzeichnis der Ausführungsumgebung zuordnen, authentifizieren und ein Kerberos-Ticket abrufen können. Der folgende Podman-Befehl startet den Container unserer Ausführungsumgebung und ordnet /etc/krb5.conf.d/ dem ausgeführten Container zu. Wir erhalten auch eine interaktive Shell innerhalb des Containers, damit wir kinit testen können. Ein letzter Hinweis dazu: Kerberos verwendet einen Zugangsdaten-Cache zur Speicherung gültiger Kerberos-Zugangsdaten. Zur Erinnerung: „localhost“ ist hier nicht das, was es zu sein scheint. Daher haben wir keinen Zugriff auf das Dateisystem und den Kerberos-Cache. Wir erstellen einen temporären Kerberos-Zugangsdaten-Cache, um die Konfiguration durch Festlegen der Variablen KRB5CCNAME testen zu können. Das winrm-Verbindungs-Plugin verwendet einen ähnlichen Mechanismus. 

 $ podman run --rm  -v "/etc/krb5.conf.d:/etc/krb5.conf.d:O" -it registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8:latest /bin/bash 

bash-4.4# export KRB5CCNAME=`mktemp` 
bash-4.4# echo $KRB5CCNAME 
/tmp/tmp.ZzBXbtGiV1 
bash-4.4# kinit svc-ansible@DEMOLAB.LOCAL 
Password for svc-ansible@DEMOLAB.LOCAL: 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.ZzBXbtGiV1 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
04/04/23 14:01:37  04/05/23 00:01:37  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 04/11/23 14:01:33 

Als weiteren Test können wir überprüfen, ob das Ticket für die Authentifizierung auf einem bestimmten Server funktioniert. Nachdem kinit erfolgreich in der Ausführungsumgebung ausgeführt wurde, können wir uns mit kvno bei einem Zielhost authentifizieren. In diesem Beispiel möchten wir prüfen, ob das Ticket zur Authentifizierung mit „windows2.demolab.local“ verwendet werden kann.

 bash-4.4# kvno http/windows2.demolab.local 
http/windows2.demolab.local@DEMOLAB.LOCAL: kvno = 1 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.pe2PBReLm5 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
05/10/23 15:26:35  05/11/23 01:26:35  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:33 
05/10/23 15:26:49  05/11/23 01:26:35  http/windows2.demolab.local@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:3

Der Test sieht gut aus! Es wird Zeit, die Konfiguration in Automation Controller zu verschieben. 

Automation Controller konfigurieren

Wir müssen Zugangsdaten vom Typ Machine in Automation Controller für unser Windows-Account hinzufügen. Dies sollte der UPN (User Principal Name) im Format „username@DOMAIN.COM“ sein. Um Zugangsdaten in Automation Controller hinzuzufügen, navigieren Sie im linken Menü zu Credentials, klicken Sie auf Add, und wählen Sie den Zugangsdatentyp Machine aus. Geben Sie den Domain-Benutzer und das Passwort wie folgt ein:

Als Nächstes können Sie die Kerberos-Client-Konfiguration der Ausführungsumgebung zuordnen. Ein Administrator muss Settings -> Job Settings  konfigurieren, den Wert im Feld „Paths to expose to isolated jobs“ bearbeiten und das Kerberos-Verzeichnis hinzufügen. Beachten Sie, dass dies das gleiche Format ist, das wir beim Testen über die CLI verwendet haben. Die neue Konfiguration sollte wie folgt aussehen:

Zeit zum Testen! Wir können ein einfaches „Ping“ Playbook verwenden, um die Konfiguration zu validieren. Wir können die Protokollierung auch auf WinRM-Verbindungsmeldungen erweitern. Bearbeiten Sie das Job-Template, und legen Sie die Ausführlichkeit auf Stufe 5 fest.

Wenn wir das Job-Template starten, sollten die detaillierten Verbindungsmeldungen angezeigt werden.

Es wird angezeigt, dass der temporäre Kerberos-Zugangsdaten-Cache erstellt wurde, das Account authentifiziert werden kann und wir ein Ticket erhalten haben. Das Playbook sollte erfolgreich abgeschlossen werden.

Fehlerbehebung

Bei der Konfiguration von Kerberos in einer Ausführungsumgebung können einige Fehlermeldungen auftreten. Im Folgenden finden Sie einige Fehlermeldungen und mögliche Lösungen.

• Included profile directory could not be read while initializing Kerberos 5 library: Dies könnte darauf hindeuten, dass sich eine Konfigurationsdatei in Ihrem Verzeichnis /etc/krb5.conf.d befindet, die versucht, zusätzliche Verzeichnisse einzubeziehen, auf die die Ausführungsumgebung keinen Zugriff hat. Überprüfen Sie alle Konfigurationsdateien in /etc/krb5.conf.d, die möglicherweise eine includedir-Option enthalten.
• Invalid UID in persistent keyring name while getting default ccache: Denken Sie daran, ein temporäres Cache-Verzeichnis für Zugangsdaten wie oben beschrieben festzulegen.
• Cannot find KDC for realm „<DOMAIN>“ while getting initial credentials: Es kann viele Gründe für diesen Fehler geben. Überprüfen Sie, ob die Kerberos-Konfiguration korrekt ist und ein gültiges KDC in der Konfiguration aufgeführt ist. Wenn Sie die KDCs mithilfe von DNS suchen, stellen Sie sicher, dass „dns_lookup_kdc“ auf „true“ gesetzt ist. 
• Server not found in Kerberos database: Dies kann häufig mit DNS-Problemen oder einem falsch konfigurierten Ansible-Inventory zusammenhängen. Überprüfen Sie, ob der Name des Hosts im Inventory mit dem Namen des Servers im DNS übereinstimmt. Überprüfen Sie außerdem, ob Ansible versucht, mithilfe des FQDN eine Verbindung zum Host herzustellen, indem Sie die WinRM-Debug-Protokolle verwenden. Hier ist ein Beispiel, bei dem die Variable „ansible_host“ für einen Windows-Server festgelegt ist, und wir versuchen, eine Verbindung zur IP anstelle des Hostnamens herzustellen.

Nächste Schritte

Dieses Beispiel war hoffentlich hilfreich, um einige der Änderungen in Ansible Automation Platform 2 und den Einstieg in die Kerberos-Authentifizierung für das Management von Windows-Servern zu verstehen. Windows ist für Ansible weiterhin ein erstklassiger Partner, und es stehen weitere Ressourcen zur Verfügung, die Sie auf Ihrem Weg unterstützen.

• Ansible for Windows: Erfahren Sie, wie Ansible zur Verwaltung der Windows-Infrastruktur und für gängige Use Cases verwendet werden kann.
• Testsubskription: Sind Sie bereit für den Einstieg? Erhalten Sie Ihre eigene Testsubskription für unbegrenzten Zugriff auf alle Komponenten von Ansible Automation Platform.