Joindre un hôte Linux à Active Directory avec realmd et SSSD

Objectif

Joindre un hôte Linux à un domaine Active Directory afin que les comptes AD puissent s'authentifier et être résolus localement, en utilisant realmd pour piloter SSSD plutôt que d'écrire sssd.conf à la main.

Prérequis

realmd, sssd et les paquets de prise en charge d'AD et de Kerberos doivent être installés (realmd, sssd-ad/sssd-common, adcli, krb5-workstation/krb5-user selon la distribution). La résolution DNS du domaine AD (enregistrements SRV) doit fonctionner, et l'heure doit être synchronisée avec les contrôleurs de domaine : l'authentification Kerberos échoue dès que le décalage d'horloge dépasse une faible tolérance. Selon la documentation du projet, SSSD est le démon client qui met en cache les données d'identité et d'authentification provenant de services d'annuaire, dont Active Directory.

Étapes

1. Avant de tenter la jonction, vérifiez que le domaine est détectable via DNS : realm discover example.com. Si la sortie indique le domaine, son type (kerberos, active-directory) et les paquets requis, les enregistrements SRV et l'accessibilité de base sont confirmés ; en cas d'échec, il faut d'abord corriger le DNS, et non modifier SSSD.
2. Joignez le domaine : realm join -U administrator example.com. Cette commande crée le compte d'ordinateur dans AD, écrit le keytab et génère la section de domaine correspondante dans sssd.conf. Comme realmd gère ce fichier, évitez de modifier à la main les sections dont il a la charge.
3. Restreignez les connexions immédiatement au lieu de laisser le domaine entièrement ouvert : realm permit user@example.com pour un compte, ou realm permit -g "Domain Admins@example.com" pour un groupe ; exécutez d'abord realm deny --all si, par défaut, personne ne doit être autorisé tant qu'il n'a pas été explicitement permis.
4. Vérifiez qu'un compte AD précis est bien résolu : id user@example.com. Une paire UID/GID et des appartenances à des groupes confirment que SSSD résout correctement les identités ; un échec ici alors que realm discover réussit désigne le service SSSD lui-même.
5. Consultez l'état tel que SSSD le perçoit : sssctl domain-list et sssctl domain-status example.com indiquent si le domaine est en ligne et quels fournisseurs sont actifs. Les paramètres id_provider/access_provider du fichier sssd.conf généré montrent quels backends sont réellement configurés.
6. Pour un échec de connexion que id n'explique pas, augmentez le niveau de débogage dans sssd.conf (debug_level = 9 dans la section concernée, puis systemctl restart sssd), reproduisez l'échec, puis collectez les journaux avec sssctl logs-fetch /tmp/sssd-logs.tar (le chemin de l'archive est obligatoire). Le niveau 9 est très verbeux et consigne des informations sensibles ; rétablissez-le ensuite.

Résultat attendu

id user@example.com renvoie un UID/GID résolu ; seuls les comptes ou groupes explicitement autorisés peuvent s'authentifier.

Limites et base de vérification

Vérifié d'après realm(8) (discover, join, permit), sssd.conf(5) (id_provider, access_provider) et sssctl(8). Annulation : realm leave example.com supprime la configuration locale du domaine et empêche SSSD de s'authentifier auprès de celui-ci ; le compte d'ordinateur AD reste en place, sauf si l'on utilise realm leave --remove -U administrator example.com ou si un administrateur du domaine le supprime.