Procédure

1. Se connecter à l'interface Web IdM avec des privilèges d'administrateur. Pour plus de détails, voir Accès à l'interface web IdM dans un navigateur web.
2. Cliquez sur l'onglet Network Services.
3. Cliquez sur l'onglet DNS.

4. Dans le menu déroulant, cliquez sur l'élément DNS Forward Zones.

   

5. Cliquez sur le bouton Add.
6. Dans la boîte de dialogue Add DNS forward zone, ajoutez un nom de zone.
7. Dans la rubrique Zone forwarders, cliquez sur le bouton Add.
8. Dans le champ Zone forwarders, ajoutez l'adresse IP du serveur pour lequel vous souhaitez créer la zone de transfert.

9. Cliquez sur le bouton Add.

   

Procédure

1. Connectez-vous au serveur Windows.
2. Ouvrir Server Manager.
3. Ouvrir DNS Manager.

4. Dans Conditional Forwarders, ajoutez un nouveau forwarder conditionnel avec :

   • L'adresse IP du serveur IdM
   • Un nom de domaine complet, par exemple, server.idm.example.com
5. Sauvegarder les paramètres.

Procédure

1. Lancez une requête DNS pour les enregistrements de service Kerberos over UDP et LDAP over TCP.

   [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.
   0 100 88 server.idm.example.com.
   
   [admin@server ~]# dig +short -t SRV _ldap._tcp.idm.example.com.
   0 100 389 server.idm.example.com.

   Les commandes sont censées répertorier tous les serveurs IdM.

2. Lancer une requête DNS pour l'enregistrement TXT avec le nom du domaine Kerberos de l'IdM. La valeur obtenue devrait correspondre au domaine Kerberos spécifié lors de l'installation d'IdM.

   [admin@server ~]# dig +short -t TXT _kerberos.idm.example.com.
   "IDM.EXAMPLE.COM"

   Si les étapes précédentes n'ont pas permis d'obtenir tous les enregistrements attendus, mettez à jour la configuration DNS avec les enregistrements manquants :

   • Si votre environnement IdM utilise un serveur DNS intégré, entrez la commande ipa dns-update-system-records sans aucune option pour mettre à jour les enregistrements de votre système :

     [admin@server ~]$ ipa dns-update-system-records

   • Si votre environnement IdM n'utilise pas de serveur DNS intégré :

     1. Sur le serveur IdM, exporter les enregistrements DNS IdM dans un fichier :

        [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate

        La commande crée un fichier nommé dns_records_file.nsupdate avec les enregistrements DNS IdM pertinents.

     2. Soumettez une demande de mise à jour DNS à votre serveur DNS à l'aide de l'utilitaire nsupdate et du fichier dns_records_file.nsupdate. Pour plus d'informations, voir Mise à jour des enregistrements DNS externes à l'aide de nsupdate dans la documentation RHEL 7. Vous pouvez également vous référer à la documentation de votre serveur DNS pour l'ajout d'enregistrements DNS.

3. Vérifiez que l'IdM est en mesure de résoudre les enregistrements de service pour AD à l'aide d'une commande qui exécute une requête DNS pour les enregistrements de service Kerberos et LDAP sur TCP :

   [admin@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
   0 100 88 addc1.ad.example.com.
   
   [admin@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
   0 100 389 addc1.ad.example.com.

Procédure

1. Installez le client IdM avec l'option --domain=IPA_DNS_Domain pour que le démon des services de sécurité du système (SSSD) puisse communiquer avec les serveurs IdM :

   [root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com

   Cette option désactive la détection automatique des enregistrements SRV pour le domaine DNS Active Directory.

2. Ouvrez le fichier de configuration /etc/krb5.conf et localisez le mappage existant pour le domaine Active Directory dans la section [domain_realm].

   .ad.example.com = IDM.EXAMPLE.COM
   ad.example.com = IDM.EXAMPLE.COM

3. Remplacez les deux lignes par une entrée mettant en correspondance le nom de domaine complet (FQDN) des clients Linux dans la zone DNS Active Directory avec le domaine IdM :

   idm-client.ad.example.com = IDM.EXAMPLE.COM

   En remplaçant le mappage par défaut, vous empêchez Kerberos d'envoyer ses demandes pour le domaine Active Directory au centre de distribution Kerberos (KDC) de l'IdM. Au lieu de cela, Kerberos utilise la découverte automatique par le biais des enregistrements DNS SRV pour localiser le KDC.

Procédure

1. Créer un nouvel objet hôte sur le serveur IdM :

   [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force

   Utilisez l'option --force, car le nom d'hôte est un CNAME et non un enregistrement A/AAAA.

2. Sur le serveur IdM, autoriser le nom d'hôte DNS IdM à gérer l'entrée d'hôte Active Directory dans la base de données IdM :

   [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
         --hosts=idm-client.idm.example.com

3. Vous pouvez maintenant demander un certificat SSL pour votre client IdM avec l'enregistrement d'extension dNSName pour son nom d'hôte dans le domaine DNS Active Directory :

   [root@idm-client.idm.example.com ~]# ipa-getcert request -r \
         -f /etc/httpd/alias/server.crt \
         -k /etc/httpd/alias/server.key \
         -N CN=`hostname --fqdn` \
         -D `hostname --fqdn` \
         -D idm-client.ad.example.com \
         -K host/idm-client.idm.example.com@IDM.EXAMPLE.COM \
         -U id-kp-serverAuth

Procédure

1. Installez les paquets nécessaires :

   [root@ipaserver ~]# dnf install ipa-server-trust-ad samba-client

2. S'authentifier en tant qu'utilisateur administratif de l'IdM :

   [root@ipaserver ~]# kinit admin

3. Exécutez l'utilitaire ipa-adtrust-install:

   [root@ipaserver ~]# ipa-adtrust-install

   Les enregistrements de service DNS sont créés automatiquement si IdM a été installé avec un serveur DNS intégré.

   Si vous avez installé IdM sans serveur DNS intégré, ipa-adtrust-install imprime une liste d'enregistrements de service que vous devez ajouter manuellement au DNS avant de pouvoir continuer.

4. Le script vous indique que le site /etc/samba/smb.conf existe déjà et qu'il va être réécrit :

   WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
   
   Do you wish to continue? [no]: yes

5. Le script vous invite à configurer le plug-in slapi-nis, un plug-in de compatibilité qui permet aux anciens clients Linux de travailler avec des utilisateurs de confiance :

   Do you want to enable support for trusted domains in Schema Compatibility plugin?
   This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
   
   Enable trusted domains support in slapi-nis? [no]: yes

6. Lorsque vous y êtes invité, entrez le nom NetBIOS du domaine IdM ou appuyez sur Enter pour accepter le nom proposé :

   Trust is configured but no NetBIOS domain name found, setting it now.
   Enter the NetBIOS name for the IPA domain.
   Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
   Example: EXAMPLE.
   
   NetBIOS domain name [IDM]:

7. Vous êtes invité à exécuter la tâche de génération de SID afin de créer un SID pour tous les utilisateurs existants :

   Voulez-vous exécuter la tâche ipa-sidgen ? [non] : yes

   Il s'agit d'une tâche gourmande en ressources, donc si vous avez un grand nombre d'utilisateurs, vous pouvez l'exécuter à un autre moment.

8. (Optional) Par défaut, la plage de ports Dynamic RPC est définie comme 49152-65535 pour Windows Server 2008 et les versions ultérieures. Si vous devez définir une plage de ports Dynamic RPC différente pour votre environnement, configurez Samba pour qu'il utilise d'autres ports et ouvrez ces ports dans les paramètres de votre pare-feu. L'exemple suivant définit la plage de ports à 55000-65000.

   [root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000
   [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
   [root@ipaserver ~]# firewall-cmd --runtime-to-permanent

9. Assurez-vous que le DNS est correctement configuré, comme décrit dans la section Vérification de la configuration DNS d'une confiance.

   Important

   Red Hat vous recommande fortement de vérifier la configuration DNS comme décrit dans la section Vérification de la configuration DNS pour une confiance à chaque fois après l'exécution de ipa-adtrust-install, en particulier si IdM ou AD n'utilisent pas de serveurs DNS intégrés.

10. Redémarrez le service ipa:

    [root@ipaserver ~]# ipactl restart

11. Utilisez l'utilitaire smbclient pour vérifier que Samba répond à l'authentification Kerberos du côté IdM :

    [root@ipaserver ~]# smbclient -L server.idm.example.com -U user_name --use-kerberos=required
    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.15.2)
    ...

Procédure

1. Se connecter à l'interface Web IdM avec des privilèges d'administrateur. Pour plus de détails, voir Accès à l'interface web IdM dans un navigateur web.
2. Dans l'interface Web IdM, cliquez sur l'onglet IPA Server.
3. Dans l'onglet IPA Server, cliquez sur l'onglet Trusts.

4. Dans le menu déroulant, sélectionnez l'option Trusts.

   

5. Cliquez sur le bouton Add.
6. Dans la boîte de dialogue Add Trust, entrez le nom du domaine Active Directory.

7. Dans les champs Account et Password, ajoutez les informations d'identification de l'administrateur Active Directory.

   

8. (Optional) Sélectionnez Two-way trust, si vous souhaitez permettre aux utilisateurs et aux groupes AD d'accéder aux ressources dans IdM. Cependant, la confiance bidirectionnelle dans IdM ne donne aux utilisateurs aucun droit supplémentaire par rapport à la solution de confiance unidirectionnelle dans AD. Les deux solutions sont considérées comme aussi sûres l'une que l'autre en raison des paramètres de filtrage SID par défaut de la confiance inter-forêts.
9. (Optional) Sélectionnez External trust si vous configurez une confiance avec un domaine AD qui n'est pas le domaine racine d'une forêt AD. Bien qu'une confiance de forêt nécessite toujours l'établissement d'une confiance entre IdM et le domaine racine d'une forêt Active Directory, vous pouvez établir une confiance externe entre IdM et n'importe quel domaine au sein d'une forêt AD.

10. (Optional) Par défaut, le script d'installation de trust tente de détecter le type de plage d'identifiants approprié. Vous pouvez également définir explicitement le type de plage d'identifiants en choisissant l'une des options suivantes :

    1. Pour que SSSD génère automatiquement des UID et des GID pour les utilisateurs AD en fonction de leur SID, sélectionnez le type de plage d'ID Active Directory domain. Il s'agit de la configuration la plus courante.

    2. Si vous avez configuré des attributs POSIX pour vos utilisateurs dans Active Directory (tels que uidNumber et gidNumber) et que vous souhaitez que SSSD traite ces informations, sélectionnez le type de plage d'ID Active Directory domain with POSIX attributes.

       

       Avertissement

       Si vous laissez le paramètre Range type sur l'option par défaut Detect, l'IdM tente de sélectionner automatiquement le type de plage approprié en demandant des détails aux contrôleurs de domaine AD dans le domaine racine de la forêt. Si l'IdM ne détecte aucun attribut POSIX, le script d'installation de la confiance sélectionne la plage d'ID 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. 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.

11. Cliquez sur Add.

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

Procédure

1. Demander un ticket pour un utilisateur Active Directory (AD) :

   [root@ipaserver ~]# kinit user@AD.EXAMPLE.COM

2. Demande de tickets de service pour un service dans le domaine IdM :

   [root@server ~]# kvno -S host server.idm.example.com

   Si le ticket de service AD est accordé avec succès, un ticket d'octroi de ticket (TGT) inter-royaumes est listé avec tous les autres tickets demandés. Le TGT est nommé krbtgt/IPA.DOMAIN@AD.DOMAIN.

Procédure

1. Exécutez une requête DNS pour les enregistrements de service MS DC Kerberos over UDP et LDAP over TCP.

   [root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.
   0 100 88 server.idm.example.com.
   
   [root@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com.
   0 100 389 server.idm.example.com.

   Ces commandes dressent la liste de tous les serveurs IdM sur lesquels ipa-adtrust-install a été exécuté. La sortie est vide si ipa-adtrust-install n'a été exécuté sur aucun serveur IdM, ce qui est généralement le cas avant l'établissement de la première relation de confiance.

2. Lancez une requête DNS pour les enregistrements de service Kerberos et LDAP over TCP afin de vérifier que l'IdM est en mesure de résoudre les enregistrements de service pour AD :

   [root@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
   0 100 88 addc1.ad.example.com.
   
   [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
   0 100 389 addc1.ad.example.com.

Procédure

1. Sur le serveur AD, configurez l'utilitaire nslookup.exe pour qu'il recherche les enregistrements de service.

   C:\>nslookup.exe
   > set type=SRV

2. Entrez le nom de domaine pour les enregistrements de service Kerberos sur UDP et LDAP sur TCP.

   > _kerberos._udp.idm.example.com.
   _kerberos._udp.idm.example.com.       SRV service location:
       priority                = 0
       weight                  = 100
       port                    = 88
       svr hostname   = server.idm.example.com
   > _ldap._tcp.idm.example.com
   _ldap._tcp.idm.example.com       SRV service location:
       priority                = 0
       weight                  = 100
       port                    = 389
       svr hostname   = server.idm.example.com

3. Changez le type de service en TXT et lancez une requête DNS pour l'enregistrement TXT avec le nom du royaume IdM Kerberos.

   C:\>nslookup.exe
   > set type=TXT
   > _kerberos.idm.example.com.
   _kerberos.idm.example.com.        text =
   
       "IDM.EXAMPLE.COM"

4. Exécutez une requête DNS pour les enregistrements de service MS DC Kerberos over UDP et LDAP over TCP.

   C:\>nslookup.exe
   > set type=SRV
   > _kerberos._udp.dc._msdcs.idm.example.com.
   _kerberos._udp.dc._msdcs.idm.example.com.        SRV service location:
       priority = 0
       weight = 100
       port = 88
       svr hostname = server.idm.example.com
   > _ldap._tcp.dc._msdcs.idm.example.com.
   _ldap._tcp.dc._msdcs.idm.example.com.        SRV service location:
       priority = 0
       weight = 100
       port = 389
       svr hostname = server.idm.example.com

   Active Directory ne s'attend à découvrir que les contrôleurs de domaine qui peuvent répondre aux demandes de protocole spécifiques à AD, tels que les autres contrôleurs de domaine AD et les contrôleurs de confiance IdM. Utilisez l'outil ipa-adtrust-install pour promouvoir un serveur IdM en contrôleur de confiance, et vous pouvez vérifier quels serveurs sont des contrôleurs de confiance à l'aide de la commande ipa server-role-find --role 'AD trust controller'.

5. Vérifiez que les services AD peuvent être résolus à partir du serveur AD.

   C:\>nslookup.exe
   > set type=SRV

6. Entrez le nom de domaine pour les enregistrements de service Kerberos sur UDP et LDAP sur TCP.

   > _kerberos._udp.dc._msdcs.ad.example.com.
   _kerberos._udp.dc._msdcs.ad.example.com. 	SRV service location:
       priority = 0
       weight = 100
       port = 88
       svr hostname = addc1.ad.example.com
   > _ldap._tcp.dc._msdcs.ad.example.com.
   _ldap._tcp.dc._msdcs.ad.example.com. 	SRV service location:
       priority = 0
       weight = 100
       port = 389
       svr hostname = addc1.ad.example.com

Procédure

1. Sur un contrôleur de confiance existant, exécutez la commande ipa-adtrust-install --add-agents:

   [root@existing_trust_controller]# ipa-adtrust-install --add-agents

   La commande lance une session de configuration interactive et vous invite à fournir les informations nécessaires à la configuration de l'agent.

2. Redémarrer le service IdM sur l'agent de confiance.

   [root@new_trust_agent]# ipactl restart

3. Supprimer toutes les entrées du cache SSSD de l'agent de confiance :

   [root@new_trust_agent]# sssctl cache-remove

4. Vérifiez que le rôle d'agent fiduciaire AD est installé sur la réplique :.

   [root@existing_trust_controller]# ipa server-show new_replica.idm.example.com
   ...
   Enabled server roles: CA server, NTP server, AD trust agent

Procédure

1. Affichez toutes les plages d'identification et notez la plage d'identification AD que vous souhaitez modifier.

   [root@server ~]# ipa idrange-find
   ----------------
   2 ranges matched
   ----------------
     Range name: IDM.EXAMPLE.COM_id_range
     First Posix ID of the range: 882200000
     Number of IDs in the range: 200000
     Range type: local domain range
   
     Range name: AD.EXAMPLE.COM_id_range
     First Posix ID of the range: 1337000000
     Number of IDs in the range: 200000
     Domain SID of the trusted domain: S-1-5-21-4123312420-990666102-3578675309
     Range type: Active Directory trust range with POSIX attributes
   ----------------------------
   Number of entries returned 2
   ----------------------------

2. Ajustez le comportement du groupe privé automatique pour la plage d'ID AD à l'aide de la commande ipa idrange-mod.

   [root@server ~]# ipa idrange-mod --auto-private-groups=hybrid AD.EXAMPLE.COM_id_range

3. Réinitialisez le cache SSSD pour activer le nouveau paramètre.

   [root@server ~]# sss_cache -E

Procédure

1. Connectez-vous à l'interface Web IdM avec votre nom d'utilisateur et votre mot de passe.
2. Ouvrez l'onglet IPA Server → ID Ranges.
3. Sélectionnez la plage d'identifiants que vous souhaitez modifier, par exemple AD.EXAMPLE.COM_id_range.

4. Dans le menu déroulant Auto private groups, sélectionnez l'option hybrid.

   

5. Cliquez sur le bouton Save pour enregistrer vos modifications.

Partie 1 : La commande vérifie les réglages et les entrées

1. Vérifiez que le serveur IdM a le rôle Trust Controller.
2. Valide les options passées à la commande ipa trust-add.
3. Validez la plage d'identifiants associée à un domaine racine de la forêt de confiance. Si vous n'avez pas spécifié le type et les propriétés de la plage d'identifiants en tant qu'options de la commande ipa trust-add, ils sont découverts à partir d'Active Directory.

Partie 2 : La commande tente d'établir une relation de confiance avec un domaine Active Directory

4. Créer un objet de confiance distinct pour chaque direction de confiance. Chacun des objets est créé des deux côtés (IdM et AD). Si vous établissez une confiance à sens unique, un seul objet est créé de chaque côté.

5. Le serveur IdM utilise la suite Samba pour gérer les capacités de contrôleur de domaine pour Active Directory et crée un objet de confiance sur le PDC AD cible :

   1. Le serveur IdM établit une connexion sécurisée au partage IPC$ sur le DC cible. Depuis RHEL 8.4, la connexion nécessite au moins le protocole SMB3 avec Windows Server 2012 et supérieur pour garantir que la connexion est suffisamment sécurisée avec un cryptage basé sur AES utilisé pour la session.
   2. Le serveur IdM demande la présence de l'objet de domaine de confiance (TDO) à l'aide d'un appel LSA QueryTrustedDomainInfoByName.

   3. Si le TDO est déjà présent, supprimez-le en appelant LSA DeleteTrustedDomain.

      Note

      Cet appel échoue si le compte d'utilisateur AD utilisé pour établir la confiance ne dispose pas de tous les privilèges Enterprise Admin (EA) ou Domain Admin (DA) pour la racine de la forêt, tels que les membres du groupe Incoming Forest Trust Builders. Si l'ancien TDO n'est pas automatiquement supprimé, un administrateur AD doit le supprimer manuellement d'AD.

   4. Le serveur IdM crée un nouveau TDO à l'aide d'un appel LSA CreateTrustedDomainEx2. Les informations d'identification du TDO sont générées de manière aléatoire à l'aide d'un générateur de mot de passe fourni par Samba, avec 128 caractères aléatoires.

   5. Le nouveau TDO est ensuite modifié par un appel à LSA SetInformationTrustedDomain pour s'assurer que les types de chiffrement pris en charge par la confiance sont correctement définis :

      1. Le type de cryptage RC4_HMAC_MD5 est activé, même si aucune clé RC4 n'est utilisée, en raison de la conception d'Active Directory.

      2. AES128_CTS_HMAC_SHA1_96 et AES256_CTS_HMAC_SHA1_96 sont activés.

         Note

         Par défaut, RHEL 9 n'autorise pas le cryptage SHA-1, qui est un algorithme requis par AD. Assurez-vous d'avoir activé la sous-politique cryptographique à l'échelle du système AD-SUPPORT pour autoriser le chiffrement SHA-1 dans vos serveurs IdM RHEL 9 pour la communication avec les contrôleurs de domaine AD. Voir <link TBA>.

6. Pour une confiance forestière, vérifiez que les domaines internes à la forêt peuvent être atteints de manière transitive avec un appel LSA SetInformationTrustedDomain.

7. Ajouter des informations sur la topologie de confiance de l'autre forêt (IdM dans le cas d'une communication avec AD, AD dans le cas d'une communication avec IdM) à l'aide d'un appel LSA RSetForestTrustInformation.

   Note

   Cette étape peut provoquer un conflit pour l'une des trois raisons suivantes :

   1. Un conflit d'espace de noms SID, signalé comme une erreur LSA_SID_DISABLED_CONFLICT. Ce conflit ne peut être résolu.
   2. Un conflit d'espace de noms NetBIOS, signalé comme une erreur LSA_NB_DISABLED_CONFLICT. Ce conflit ne peut être résolu.
   3. Un conflit d'espace de noms DNS avec un nom de premier niveau (TLN), signalé comme une erreur LSA_TLN_DISABLED_CONFLICT. Le serveur IdM peut résoudre automatiquement un conflit TLN s'il est causé par une autre forêt.

   Pour résoudre un conflit TLN, le serveur IdM effectue les étapes suivantes :

   1. Récupérer les informations de confiance de la forêt en conflit.
   2. Ajouter une entrée d'exclusion pour l'espace de noms IdM DNS à la forêt AD.
   3. Définir les informations de confiance pour la forêt sur laquelle nous sommes en conflit.
   4. Réessayez d'établir la confiance avec la forêt d'origine.

   Le serveur IdM ne peut résoudre ces conflits que si vous avez authentifié la commande ipa trust-add avec les privilèges d'un administrateur AD qui peut modifier les trusts de la forêt. Si vous n'avez pas accès à ces privilèges, l'administrateur de la forêt d'origine doit effectuer manuellement les étapes ci-dessus dans la section Active Directory Domains and Trusts de l'interface utilisateur Windows.

8. S'il n'existe pas, créez la plage d'ID pour le domaine de confiance.
9. Dans le cas d'une confiance forestière, interrogez les contrôleurs de domaine Active Directory à partir de la racine de la forêt pour obtenir des détails sur la topologie de la forêt. Le serveur IdM utilise ces informations pour créer des plages d'identifiants supplémentaires pour tous les domaines supplémentaires de la forêt approuvée.

Procédure

1. Pour activer le débogage du serveur IdM, créez le fichier /etc/ipa/server.conf avec le contenu suivant.

   [global]
   debug=True

2. Redémarrez le service httpd pour charger la configuration de débogage.

   [root@trust_controller ~]# systemctl restart httpd

3. Arrêtez les services smb et winbind.

   [root@trust_controller ~]# systemctl stop smb winbind

4. Définir le niveau de journalisation de débogage pour les services smb et winbind.

   [root@trust_controller ~]# net conf setparm global 'log level' 100

5. Pour activer la journalisation de débogage pour le code client Samba utilisé par le cadre IdM, modifiez le fichier de configuration /usr/share/ipa/smb.conf.empty pour qu'il contienne le contenu suivant.

       [global]
       log level = 100

6. Supprimer les journaux Samba précédents.

   [root@trust_controller ~]# rm /var/log/samba/log.*

7. Démarrez les services smb et winbind.

   [root@trust_controller ~]# systemctl start smb winbind

8. Imprimer un horodatage lorsque vous tentez d'établir une confiance avec le mode verbeux activé.

   [root@trust_controller ~]# date ; ipa -vvv trust-add --type=ad ad.example.com

9. Consultez les fichiers journaux d'erreurs suivants pour obtenir des informations sur l'échec de la demande :

   1. /var/log/httpd/error_log
   2. /var/log/samba/log.*

10. Désactiver le débogage.

    [root@trust_controller ~]# mv /etc/ipa/server.conf /etc/ipa/server.conf.backup
    [root@trust_controller ~]# systemctl restart httpd
    [root@trust_controller ~]# systemctl stop smb winbind
    [root@trust_controller ~]# net conf setparm global 'log level' 0
    [root@trust_controller ~]# mv /usr/share/ipa/smb.conf.empty /usr/share/ipa/smb.conf.empty.backup
    [root@trust_controller ~]# systemctl start smb winbind

11. (Optional) Si vous ne parvenez pas à déterminer la cause du problème d'authentification :

    1. Rassemblez et archivez les fichiers journaux que vous avez récemment générés.

       [root@trust_controller ~]# tar -xcvf debugging-trust.tar /var/log/httpd/error_log /var/log/samba/log.*

    2. Ouvrez un dossier d'assistance technique Red Hat et fournissez l'horodatage et les journaux de débogage de la tentative.

1. Le client AD contacte le centre de distribution Kerberos AD (KDC) pour effectuer une requête TGS pour le service dans le domaine IdM.
2. Le KDC AD reconnaît que le service appartient au domaine IdM de confiance.
3. Le KDC AD envoie au client un ticket d'attribution de ticket inter-royaumes (TGT), ainsi qu'une référence au KDC IdM de confiance.
4. Le client AD utilise le TGT inter-royaumes pour demander un ticket au KDC IdM.
5. La KDC IdM valide le certificat d'attribut privilégié (MS-PAC) transmis avec le TGT inter-royaumes.
6. Le plugin IPA-KDB peut vérifier l'annuaire LDAP pour voir si des mandants étrangers sont autorisés à obtenir des tickets pour le service demandé.
7. Le plugin IPA-KDB décode le MS-PAC, vérifie et filtre les données. Il effectue des recherches dans le serveur LDAP pour vérifier s'il est nécessaire d'ajouter des informations supplémentaires au MS-PAC, telles que des groupes locaux.
8. Le plugin IPA-KDB encode alors le PAC, le signe, l'attache au ticket de service et l'envoie au client AD.
9. Le client AD peut maintenant contacter le service IdM en utilisant le ticket de service émis par le KDC IdM.

1. Le client AD contacte le centre de distribution Kerberos AD (KDC) dans son propre domaine pour effectuer une demande de TGS pour le service dans le domaine IdM.
2. Le KDC AD de child.ad.example.com, le domaine enfant, reconnaît que le service appartient au domaine IdM de confiance.
3. Le KDC AD du domaine enfant envoie au client un ticket de renvoi pour le domaine racine de la forêt AD ad.example.com.
4. Le client AD contacte le KDC dans le domaine racine de la forêt AD pour le service dans le domaine IdM.
5. Le KDC du domaine racine de la forêt reconnaît que le service appartient au domaine IdM de confiance.
6. Le KDC AD envoie au client un ticket d'attribution de ticket inter-royaumes (TGT), ainsi qu'une référence au KDC IdM de confiance.
7. Le client AD utilise le TGT inter-royaumes pour demander un ticket au KDC IdM.
8. La KDC IdM valide le certificat d'attribut privilégié (MS-PAC) transmis avec le TGT inter-royaumes.
9. Le plugin IPA-KDB peut vérifier l'annuaire LDAP pour voir si des mandants étrangers sont autorisés à obtenir des tickets pour le service demandé.
10. Le plugin IPA-KDB décode le MS-PAC, vérifie et filtre les données. Il effectue des recherches dans le serveur LDAP pour vérifier s'il est nécessaire d'ajouter des informations supplémentaires au MS-PAC, telles que des groupes locaux.
11. Le plugin IPA-KDB encode alors le PAC, le signe, l'attache au ticket de service et l'envoie au client AD.
12. Le client AD peut maintenant contacter le service IdM en utilisant le ticket de service émis par le KDC IdM.

1. Le client IdM demande un ticket d'attribution de ticket (TGT) au centre de distribution Kerberos (KDC) IdM pour le service AD qu'il souhaite contacter.
2. Le KDC IdM reconnaît que le service appartient à la zone AD, vérifie que la zone est connue et approuvée, et que le client est autorisé à demander des services dans cette zone.
3. À l'aide des informations fournies par le serveur d'annuaire IdM sur le principal utilisateur, la KDC IdM crée un TGT inter-royaumes avec un enregistrement de certificat d'attribut privilégié (MS-PAC) sur le principal utilisateur.
4. Le KDC IdM renvoie un TGT inter-royaumes au client IdM.
5. Le client IdM contacte le KDC AD pour demander un ticket pour le service AD, en présentant le TGT inter-royaumes qui contient le MS-PAC fourni par le KDC IdM.
6. Le serveur AD valide et filtre le PAC et renvoie un ticket pour le service AD.
7. Le client IPA peut maintenant contacter le service AD.