Présentation du plug-in d'inventaire Microsoft Active Directory pour Red Hat Ansible Automation Platform

Cet article s'adresse aux personnes qui utilisent Red Hat Ansible Automation Platform pour gérer des hôtes Windows. Je vais présenter le plug-in d'inventaire Active Directory, qui permet d'utiliser Active Directory comme source de vérité pour Ansible Automation Platform. Intéressons-nous d'abord à l'importance de la gestion des inventaires.

Ansible Automation Platform est un outil d'automatisation simple, puissant et sans agent.

L'architecture sans agent offre de nombreuses possibilités d'automatisation qui ne sont pas limitées à la gestion d'appareils sur lesquels des agents peuvent être installés. Dans cet univers, la gestion des inventaires devient un pilier de la réussite. Voici les informations qu'il faut généralement connaître :

• Quels appareils faut-il gérer ? Où trouver une liste précise et à jour des composants de l'infrastructure ?
• Comment classer les nœuds pour définir les processus automatisés ? Par exemple, les processus automatisés d'un serveur de base de données seront différents de ceux d'un serveur web.

Les plug-ins d'inventaire offrent une réponse adaptée à ces questions. À la base, ce sont des scripts qui permettent de désigner une source de vérité afin de recueillir une liste de serveurs et de caractéristiques pouvant nous aider à comprendre comment automatiser les processus.

Pour gérer un environnement Microsoft Windows, il est très intéressant d'utiliser Active Directory comme source de vérité, car les serveurs sont généralement enregistrés dans un domaine. La collection Red Hat Ansible Certified Content Collection pour Microsoft AD contient un vaste ensemble de modules qui peuvent interagir avec Microsoft Active Directory et, surtout, un plug-in d'inventaire qui  peut exploiter Active Directory comme source de vérité. Ce plug-in d'inventaire permet de filtrer et regrouper les hôtes en fonction de leurs attributs Active Directory et de leur appartenance à un groupe.

Découvrons le fonctionnement de ce plug-in.

Utilisation de la ligne de commande

Accédons d'abord à la ligne de commande pour utiliser les composants Automation Content Navigator et Automation Execution Environment. Les instructions d'installation et de configuration d'Automation Content Navigator sont disponibles dans la documentation relative à la création de contenus. L'environnement d'exécution pris en charge qui est fourni avec Ansible Automation Platform 2.4+ comprend déjà tout ce dont nous avons besoin pour commencer à intégrer Microsoft Active Directory, notamment la collection microsoft.ad et les dépendances Python nécessaires. Si vous utilisez une version antérieure, vous devrez peut-être personnaliser votre environnement d'exécution pour inclure ces éléments.

Le module debug_ldap_client permet de rechercher les dépendances Python nécessaires, ainsi que les configurations DNS et Kerberos. Comme nous utilisons un environnement d'exécution Automation Execution Environment, nous allons exécuter ce module dans l'image pour vérifier que nous disposons des dépendances requises pour le plug-in d'inventaire. Nous pouvons ignorer les erreurs de retraçage, car notre seul but est de nous assurer d'avoir les bonnes dépendances Python pour notre cas d'utilisation.

$ ansible-navigator exec -- ansible localhost -m microsoft.ad.debug_ldap_client
  < Output Truncated >
"packages": {
    "dnspython": "2.3.0",
    "krb5": "0.5.0",
    "pyspnego": "0.9.0",
    "sansldap": "0.1.0"

Pour créer une définition d'inventaire afin d'interroger le serveur Active Directory, le fichier d'inventaire doit se terminer par microsoft.ad.ldap.yml ou microsoft.ad.ldap.yaml. Appelons-le simplement microsoft.ad.ldap.yml. Pour le tester, j'utilise la configuration suivante dans laquelle le nom d'utilisateur et le mot de passe sont pour l'instant en texte brut. L'objectif est juste de nous permettre d'effectuer quelques tests de connexion avant de tester certains attributs. Nous corrigerons les informations d'identification plus tard.

plugin: microsoft.ad.ldap
server: ms-ad.demolab.local
username: svc-aap-ldap
password: Redhat123
tls_mode: ldaps

Nous pouvons maintenant tester le plug-in depuis la ligne de commande à l'aide de la sous-commande de navigation « inventory » d'Ansible Automation Platform. L'utilisation de fichiers ldap implique de mettre en correspondance le magasin de confiance d'autorités de certificats de l'hôte RHEL avec l'environnement d'exécution à l'aide du chemin /etc/pki/ca-trust.

La sortie révèle l'hôte MS-AD, qui est le contrôleur du domaine. 

$ ansible-navigator inventory -i microsoft.ad.ldap.yml --list -m stdout --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
{
"_meta": {
    "hostvars": {
        "MS-AD": {
            "ansible_host": "ms-ad.demolab.local",
            "microsoft_ad_distinguished_name": "CN=MS-AD,OU=Domain Controllers,DC=demolab,DC=local"
        }
    }
},
"all": {
    "children": [
        "ungrouped"
    ]
},
"ungrouped": {
    "hosts": [
        "MS-AD"
    ]
}
}

La connectivité semble satisfaisante, mais nous avons obtenu des informations fragmentées et nous n'avons pas pu ajouter l'hôte à des groupes. Il existe une multitude de paramètres documentés que nous pouvons fournir au plug-in d'inventaire pour le personnaliser en fonction des besoins.

En fait, tous les attributs d'ordinateur d'Active Directory peuvent servir à filtrer et définir des variables ou à regrouper des hôtes. Afin d'afficher tous les attributs disponibles pour l'hôte MS-AD, nous pouvons utiliser la commande PowerShell suivante sur un hôte Windows équipé du module Active Directory PowerShell.

Get-ADComputer -Identity "MS-AD" -Properties *

Ajoutons quelques paramètres et commençons à regrouper les hôtes. Mettez à jour le fichier de configuration de l'inventaire  microsoft.ad.ldap.yml pour inclure d'autres attributs à récupérer à partir d'Active Directory. Dans notre exemple mis à jour, nous obtenons des attributs pour « OperatingSystem » et « location » ainsi qu'une liste de tous les groupes dont fait partie l'ordinateur. Ne prêtez pas attention à la ligne regex_search, je l'ai copiée-collée depuis la documentation.

La dernière section de la configuration définit les groupes Ansible Automation Platform afin que nous puissions classer les nœuds. Toutes les machines sont automatiquement ajoutées au groupe « windows ». Nous inclurons également tout hôte membre du groupe de domaines « Production » à un groupe correspondant appelé « production ». Enfin, nous ajouterons des hôtes à des groupes en fonction des attributs « OperatingSystem » et « location ». Voici le fichier de configuration final.

plugin: microsoft.ad.ldap
server: ms-ad.demolab.local
username: svc-aap-ldap
password: Redhat123
tls_mode: ldaps
attributes:
  OperatingSystem:
operating_system:
  location:
  memberOf:
computer_membership: this | map("regex_search", '^CN=(?P<name>.+?)((?<!\\),)', '\g<name>') | flatten
groups:
  windows: true
  production: '"Production" in computer_membership'
keyed_groups:
- key: operating_system | lower
  prefix: os
  default_value: unknown
- key: location | lower
  default_value: unknown
  prefix: location

Effectuons un dernier test à partir de la ligne de commande. Vérifions les attributs que nous récupérons d'Active Directory. Les valeurs qui affichent la chaîne « __ansible_unsafe »  ne permettent pas de créer des modèles Jinja2.

$ ansible-navigator inventory -i microsoft.ad.ldap.yml -m stdout --host MS-AD --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
{
    "ansible_host": "ms-ad.demolab.local",
    "computer_membership": [
    {
        "__ansible_unsafe": "Production"
    }
    ],
    "location": {
    "__ansible_unsafe": "london-dc1"
    },
    "microsoft_ad_distinguished_name": "CN=MS-AD,OU=Domain Controllers,DC=demolab,DC=local",
    "operating_system": {
    "__ansible_unsafe": "Windows Server 2019 Standard Evaluation"
    }
}

Observons maintenant l'appartenance au groupe. Le serveur fait partie de quatre groupes Ansible Automation Platform que nous pouvons utiliser pour le cibler selon les besoins.

$ ansible-navigator inventory -i microsoft.ad.ldap.yml -m stdout --graph --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
@all:
  |--@_london_dc1:
  |  |--MS-AD
  |--@os_windows_server_2019_standard_evaluation:
  |  |--MS-AD
  |--@production:
  |  |--MS-AD
  |--@windows:
  |  |--MS-AD

Les tests sont terminés. Voyons comment utiliser cette configuration avec Automation Controller dans un environnement d'entreprise.

Configuration d'Automation Controller

Le composant Automation Controller permet aux entreprises de standardiser la manière dont l'automatisation est déployée, lancée, déléguée et vérifiée. Nous devons corriger les informations d'identification en texte brut et mettre en place des contrôles de configuration dans l'inventaire.

1. Créer un type d'informations d'identification : Automation Controller permet de définir des types d'informations d'identification personnalisés pour interagir avec différents systèmes sans compromettre la posture de sécurité. Cette option offre la possibilité d'injecter des variables d'environnement lors de l'exécution plutôt que de les conserver en texte brut. La documentation sur le plug-in d'inventaire indique que celui-ci accepte diverses variables d'environnement pour l'authentification. Nous utiliserons ces variables avec Automation Controller.
   
   Dans l'interface utilisateur d'Automation Controller, accédez au menu « Credential Types » et sélectionnez « Add ». Saisissez un nom pour le type d'informations d'identification, ici « Microsoft AD Inventory ». Pour le paramètre « Input configuration », nous pouvons utiliser ces champs afin de définir les valeurs souhaitées pour le nom d'utilisateur, le mot de passe et le serveur AD.

   fields:
     - id: MICROSOFT_AD_LDAP_USERNAME
   type: string
   label: Username
     - id: MICROSOFT_AD_LDAP_PASSWORD
   type: string
   label: Password
   secret: true
     - id: MICROSOFT_AD_LDAP_SERVER
   type: string
   label: AD Server
   required:
     - MICROSOFT_AD_LDAP_USERNAME
     - MICROSOFT_AD_LDAP_PASSWORD
     - MICROSOFT_AD_LDAP_SERVER

   Le paramètre « injector configuration » définit les variables que nous allons injecter dans la synchronisation de l'inventaire. Utilisez les paramètres suivants :

   env:
     MICROSOFT_AD_LDAP_SERVER: '{{ MICROSOFT_AD_LDAP_SERVER }}'
     MICROSOFT_AD_LDAP_PASSWORD: '{{ MICROSOFT_AD_LDAP_PASSWORD }}'
     MICROSOFT_AD_LDAP_USERNAME: '{{ MICROSOFT_AD_LDAP_USERNAME }}'

2. Créer des informations d'identification  : nous pouvons maintenant créer les informations d'identification correspondant au nouveau type d'informations d'identification. Dans « Credentials », sélectionnez « Add ». Sélectionnez le type d'informations d'identification « Microsoft AD Inventory », puis saisissez le nom d'utilisateur, le mot de passe et le serveur Active Directory, comme nous l'avons fait depuis la ligne de commande.

3. Créer un projet : nous souhaitons gérer la configuration de notre inventaire Active Directory avec le contrôle des sources, afin que les modifications fassent l'objet de révisions et d'approbations par les pairs. Dans Automation Controller, un projet permet d'établir une correspondance avec un référentiel de contrôle de source. J'ai placé la configuration que nous avons écrite pour la ligne de commande dans un référentiel GitHub : https://github.com/pharriso/ansible_microsoft_ad_inventory
   
   IMPORTANT ! Nous n'avons pas appliqué le contrôle des sources aux nom d'utilisateur, mot de passe et serveur Active Directory. Ces informations sont désormais gérées par les informations d'identification dans Automation Controller. Vous devez supprimer les paramètres dans la configuration de l'inventaire.
   
   Dans l'interface utilisateur d'Automation Controller, accédez au menu « Projects », puis sélectionnez « Add ». Les détails de notre projet s'affichent, avec la bonne URL de contrôle de source. Pour en savoir plus sur les  autres champs du menu Projects consultez la documentation.

4. Créer un inventaire  : nous sommes prêts à créer l'inventaire. Accédez au menu « Inventories », sélectionnez « Add », puis « Add Inventory ». Attribuez un nom approprié à l'inventaire.
   
   Une fois que vous l'avez enregistré avec le bouton « Save », d'autres options s'affichent pour l'inventaire. Sélectionnez « Sources », puis « Add ». Pour finir, sélectionnez le fichier de configuration de l'inventaire et les informations d'identification. Voici notre source d'inventaire.

   

   REMARQUE : il est possible que vous deviez saisir manuellement le nom du fichier d'inventaire, puis valider le champ.

Après avoir cliqué sur « Save », vous verrez un bouton « Sync » qui s'affiche en bas de l'écran. Utilisez-le pour exécuter le plug-in d'inventaire. Il est possible de suivre la progression de l'opération avec l'option « Last job status » ou en accédant à l'élément de menu « Jobs ». Espérons que tout fonctionne comme prévu !

Pour valider la configuration du plug-in, accédez au menu « Inventories », « Demolab AD Inventory », puis à l'onglet « Hosts ». Vous devriez voir que les hôtes ont été importés :

Sélectionnez l'hôte pour afficher les variables (attributs) que nous avons recueillies à partir d'Active Directory. Enfin, accédez à l'onglet « Groups » pour vérifier que nous avons bien regroupé les hôtes.

Étapes suivantes

La gestion des inventaires est un élément clé pour optimiser et mettre à l'échelle l'automatisation à l'aide de la solution Ansible Automation Platform. Le plug-in d'inventaire Microsoft AD n'est qu'un exemple de la manière dont Ansible Automation Platform peut simplifier le travail des utilisateurs. Nous espérons qu'en utilisant Active Directory comme source de vérité, vous pourrez tirer parti plus rapidement d'Ansible Automation Platform pour l'automatisation de Windows.

• Ansible Automation Platform pour Windows : découvrez comment Ansible Automation Platform 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.
• Utiliser Kerberos pour gérer les systèmes Windows