getent queries Name Service Switch (NSS) databases—the same view applications get via glibc: local files, LDAP/SSSD, mDNS, DNS for hosts, and more. Prefer it over cat /etc/passwd when directory services or nsswitch plugins are in play.
Syntax
getent[options] database [key ...]
Common Databases
Database
Purpose
passwd
Users
group
Groups
shadow
Shadow passwords (privileged)
hosts
Host lookup
ahosts / ahostsv4 / ahostsv6
getaddrinfo-style
services
Service name ↔︎ port
protocols
Protocol names
networks
Network names
aliases
Mail aliases (if used)
ethers
Hardware addresses (rare)
Common Options
Option
Description
-s SERVICE
Force NSS service
-i
Case insensitive where supported
Key Use Cases
Confirm a user exists in LDAP/SSSD, not only locally
Script portable account lookups
Debug host resolution order (files/dns)
Map service names to ports
Examples with Explanations
Users and groups
getent passwd alicegetent passwd 1000getent group sudogetent group 27
# Does this UID resolve?getent passwd 1001 ||echo'unknown uid'# Members visible via NSSgetent group developers# Compare file vs NSSgetent passwd alice;grep'^alice:' /etc/passwd ||true# nsswitch insightcat /etc/nsswitch.conf
Notes & Pitfalls
Empty result means “not found in any configured source,” not necessarily “query error.”
shadow access is restricted; applications should use proper auth APIs.
Host lookups follow nsswitch.conf—may never touch DNS if files hits first.
Enumerating all LDAP users with bare getent passwd can be huge or disabled—don’t DoS your directory.
2026-relevant notes
SSSD/FreeIPA/Azure AD-ish integrations still show up through NSS; getent is the smoke test.
For DNS-only questions use dig/resolvectl; getent hosts includes non-DNS sources.
Containers often have minimal passwd; UIDs from the host may not resolve by name inside.
Related Commands
id — UIDs/GIDs for a user
passwd / usermod — local account changes
dig / resolvectl — pure DNS
getent vs cat /etc/passwd — NSS is authoritative for apps