Getent sous Linux : retrouver un compte même s’il ne vient pas de /etc/passwd

Vous lancez id alice sur un serveur, le compte existe dans l’annuaire de l’entreprise, mais grep alice /etc/passwd ne renvoie rien. Avant de conclure à un compte absent, regardez la vue que Linux utilise réellement.

getent interroge les bases déclarées dans NSS, le mécanisme qui peut combiner les fichiers locaux, SSSD, LDAP ou un autre service d’identité. Vous pouvez ainsi savoir si le système résout le compte, le groupe et son identifiant numérique, sans modifier la configuration.

Pourquoi /etc/passwd ne donne pas toujours la réponse

Sur une machine locale, /etc/passwd contient souvent tous les comptes attendus. Sur un serveur relié à LDAP ou Active Directory via SSSD, ce fichier garde les comptes locaux, alors que les comptes distants arrivent par NSS.

La commande getent passwd passe par NSS pour résoudre la base passwd avec les sources et l’ordre définis dans /etc/nsswitch.conf.

grep '^passwd:' /etc/nsswitch.conf
grep '^group:' /etc/nsswitch.conf

Une ligne comme passwd: files systemd sss indique que Linux consulte d’abord les fichiers locaux, puis le service système et enfin SSSD. Ne copiez pas cet ordre dans votre configuration : il dépend de la distribution et de l’intégration déjà en place.

Chercher un compte avec getent

Utilisez le nom de connexion exact, sans afficher toute la base. Sur un annuaire volumineux, getent passwd seul peut produire une sortie longue et inutile.

getent passwd alice
getent passwd 10542

Si le compte est résolu, la sortie suit le format habituel : nom, marqueur de mot de passe, UID, GID, champ descriptif, répertoire personnel et shell. Un compte LDAP ou SSSD peut donc apparaître ici alors qu’il reste absent de /etc/passwd.

Aucune sortie signifie seulement que NSS ne trouve pas cette entrée avec sa configuration actuelle. Ce résultat ne corrige ni une panne LDAP, ni un cache SSSD, ni une faute dans le nom demandé.

Contrôler le groupe et l’identité effective

Un compte visible ne garantit pas que ses groupes sont corrects. Contrôlez la base group, puis laissez id afficher les groupes calculés pour cet utilisateur.

getent group projet-admin
id alice

id alice doit afficher l’UID, le GID principal et les groupes supplémentaires attendus. Si le compte ressort avec getent passwd alice mais pas avec id alice, gardez les deux sorties et consultez les journaux de SSSD ou du service d’identité concerné.

Cette lecture aide les outils qui demandent à NSS de résoudre une identité, comme id ou un service configuré avec un annuaire.

Le guide pour lister les utilisateurs sous Linux reste utile pour inventorier les comptes locaux. Ici, la question est différente : le système reconnaît-il l’identité au moment où un service doit l’utiliser ?

Chercher d’abord, réparer ensuite

Je garderais getent comme premier contrôle avant de redémarrer SSSD, de vider un cache ou de modifier nsswitch.conf. La commande est en lecture seule et donne le même point de vue que beaucoup de programmes Linux.

• Comparez le compte demandé avec la ligne passwd: de /etc/nsswitch.conf.
• Lancez getent passwd utilisateur et getent group groupe.
• Contrôlez les groupes calculés avec id utilisateur.
• Si une entrée manque, relevez le journal du service d’identité avant de changer sa configuration.

Sur un poste uniquement local, getent confirmera souvent le contenu de /etc/passwd. Sur un serveur relié à un annuaire, cette différence évite de supprimer ou de recréer un compte qui existe déjà côté NSS.

La page getent(1) de man7 détaille les bases disponibles et la recherche par clé. Si le compte doit être créé localement, utilisez plutôt la procédure Useradd sous Linux après avoir écarté une identité distante.