You run id alice on a server, the account exists in the company’s directory, but grep alice /etc/passwd returns nothing. Before concluding that an account is missing, check the view that Linux is actually using.
getent queries the databases declared in NSS, the mechanism that can combine local files, SSSD, LDAP, or another identity service. This way you can determine if the system resolves the account, the group, and its numeric identifier, without altering the configuration.
Why /etc/passwd doesn’t always provide the answer
On a local machine, /etc/passwd usually contains all expected accounts. On a server connected to LDAP or Active Directory via SSSD, this file retains local accounts, while remote accounts are retrieved through NSS.
The getent passwd command goes through NSS to resolve the passwd database with the sources and order defined in /etc/nsswitch.conf.
grep '^passwd:' /etc/nsswitch.conf
grep '^group:' /etc/nsswitch.confA line like passwd: files systemd sss indicates that Linux first checks local files, then the system service, and finally SSSD. Do not copy this order into your configuration: it depends on the distribution and existing integration.
Searching for an account with getent
Use the exact login name, without displaying the entire database. On a large directory, getent passwd alone can produce long and unnecessary output.
getent passwd alice
getent passwd 10542If the account is resolved, the output follows the usual format: name, password placeholder, UID, GID, descriptive field, home directory, and shell. An LDAP or SSSD account can therefore appear here while being absent from /etc/passwd.
No output only means that NSS cannot find this entry with its current configuration. This outcome does not fix an LDAP failure, an SSSD cache issue, or a mistake in the requested name.
Check the group and effective identity
A visible account does not guarantee that its groups are correct. Check the group database, then let id display the calculated groups for that user.
getent group projet-admin
id aliceid alice should display the UID, primary GID, and expected additional groups. If the account comes up with getent passwd alice but not with id alice, keep both outputs and check the logs of SSSD or the relevant identity service.
This reading aids the tools that request NSS to resolve an identity, such as id or a service configured with a directory.
The guide to list users on Linux remains useful for inventorying local accounts. Here, the question is different: does the system recognize the identity at the moment a service needs to use it?
Search first, fix later
I would keep getent as the first check before restarting SSSD, clearing a cache, or modifying nsswitch.conf. The command is read-only and provides the same viewpoint as many Linux programs.
- Compare the requested account with the line
passwd:from/etc/nsswitch.conf. - Run
getent passwd userandgetent group group. - Check the calculated groups with
id user. - If an entry is missing, check the identity service log before changing its configuration.
On a purely local workstation, getent often confirms the contents of /etc/passwd. On a server connected to a directory, this difference prevents deleting or recreating an account that already exists on the NSS side.
The page getent(1) from man7 details the available databases and key-based searches. If the account needs to be created locally, use the procedure Useradd on Linux after ruling out a remote identity.