Identifier la source d'identité qui répond pour un utilisateur : getent, id, nsswitch.conf et sss_cache

Objectif

Déterminer quel service de noms répond pour un nom d'utilisateur ou un groupe donné sur un hôte Linux, et purger une entrée obsolète du cache SSSD, lorsque les fichiers locaux et un service d'annuaire (LDAP/SSSD/AD) sont tous deux en jeu.

Prérequis

Accès en lecture à /etc/nsswitch.conf ; sss_cache présent si l'hôte utilise SSSD (installé avec sssd-common/sssd-tools, comme pour les jonctions AD via realmd/SSSD).

Étapes

1. Lire l'ordre de résolution des comptes : les lignes passwd:, group: et shadow: de /etc/nsswitch.conf énumèrent, dans l'ordre, les sources à interroger. Sous Debian/Ubuntu, libnss-sss place sss après files ; les profils authselect de la famille RHEL ont placé sss avant ou après files selon la version, il faut donc lire la ligne réelle plutôt que de présumer. La page de manuel décrit ce format de liste de sources par base de données.
2. Résoudre un nom précis exactement comme le ferait n'importe quel programme du système : getent passwd alice parcourt les sources configurées dans l'ordre et affiche la première correspondance, ou rien si aucune ne correspond. C'est la méthode de référence pour vérifier « ce système voit-il cet utilisateur ? », contrairement à un grep direct sur /etc/passwd, qui ne montre que la source locale.
3. Vérifier à quoi ressemble une identité entièrement résolue, y compris les appartenances à des groupes qui peuvent provenir d'une autre source que le compte principal : id alice, que la page de manuel décrit comme affichant les informations d'utilisateur et de groupes pour l'utilisateur indiqué, avec tous les identifiants de groupe grâce à -G, --groups. C'est utile lorsqu'une appartenance à un groupe ajoutée côté annuaire n'apparaît pas.
4. Si SSSD fait partie des sources et qu'une modification effectuée côté annuaire (nouvelle appartenance à un groupe, compte désactivé) n'apparaît pas, la cause est souvent le cache de SSSD plutôt que l'ordre de résolution : sss_cache -E (en root) fait expirer toutes les entrées en cache de chaque domaine configuré, de sorte que la recherche suivante interroge à nouveau le fournisseur au lieu de renvoyer un enregistrement obsolète. sss_cache -u <user> cible un seul utilisateur au lieu de tout le cache.
5. Confirmer la correction : relancer getent passwd alice (ou id alice) et vérifier le champ ou l'appartenance à un groupe qui était obsolète.

Résultat attendu

getent passwd <name> et id <name> reflètent l'état actuel de l'annuaire dès la première recherche suivant sss_cache -E, sans qu'il soit nécessaire de redémarrer le service sssd. Les sessions déjà ouvertes conservent leur ancienne liste de groupes jusqu'à la prochaine connexion de l'utilisateur.

Limites et base de vérification

getent passwd sans nom ne liste normalement que les utilisateurs locaux, car SSSD n'énumère pas les utilisateurs de l'annuaire par défaut ; il faut toujours interroger un nom précis. getent ne rapporte que ce que NSS résout : si files précède sss dans nsswitch.conf et qu'une entrée locale obsolète ou conflictuelle existe pour le même nom, c'est elle qui l'emporte et aucune donnée de l'annuaire n'est jamais consultée pour ce nom. sss_cache -E fait expirer les entrées du cache afin que la requête suivante soit vérifiée auprès du fournisseur ; la commande ne contacte pas elle-même le fournisseur, donc une recherche doit la suivre pour voir les données actualisées. Et si le fournisseur est injoignable à ce moment-là, SSSD peut tout de même servir la valeur en cache (désormais marquée comme périmée), selon la configuration de son cache hors ligne.