Linux et Active Directory : diagnostiquer les pannes SSSD qui apparaissent après la jointure

Une jointure Active Directory réussie ne garantit pas une intégration Linux stable. La commande realm join peut terminer sans erreur, le compte machine peut apparaître dans l’OU attendue, puis les problèmes commencent plus tard : utilisateurs introuvables, authentification intermittente, groupes incomplets, lenteurs au login, cache SSSD incohérent ou erreurs Kerberos difficiles à lire.

Le scénario traité ici démarre après la jointure. La machine Linux est censée authentifier des utilisateurs AD via SSSD. Le DNS pointe vers les contrôleurs de domaine, l’heure est synchronisée et la configuration semble correcte. L’objectif est de diagnostiquer méthodiquement les pannes qui apparaissent en exploitation.

Repartir des couches de base

SSSD dépend de plusieurs couches. Si le DNS, le temps ou Kerberos sont instables, SSSD ne pourra pas compenser. Il faut donc éviter de commencer par vider le cache ou modifier sssd.conf au hasard. La première étape consiste à vérifier les prérequis depuis la machine concernée.

hostname -f
realm list
resolvectl status || cat /etc/resolv.conf
timedatectl

nslookup _ldap._tcp.example.local
nslookup _kerberos._tcp.example.local

klist -k
kinit user@example.local
klist

Si les enregistrements SRV ne répondent pas correctement, le problème est probablement DNS. Si kinit échoue alors que le mot de passe est bon, il faut regarder le temps, le realm, les contrôleurs de domaine ou le compte. Si Kerberos fonctionne mais que les utilisateurs ne remontent pas via NSS, SSSD devient le sujet principal.

Vérifier ce que SSSD voit vraiment

Les commandes id, getent et sssctl donnent une vision plus utile qu’un simple test de login. Elles permettent de savoir si l’utilisateur est trouvé, si les groupes sont résolus et si le domaine est en ligne.

systemctl status sssd --no-pager
sssctl domain-status example.local
sssctl user-checks user@example.local
getent passwd user@example.local
id user@example.local

Un domaine offline dans SSSD peut venir d’un contrôleur indisponible, d’un problème DNS, d’un port filtré ou d’une erreur Kerberos. Un utilisateur introuvable peut venir d’un filtre LDAP, d’un use_fully_qualified_names, d’un mapping d’attributs ou d’un cache ancien.

Lire les logs avec le bon niveau

Les logs SSSD sont souvent trop silencieux par défaut. Il est possible d’augmenter temporairement le niveau de debug pour comprendre une panne. Cette modification doit rester contrôlée, car les logs peuvent devenir volumineux et contenir des informations sensibles.

[domain/example.local]
debug_level = 6

[sssd]
debug_level = 6

[nss]
debug_level = 6

[pam]
debug_level = 6

Après modification, redémarrer SSSD et reproduire le problème avec un utilisateur précis. Il faut ensuite revenir au niveau normal. L’objectif n’est pas de laisser la production en debug, mais de capturer une trace lisible.

systemctl restart sssd
id user@example.local
journalctl -u sssd --since "10 minutes ago"
ls -l /var/log/sssd/
tail -n 200 /var/log/sssd/sssd_example.local.log

Les messages importants concernent souvent la découverte LDAP, le choix du contrôleur de domaine, les erreurs Kerberos, les timeouts ou les refus d’accès liés aux filtres.

Comprendre le cache avant de le supprimer

Vider le cache SSSD peut résoudre un symptôme, mais cela ne doit pas devenir une réponse automatique. Le cache explique certains comportements : un groupe récemment modifié n’apparaît pas, un utilisateur désactivé reste visible, ou une erreur persiste malgré une correction côté AD. Il faut savoir si l’incident est un problème de cache ou une panne de communication.

sssctl cache-status
sss_cache -u user@example.local
sss_cache -E
systemctl restart sssd

sss_cache -E invalide tout le cache. C’est utile pour un test, mais en production il faut comprendre pourquoi le cache contenait une information gênante. Sinon l’incident reviendra après le prochain changement AD.

Vérifier le compte machine

Le compte machine Linux dans Active Directory peut poser problème après rotation de mot de passe, déplacement d’OU, restauration de VM ou snapshot. Une machine clonée sans précaution peut aussi partager une identité AD avec une autre. Les symptômes ressemblent parfois à une panne SSSD alors que le trust machine est cassé.

realm list
adcli testjoin
net ads testjoin 2>/dev/null || true
klist -k | head

# Selon distribution et outillage disponible
adcli info example.local

Si adcli testjoin échoue, il faut traiter le compte machine avant de modifier les filtres SSSD. Rejoindre de nouveau le domaine peut être nécessaire, mais seulement après avoir compris l’impact sur l’OU, les groupes autorisés et les fichiers de configuration.

Conclusion

Les pannes SSSD après jointure Active Directory se diagnostiquent mieux quand on sépare DNS, temps, Kerberos, compte machine, résolution NSS et cache. Modifier sssd.conf sans cette séparation produit souvent des corrections fragiles.

Un bon runbook tient en quelques commandes : vérifier les SRV DNS, tester Kerberos avec kinit, contrôler le domaine avec sssctl, lire les logs au bon niveau, invalider le cache de manière ciblée et tester le compte machine. Avec cette méthode, la jointure Linux AD reste exploitable au-delà du premier succès de realm join.