Linux : centraliser les comptes avec LDAP, SSSD et PAM

Le commissaire aux comptes est revenu. Au lab 2, vous aviez verrouillé le compte de ktraore, l'agent de quai parti depuis des mois. Son rapport préliminaire tient en une phrase : ktraore est verrouillé sur srv-erp, mais actif sur srv-quai, avec les droits d'administration, et l'auditeur s'y est connecté avec un mot de passe trouvé dans les notes de l'ancien prestataire. Le groupe a un annuaire central depuis l'an dernier, que personne n'a fini de raccorder. La contre-visite a lieu vendredi. Vous commencez par cartographier le parc : un même salarié qui porte deux numéros différents d'un serveur à l'autre, et un compte local qui hérite en silence des groupes de l'annuaire. Vous apprenez à lire un annuaire LDAP, ses branches, ses entrées et ses filtres, en chiffrant la connexion et en vous présentant avec un compte qui ne peut que lire. Puis vous désactivez l'ancien salarié dans l'annuaire, et vous découvrez que la révocation centrale ne vaut rien tant qu'un compte local porte le même nom. Le lab va là où s'arrêtent les tutoriels. Raccorder un serveur avec SSSD, NSS et PAM, et comprendre pourquoi SSSD refuse de démarrer avec un fichier lisible par tous. Migrer les comptes locaux vers l'annuaire sans qu'aucun fichier ne change de main, en sachant pourquoi un chown lancé sur tout le disque volerait leurs fichiers aux comptes d'un conteneur. Constater qu'un ordre mal choisi rouvre la porte qu'on croyait fermée. Couper l'annuaire, voir qui peut encore entrer grâce au cache, et tester le compte de secours avant d'en avoir besoin. Enfin, écrire la procédure de départ que l'auditeur lira vendredi. L'annuaire est un vrai OpenLDAP, et le serveur du quai un conteneur avec son propre SSSD : vous travaillez sur un petit parc, depuis un seul terminal. À la fin, de vraies tentatives de connexion vérifient vos révocations, comme le fera l'auditeur, et le résultat compte pour votre classement.