Joindre Linux à Active Directory sans fragiliser le DNS

Joindre une machine Linux à Active Directory paraît souvent simple parce que la commande finale est courte. Un realm join, quelques paquets installés, un compte autorisé et la machine apparaît dans le domaine. Cette simplicité apparente masque pourtant plusieurs dépendances. Une jointure fiable repose sur le DNS, la synchronisation horaire, Kerberos, SSSD, les droits d’administration, les règles sudo, la gestion des groupes et la capacité à diagnostiquer le chemin d’authentification.

Dans un environnement de production, l’objectif n’est pas seulement de réussir la jointure une fois. Il faut obtenir un modèle reproductible, compatible avec plusieurs distributions, compréhensible par l’équipe système, et suffisamment robuste pour éviter les incidents silencieux. Une machine peut rejoindre le domaine, puis devenir inutilisable quelques jours plus tard parce qu’un resolver change, qu’un contrôleur de domaine n’est plus joignable, qu’un cache SSSD masque le problème ou qu’une règle sudo dépend d’un groupe mal résolu.

DNS et temps avant toute commande

Le DNS est la première dépendance. Une machine Linux doit résoudre correctement le domaine Active Directory, les contrôleurs de domaine, les enregistrements SRV Kerberos et LDAP, et parfois les suffixes internes utilisés par les applications. Si la machine pointe vers un DNS générique ou vers un resolver qui ne connaît pas le domaine, la jointure peut échouer immédiatement ou, pire, fonctionner de manière partielle.

Le test utile ne consiste pas seulement à résoudre le nom court d’un contrôleur de domaine. Il faut vérifier les enregistrements de service. Ce sont eux qui permettent au client de découvrir les services du domaine. Une configuration DNS bricolée peut répondre pour quelques noms fixes, mais échouer dès qu’un contrôleur change ou qu’un site Active Directory différent est utilisé.

DOMAIN="example.local"

# Résolution de base
getent hosts "$DOMAIN"

# Enregistrements SRV nécessaires
nslookup -type=SRV _ldap._tcp.$DOMAIN
nslookup -type=SRV _kerberos._tcp.$DOMAIN

# Vérification du resolver réellement utilisé
cat /etc/resolv.conf
resolvectl status 2>/dev/null || systemd-resolve --status 2>/dev/null

La synchronisation horaire vient immédiatement après. Kerberos tolère peu les écarts. Une machine dont l’heure dérive peut donner l’impression d’un problème de mot de passe, de compte ou de droits alors que le ticket Kerberos est simplement refusé. Avant de diagnostiquer SSSD ou realmd, il faut donc vérifier NTP ou chrony.

Garder une approche multi-distribution

Les distributions ne présentent pas toutes les mêmes paquets ni les mêmes conventions de service. Debian, Ubuntu, RHEL, Rocky, AlmaLinux ou SUSE peuvent différer dans le nom des paquets, la configuration de NetworkManager, l’intégration de systemd-resolved, le comportement de authselect, ou la place exacte des fichiers PAM et NSS.

Pour éviter un script fragile, il vaut mieux séparer le socle commun des adaptations par famille. Le socle commun contient les contrôles DNS, l’heure, les paquets nécessaires, la découverte du domaine, la jointure et les tests SSSD. Les adaptations concernent le gestionnaire de paquets, la configuration réseau et les outils d’authentification propres à la distribution.

Socle commun
DNS correct vers Active Directory
Heure synchronisée
Kerberos fonctionnel
SSSD installé et activé
Découverte du domaine validée
Groupes AD testés localement

Adaptations par distribution
Paquets Debian/Ubuntu ou RHEL-like
Gestion resolv.conf ou systemd-resolved
authselect sur RHEL-like
Configuration PAM et NSS selon distribution

Cette approche évite de faire porter à une seule commande toute la complexité. La jointure devient une séquence contrôlée. Chaque étape peut échouer avec un message compréhensible, ce qui rend l’automatisation plus fiable.

SSSD comme composant central

SSSD est souvent le composant réel d’exploitation après la jointure. Il gère la résolution des identités, l’authentification, le cache, la correspondance des groupes, l’accès hors ligne éventuel et une partie du comportement NSS/PAM. Si SSSD est mal configuré, la machine peut être jointe au domaine mais difficile à utiliser.

Le fichier sssd.conf doit rester lisible. Les options doivent correspondre au besoin réel. Activer trop de comportements par défaut sans les comprendre complique le diagnostic. À l’inverse, une configuration trop minimale peut manquer de contrôles d’accès, laisser passer trop d’utilisateurs ou créer des incohérences dans les noms de groupes.

Les caches SSSD doivent être connus des équipes. Ils sont utiles, mais ils peuvent masquer un problème. Un utilisateur peut continuer à s’authentifier grâce au cache alors que le contrôleur de domaine n’est plus accessible. Un groupe peut sembler présent localement alors que sa résolution réelle échoue. Lors d’un diagnostic, il faut donc savoir quand consulter les logs, quand vider un cache et quand tester une résolution fraîche.

systemctl status sssd --no-pager
journalctl -u sssd -n 100 --no-pager

# Tester la résolution d'un utilisateur et d'un groupe AD
getent passwd utilisateur@example.local
getent group "linux-admins@example.local"

# Vérifier la configuration chargée
sssctl config-check
sssctl domain-status example.local

Droits sudo et contrôle d’accès

La jointure au domaine ne doit pas donner implicitement accès à tout. Il faut définir quels groupes AD peuvent se connecter, quels groupes peuvent obtenir des privilèges sudo, et quelles machines acceptent quels profils d’administration. Sans cette étape, l’intégration AD devient une porte d’entrée trop large.

Un modèle simple consiste à créer des groupes AD dédiés par rôle. Par exemple un groupe pour l’accès SSH standard, un groupe pour l’administration Linux, un groupe pour certains serveurs applicatifs, et un groupe pour les comptes de service. Les règles sudo doivent référencer ces groupes explicitement. Ce modèle reste auditable et évite de dépendre de groupes trop larges comme Domain Admins.

Le contrôle d’accès peut se faire via SSSD, via PAM, via sudoers, ou via une combinaison. L’important est de ne pas laisser une règle implicite décider. Une machine Linux jointe au domaine doit avoir une politique claire : qui peut se connecter, depuis où, avec quel niveau de privilège, et comment cette décision est revue.

Automatiser sans cacher les erreurs

Automatiser la jointure est nécessaire si le parc grandit. Mais le script ne doit pas masquer les erreurs. Un bon playbook Ansible ou un script shell doit tester le DNS, l’heure, les paquets, la découverte du domaine, la jointure, SSSD, la résolution d’un utilisateur test et la règle sudo. Si une étape échoue, il vaut mieux arrêter immédiatement avec un message clair plutôt que continuer et laisser une machine à moitié intégrée.

La commande de jointure doit aussi être idempotente. Une machine déjà jointe ne doit pas être réinscrite sans raison. Un changement de domaine, une suppression d’objet ordinateur ou une rotation de compte de jointure doivent être traités comme des opérations sensibles, pas comme des effets secondaires automatiques.

Avant la jointure
DNS AD validé
Enregistrements SRV LDAP et Kerberos résolus
Heure synchronisée
Paquets installés
Domaine découvert

Après la jointure
Objet ordinateur présent dans la bonne OU
SSSD actif
Utilisateur test résolu
Groupe sudo résolu
Connexion SSH testée
Logs vérifiés

Conclusion

Joindre Linux à Active Directory proprement n’est pas un simple sujet de commande. C’est un petit modèle d’exploitation qui relie DNS, temps, Kerberos, SSSD, droits sudo, groupes AD et diagnostic. La jointure réussie n’est que le début. Le vrai résultat attendu est une machine qui continue à s’authentifier correctement, dont les accès sont contrôlés, et dont les incidents peuvent être expliqués rapidement.

La bonne approche consiste à traiter la jointure comme une séquence vérifiable. DNS et temps d’abord. Découverte du domaine ensuite. Jointure contrôlée. SSSD validé. Groupes et sudo testés. Logs consultables. Avec cette discipline, l’intégration Active Directory devient un composant stable de l’exploitation Linux plutôt qu’une configuration fragile répétée serveur par serveur.