Jointure Linux Active Directory en multi-distribution avec SSSD et discipline DNS

Un realm join réussi prouve beaucoup moins de choses qu’on ne l’imagine souvent. La jointure elle-même est rarement la partie difficile. La fragilité apparaît ensuite, quand le DNS est incohérent, quand les tickets Kerberos expirent, quand SSSD résout les identités autrement que prévu, ou quand PAM accepte l’authentification sans jamais produire une session réellement exploitable.

Cet article est volontairement pensé en multi-distribution. La chaîne technique reste la même sur un déploiement sérieux, avec DNS, Kerberos, realmd, adcli, SSSD, PAM et un contrôle clair des autorisations. Ce qui change d’une famille de distribution à l’autre concerne surtout les paquets, quelques comportements par défaut, certaines habitudes d’exploitation et la manière de diagnostiquer les écarts.

Objectif réel de l’article

L’état cible est simple.

Un serveur Linux est joint à Active Directory.

Les utilisateurs et groupes du domaine sont correctement résolus.

La connexion interactive fonctionne.

La création du répertoire personnel est prévisible.

L’accès est limité aux bonnes identités.

La machine peut être validée avec une courte checklist post-jointure, au lieu de supposer que tout est encore sain parce que la jointure a fonctionné une fois la semaine précédente.

Périmètre et hypothèses

Les exemples ci-dessous partent des hypothèses suivantes.

La connectivité réseau doit exister vers les serveurs DNS intégrés à AD, vers Kerberos et vers les services LDAP utilisés par ton design. Si la résolution de noms est déjà instable, il ne faut pas commencer par la commande de jointure. Il faut d’abord corriger le DNS.

La chaîne technique qui compte sur toutes les distributions

La pile reste la même même lorsque les noms de paquets changent.

realmd orchestre la découverte et la jointure.

adcli gère les opérations de compte machine dans AD.

SSSD traite la résolution d’identité, le cache d’authentification, l’intégration NSS et PAM.

Kerberos apporte la couche de confiance et de tickets.

PAM et oddjob-mkhomedir ou un mécanisme équivalent décident si une authentification réussie devient réellement une session utilisable.

C’est pour cette raison qu’une approche multi-distribution est plus solide quand l’article garde un socle de diagnostic commun et ne se sépare par distribution qu’au moment où les paquets ou le comportement changent réellement.

Vérifier le DNS avant toute tentative de jointure

Si le DNS est mauvais, tout le reste devient trompeur. Le serveur peut découvrir une partie de l’annuaire, joindre le domaine avec un succès partiel, ou résoudre un contrôleur mais pas les autres.

hostname -f
cat /etc/resolv.conf
resolvectl status

dig _ldap._tcp.dc._msdcs.example.local SRV
dig _kerberos._tcp.example.local SRV

dig dc01.example.local
dig dc02.example.local
getent hosts dc01.example.local
getent hosts dc02.example.local

Ce qu’il faut obtenir est simple, avec une découverte SRV cohérente, une résolution stable des contrôleurs et aucune dépendance involontaire à un résolveur public qui ignore complètement l’espace de noms AD.

Une jointure peut sembler fonctionner avec un DNS cassé si un contrôleur reste joignable et déjà en cache. L’échec n’apparaît alors qu’ensuite, sous forme de connexions aléatoires, de résolution de groupes incohérente ou d’échecs kinit intermittents.

Vérifier le temps et Kerberos

La dérive de temps reste une des manières les plus simples de produire une jointure qui semble propre mais qui se comporte mal lors de l’authentification réelle.

timedatectl

# Utiliser chronyc ou ntpq selon la pile présente
chronyc sources -v || true
ntpq -pn || true

kinit administrator@EXAMPLE.LOCAL
klist

Si kinit échoue avant la jointure, le problème est souvent plus simple à isoler que lorsqu’il faut ensuite raisonner au milieu de SSSD et de PAM.

Installation des paquets selon la famille de distribution

L’erreur classique consiste à reprendre une liste de paquets trouvée dans un article mono-distribution et à supposer qu’elle s’applique partout.

Famille Ubuntu et Debian

sudo apt update
sudo apt install -y   realmd sssd sssd-tools adcli krb5-user   samba-common-bin packagekit   oddjob oddjob-mkhomedir   libnss-sss libpam-sss

Famille RHEL, Rocky et AlmaLinux

sudo dnf install -y   realmd sssd sssd-tools adcli krb5-workstation   samba-common-tools oddjob oddjob-mkhomedir   authselect authselect-compat

Sur les systèmes de type RHEL récents, authselect compte réellement, car la gestion du profil PAM et NSS ne doit pas être modifiée à la main sans méthode.

Découvrir le domaine avant de joindre

La découverte permet de vérifier que l’hôte voit correctement l’annuaire avant d’écrire son identité machine.

realm discover example.local

Le résultat doit confirmer le type d’annuaire, le nom de domaine détecté, le logiciel client utilisé et le logiciel serveur observé. Si la découverte est lente, incohérente ou vide, c’est déjà un indicateur fort que les hypothèses DNS ou réseau sont mauvaises.

Réaliser une jointure maîtrisée

La commande de jointure est courte. Les décisions autour ne le sont pas.

sudo realm join example.local   -U administrator   --computer-ou="OU=Linux,OU=Servers,DC=example,DC=local"

Joindre directement dans la bonne OU est utile. Cela évite du nettoyage après coup, garde l’intention de délégation et de GPO lisible, et facilite l’automatisation ensuite.

Il faut valider la jointure immédiatement au lieu de faire confiance au simple code de retour de la commande.

realm list
sudo adcli info example.local
sudo adcli testjoin

Relire et normaliser SSSD

Même si la jointure remplit une configuration automatiquement, il faut la relire. Un défaut fonctionnel n’est pas une configuration intentionnelle.

Une base pragmatique ressemble à ceci.

[sssd]
services = nss, pam, sudo
config_file_version = 2
domains = example.local

[domain/example.local]
id_provider = ad
access_provider = ad
cache_credentials = true
default_shell = /bin/bash
use_fully_qualified_names = false
fallback_homedir = /home/%u
ldap_id_mapping = true

Ensuite, il faut imposer les bons droits et redémarrer SSSD.

sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
sudo systemctl status sssd --no-pager

Les décisions importantes ici ne sont pas décoratives.

use_fully_qualified_names = false change la manière dont on référence les identités dans sudo, dans les scripts ou dans les habitudes d’exploitation.

fallback_homedir détermine l’emplacement de la première session interactive.

cache_credentials = true améliore la résilience lors d’une perte temporaire de connectivité annuaire, mais oblige aussi à raisonner correctement sur le cache pendant le diagnostic.

ldap_id_mapping = true simplifie les environnements qui ne gèrent pas d’attributs POSIX de manière centralisée. Dans un environnement avec une gouvernance stricte des UID et GID, un autre choix peut être préférable.

Intégration d’authentification selon la distribution

Famille Ubuntu et Debian

Dans la plupart des cas, realmd et les scripts de paquets câblent correctement PAM, mais il faut quand même vérifier que la création automatique du répertoire personnel est active.

grep mkhomedir /etc/pam.d/common-session /etc/pam.d/common-session-noninteractive || true
sudo pam-auth-update

Famille RHEL, Rocky et AlmaLinux

Il faut utiliser authselect au lieu de modifier les piles PAM sans cadre.

sudo authselect select sssd with-mkhomedir --force
sudo systemctl enable --now oddjobd
sudo authselect current

Cette étape est facile à ignorer quand un test de labo passe en SSH avec un compte déjà connu. Elle devient visible seulement quand de nouveaux utilisateurs ne peuvent pas ouvrir correctement leur première session.

Valider la résolution des utilisateurs et groupes

Joindre l’hôte n’est pas la même chose que prouver que le chemin d’identité est sain.

id user1
getent passwd user1
getent group linux-admins
getent group "domain admins" || true

Ce qui compte ici est la cohérence. id, getent, SSH et sudo doivent tous raconter la même histoire sur les comptes et les groupes.

S’ils ne sont pas cohérents, il y a généralement trois causes. La découverte DNS est instable. La configuration SSSD ne correspond pas aux conventions de nommage attendues. Ou bien les tests portent encore sur un état de cache ancien.

Limiter explicitement qui peut se connecter

La posture d’accès par défaut est souvent plus large que ce que les équipes imaginent. Il ne faut pas supposer que la jointure a créé le modèle d’autorisation voulu.

# accès large, rarement le meilleur choix à long terme
sudo realm permit --all

# contrôle plus explicite
sudo realm deny --all
sudo realm permit -g "linux-admins"

Tous les environnements ne gardent pas realm permit comme couche d’autorisation finale. Certains s’appuient sur des règles SSSD, d’autres sur des groupes annuaire avec une politique plus stricte. Le point important est surtout de rendre le modèle d’accès explicite et testable.

Ajouter sudo via un groupe AD

Une fois les conventions de nommage fixées, sudo peut rester très simple.

%linux-admins ALL=(ALL:ALL) ALL

Si l’environnement garde les noms pleinement qualifiés, la référence au groupe change. C’est une bonne raison de décider tôt si l’on veut des noms courts ou des noms qualifiés sur tout le parc.

Il faut valider le résultat avec un vrai compte, pas seulement avec le fichier.

sudo -l -U user1

Purger le cache SSSD pendant le diagnostic

Le cache est utile jusqu’au moment où il masque l’état que l’on essaie précisément de comprendre.

sudo sss_cache -E
sudo systemctl restart sssd
journalctl -u sssd --no-pager -n 100

Cette séquence doit être utilisée comme outil de diagnostic, pas comme réflexe d’exploitation quotidien.

Une checklist post-jointure qui vaut vraiment quelque chose

Cette liste courte attrape la majorité des intégrations fragiles avant que les utilisateurs ne les rencontrent.

hostname -f
realm list
sudo adcli testjoin
klist
id user1
getent passwd user1
getent group linux-admins
sudo -l -U user1
journalctl -u sssd --no-pager -n 100

Si l’un de ces contrôles échoue, la jointure n’est pas terminée du point de vue de l’exploitation.

Les pannes qui reviennent le plus souvent

Le DNS reste la première source de faux sentiment de sécurité. Un serveur pointé vers les mauvais résolveurs peut encore réussir un test partiel, puis échouer de manière imprévisible lorsque la sélection du contrôleur change.

La dérive de temps arrive juste derrière. Kerberos ne devient pas tolérant simplement parce que l’hôte est virtuel et peu chargé.

Le troisième problème fréquent est l’incohérence de nommage. Les équipes pensent en noms courts, puis écrivent sudo, les scripts ou la supervision avec des noms pleinement qualifiés, ou l’inverse.

Le quatrième est la confusion liée au cache. On corrige un groupe, on reteste immédiatement, puis on conclut à tort que l’annuaire n’a pas pris le changement alors que l’hôte sert encore de vieilles données SSSD.

Le cinquième concerne l’utilisabilité réelle de la session. L’authentification réussit, mais la création du répertoire personnel, le shell ou le comportement PAM rendent la première connexion inutilisable.

Les arbitrages à poser avant d’automatiser avec Ansible ou AWX

Avant d’industrialiser cette jointure, il faut trancher clairement plusieurs points.

Faut-il utiliser des attributs POSIX gérés centralement ou le mapping SSSD.

Faut-il référencer les identités en noms courts ou en noms pleinement qualifiés.

Tous les comptes du domaine doivent-ils pouvoir ouvrir une session, ou seulement des groupes dédiés.

Sudo doit-il rester local via sudoers.d ou évoluer vers une politique davantage liée à l’annuaire.

Quels précontrôles doivent obligatoirement réussir avant qu’une automatisation soit autorisée à lancer la jointure.

Un playbook de jointure sans ces décisions est souvent seulement une manière plus rapide de déployer un modèle d’identité incohérent.

Références

• Ubuntu Server Guide, intégration Active Directory avec SSSD
• Documentation Red Hat Enterprise Linux, connexion à Active Directory avec SSSD et realmd
• Documentation SSSD, configuration et diagnostic
• Documentation Microsoft sur les enregistrements SRV, les exigences DNS AD et le fonctionnement de Kerberos