Rechercher

9.4. Mise en place d'un accord de confiance à l'aide d'Ansible

download PDF

Cette section décrit comment configurer un accord de confiance à sens unique entre Identity Management (IdM) et Active Directory (AD) à l'aide d'un playbook Ansible. Vous pouvez configurer trois types d'accords de confiance :

  • One-way trust- option par défaut. La confiance à sens unique permet aux utilisateurs et aux groupes Active Directory (AD) d'accéder aux ressources du domaine IdM, mais pas l'inverse. Le domaine IdM fait confiance à la forêt AD, mais la forêt AD ne fait pas confiance au domaine IdM.
  • Two-way trust- La confiance réciproque permet aux utilisateurs et aux groupes AD d'accéder aux ressources de l'IdM.

    Vous devez configurer une confiance à double sens pour des solutions telles que Microsoft SQL Server qui s'attendent à ce que les extensions Microsoft S4U2Self et S4U2Proxy du protocole Kerberos fonctionnent au-delà d'une limite de confiance. Une application sur un hôte IdM RHEL peut demander à un contrôleur de domaine Active Directory des informations S4U2Self ou S4U2Proxy sur un utilisateur AD, et une confiance à double sens fournit cette fonctionnalité.

    Notez que cette fonctionnalité de confiance bidirectionnelle ne permet pas aux utilisateurs de l'IdM de se connecter aux systèmes Windows, et que la confiance bidirectionnelle dans l'IdM ne donne aux utilisateurs aucun droit supplémentaire par rapport à la solution de confiance unidirectionnelle dans AD.

    • Pour créer la confiance réciproque, ajoutez la variable suivante à la tâche du playbook ci-dessous : two_way: true
  • External trust - une relation de confiance entre l'IdM et un domaine AD dans différentes forêts. Alors qu'une confiance forestière nécessite toujours l'établissement d'une confiance entre l'IdM et le domaine racine d'une forêt Active Directory, une confiance externe peut être établie entre l'IdM et un domaine à l'intérieur d'une forêt. Cette solution n'est recommandée que s'il n'est pas possible d'établir une confiance forestière entre les domaines racines d'une forêt pour des raisons administratives ou organisationnelles.

    • Pour créer la confiance externe, ajoutez la variable suivante à la tâche du playbook ci-dessous : external: true

Conditions préalables

  • Nom d'utilisateur et mot de passe d'un administrateur Windows.
  • Le mot de passe de l'IdM admin.
  • Vous avez préparé le serveur IdM pour la confiance.
  • Vous utilisez la version 4.8.7 d'IdM ou une version ultérieure. Pour connaître la version d'IdM installée sur votre serveur, exécutez ipa --version.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.
    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquet ansible-freeipa.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM sur lequel vous configurez la confiance.

Procédure

  1. Naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Sélectionnez l'un des scénarios suivants en fonction de votre cas d'utilisation :

    • Pour créer un accord de confiance de mappage d'ID, dans lequel SSSD génère automatiquement des UID et des GID pour les utilisateurs et les groupes AD en fonction de leurs SID, créez un playbook add-trust.yml avec le contenu suivant :

      ---
      - name: Playbook to create a trust
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
          - name: ensure the trust is present
            ipatrust:
              ipaadmin_password: "{{ ipaadmin_password }}"
              realm: ad.example.com
              admin: Administrator
              password: secret_password
              range_type: ipa-ad-trust
              state: present

      Dans l'exemple :

      • realm définit la chaîne de nom du domaine AD.
      • admin définit la chaîne de l'administrateur du domaine AD.
      • password définit la chaîne de mots de passe de l'administrateur du domaine AD.
    • Pour créer un accord de confiance POSIX, dans lequel SSSD traite les attributs POSIX stockés dans AD, tels que uidNumber et gidNumber, créez un playbook add-trust.yml avec le contenu suivant :

      ---
      - name: Playbook to create a trust
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
          - name: ensure the trust is present
            ipatrust:
              ipaadmin_password: "{{ ipaadmin_password }}"
              realm: ad.example.com
              admin: Administrator
              password: secret_password
              range_type: ipa-ad-trust-posix
              state: present
    • Pour créer un accord de confiance dans lequel IdM tente de sélectionner automatiquement le type de plage approprié, ipa-ad-trust ou ipa-ad-trust-posix, en demandant des détails aux contrôleurs de domaine AD dans le domaine racine de la forêt, créez un playbook add-trust.yml avec le contenu suivant :

      ---
      - name: Playbook to create a trust
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
          - name: ensure the trust is present
            ipatrust:
              ipaadmin_password: "{{ ipaadmin_password }}"
              realm: ad.example.com
              admin: Administrator
              password: secret_password
              state: present
    Avertissement

    Si vous ne spécifiez pas de type de plage d'identifiants lors de la création d'un trust et si IdM ne détecte aucun attribut POSIX dans le domaine racine de la forêt AD, le script d'installation du trust sélectionne la plage d'identifiants Active Directory domain.

    Si IdM détecte des attributs POSIX dans le domaine racine de la forêt, le script d'installation de la confiance sélectionne la plage d'ID Active Directory domain with POSIX attributes et suppose que les UID et les GID sont correctement définis dans AD.

    Cependant, si les attributs POSIX ne sont pas correctement définis dans AD, vous ne pourrez pas résoudre les utilisateurs AD. Par exemple, si les utilisateurs et les groupes qui ont besoin d'accéder aux systèmes IdM ne font pas partie du domaine racine de la forêt, mais sont plutôt situés dans un domaine enfant du domaine de la forêt, le script d'installation peut ne pas détecter les attributs POSIX définis dans le domaine AD enfant. Dans ce cas, Red Hat vous recommande de choisir explicitement le type de plage d'ID POSIX lors de l'établissement de la confiance.

  3. Enregistrer le fichier.
  4. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory add-trust.yml

Ressources supplémentaires

  • /usr/share/doc/ansible-freeipa/README-trust.md
  • /usr/share/doc/ansible-freeipa/playbooks/trust
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.