Utiliser Kerberos pour Windows dans Ansible Automation Platform 2

L'authentification Kerberos est largement utilisée pour gérer des serveurs Windows au sein d'un domaine. Depuis plusieurs années, Red Hat Ansible Automation Platform permet déjà aux clients d'utiliser cette méthode. Qu'y a-t-il de plus à dire aujourd'hui sur ce sujet ? 

Lancée en juillet 2021, la solution Ansible Automation Platform 2 a été une véritable refonte de la plateforme. Elle a notamment introduit les environnements d'exécution Automation Execution Environment , qui permettent d'utiliser des conteneurs pour mettre en paquet, distribuer et exécuter des playbooks Ansible de manière cohérente. Ces environnements comprennent une image de base Red Hat Enterprise Linux (RHEL), Ansible Core et toutes les dépendances nécessaires à l'exécution de processus automatisés avec Ansible (généralement des collections de contenus Ansible Content Collections et des bibliothèques Python). 

Dans le cadre de la conteneurisation, la machine localhost peut devenir un conteneur. Un article de blog explique en quoi la machine localhost n'est pas ce qu'elle paraît être avec les environnements d'exécution Automation Execution Environment.

Prenons un exemple pour comprendre comment configurer l'authentification Kerberos dans Ansible Automation Platform 2, la tester et configurer Automation Controller pour qu'il l'utilise.

Exemple de configuration

Pour utiliser Kerberos avec Ansible, nous avons besoin d'un fichier de configuration Kerberos. Celui-ci peut varier en fonction de facteurs tels que la configuration DNS, la découverte du KDC et le nombre de domaines. Dans cet exemple, nous avons un seul domaine, DEMOLAB.LOCAL, que notre serveur Automation Controller ne peut pas découvrir.

Voici notre exemple de configuration du client Kerberos. Il existe un exemple similaire décrit dans le guide d'administration d'Automation Controller.

 [libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

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

Intéressons-nous maintenant aux environnements d'exécution Automation Execution Environment, sans oublier que la machine localhost n'est pas ce qu'elle paraît être. Lorsque Automation Controller exécute un playbook Ansible, il invoque une image de conteneur qui n'a pas accès au système de fichiers sous-jacent du nœud de contrôleur. Nous devons vérifier que l'environnement d'exécution a accès à la configuration du client Kerberos. Il existe deux options :

1. Mettre en correspondance la configuration du client Kerberos avec l'environnement d'exécution actuel depuis Automation Controller
2. Personnaliser et créer un environnement d'exécution à l'aide d'Ansible Builder et ajouter la configuration krb5.conf à l'image

Pour cet exemple, je vais mettre en correspondance la configuration du client Kerberos avec l'environnement d'exécution, car je n'ai aucune autre modification à apporter. 

Enregistrons la configuration dans le répertoire de configuration du client Kerberos sur le serveur Automation Controller, /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 
 }   

Test à partir de la ligne de commande

Nous pouvons vérifier la configuration depuis la ligne de commande. Tout d'abord, vérifions les environnements d'exécution dont nous disposons pour les tests. Sur le serveur Automation Controller, nous pouvons basculer vers l'utilisateur awx et obtenir une liste des différentes images. L'environnement d'exécution ee-supported-rhel8 semble disponible, et il s'agit de l'image que je souhaite utiliser pour les tests.

$ 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 

Pour effectuer un test avec une autre image, il faut utiliser la commande « podman pull » pour copier l'image correspondante à partir d'un registre de conteneurs.

Il est temps d'essayer de mettre en correspondance le répertoire de configuration avec l'environnement d'exécution, de nous authentifier et d'obtenir un ticket Kerberos. La commande Podman suivante va démarrer le conteneur de l'environnement d'exécution et mettre en correspondance le répertoire /etc/krb5.conf.d/ avec le conteneur en cours d'exécution. Nous pourrons aussi accéder à un shell interactif dans le conteneur pour pouvoir tester kinit. Il faut également savoir que Kerberos utilise un cache pour conserver les informations d'identification Kerberos valides. Rappelons que la machine localhost n'est pas ce qu'elle paraît être ici, ce qui nous empêche d'accéder au système de fichiers et au cache Kerberos. Nous allons créer un cache temporaire d'informations d'identification Kerberos pour tester la configuration en définissant la variable KRB5CCNAME. Le plug-in de connexion winrm utilise un mécanisme similaire. 

 $ 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 

Nous pouvons également tester le bon fonctionnement du ticket pour l'authentification sur un serveur spécifique. Après avoir exécuté kinit dans l'environnement d'exécution, il est possible d'utiliser kvno pour s'authentifier auprès d'un hôte cible. Dans cet exemple, vérifions que nous pouvons utiliser le ticket pour nous authentifier auprès de l'hôte windows2.demolab.local.

 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

Le résultat du test semble correct. Il est temps de passer à la configuration d'Automation Controller. 

Configuration d'Automation Controller

Nous devons ajouter les informations d'identification de type Machine dans Automation Controller pour notre compte Windows. Il doit s'agir du nom d'utilisateur principal au format « username@DOMAIN.COM ». Pour ajouter des informations d'identification dans Automation Controller, accédez au menu Credentials à gauche, puis sélectionnez Add et le type d'informations d'identification Machine. Saisissez l'utilisateur du domaine et le mot de passe indiqués ci-dessous :

Nous pouvons ensuite mettre en correspondance la configuration du client Kerberos avec l'environnement d'exécution. Un administrateur doit configurer les paramètres sous Settings -> Job Settings  et modifier le chemin d'accès aux tâches isolées (path to expose to isolated jobs) en ajoutant le répertoire Kerberos. Il s'agit du même format que celui que nous avons utilisé lors des tests à partir de l'interface en ligne de commande. La nouvelle configuration doit ressembler à ce qui suit :

Effectuons un test. Il est possible d'utiliser un simple playbook « ping » pour valider la configuration. Nous pouvons également augmenter le niveau de journalisation pour inclure les messages de connexion WinRM. Modifiez le modèle de tâche et définissez le niveau de détail sur 5.

Une fois le modèle de tâche lancé, des messages de connexion détaillés doivent s'afficher.

Le cache temporaire d'informations d'identification Kerberos est bien créé, le compte peut s'authentifier et nous avons obtenu un ticket. L'exécution du playbook devrait se terminer correctement.

Résolution des problèmes

Il est possible de rencontrer des messages d'erreur lors de la configuration de Kerberos au sein d'un environnement d'exécution. Voici quelques-unes de ces erreurs et leurs solutions.

• Le répertoire du profil inclus n'a pas pu être lu lors de l'initialisation de la bibliothèque Kerberos 5 : un fichier de configuration dans le répertoire /etc/krb5.conf.d peut tenter d'inclure des répertoires supplémentaires auquel l'environnement d'exécution n'a pas accès. Vérifiez tous les fichiers de configuration dans /etc/krb5.conf.d pouvant comporter l'option includedir.
• UID non valide dans le nom du gestionnaire de clés persistant lors de l'obtention du cache par défaut : n'oubliez pas de définir un répertoire de cache temporaire d'informations d'identification comme décrit ci-dessus.
• Impossible de trouver le KDC pour le domaine « <DOMAIN> » lors de l'obtention des informations d'identification initiales : cette erreur peut être due à de nombreuses raisons. Vérifiez la configuration de Kerberos et assurez-vous qu'un KDC valide existe. Si vous recherchez des KDC par DNS, le paramètre dns_lookup_kdc doit être défini sur true. 
• Serveur introuvable dans la base de données Kerberos : cette erreur est souvent liée à des problèmes de DNS ou à la mauvaise configuration d'un inventaire Ansible. Vérifiez que le nom de l'hôte dans l'inventaire correspond à celui du serveur DNS. Vérifiez également qu'Ansible tente de se connecter à l'hôte à l'aide du nom de domaine complet en utilisant les journaux de débogage WinRM. Dans l'exemple suivant, la variable ansible_host est définie pour un serveur Windows et nous essayons de nous connecter à l'adresse IP au lieu du nom d'hôte.

Étapes suivantes

Nous venons d'expliquer certaines nouveautés d'Ansible Automation Platform 2 et comment mettre en place l'authentification Kerberos pour gérer des serveurs Windows. Ansible fonctionne toujours très bien avec Windows, et d'autres ressources peuvent vous aider à utiliser la plateforme.

• Ansible pour Windows : découvrez comment Ansible permet de gérer l'infrastructure Windows et les cas d'utilisation courants.
• Souscription d'essai : vous souhaitez vous lancer ? Obtenez une souscription d'essai pour bénéficier d'un accès illimité à tous les composants d'Ansible Automation Platform.