(March 2018)
A simple and traditional stand-alone unix/Linux box, defines users and authenticates against the /etc/passwd file (along with /etc/shadow and /etc/group).
What are the options when that isn’t adequate to manage identity and authentication?
We consider these scenarios:
Authentication confirms an identity based on some type of credential (password, certificate, etc.). Authorization specifies the permissions and limitations of an authenticated party.
Every application maintains its own identity store, and a user must authenticate to each one.
How does Linux know which authentication mechanism to use? PAM (pluggable authentication modules) and NSS (name service switch).
PAM provides a unified, high-level API for application software independently of whatever underlying, low-level authentication mechanism the system uses.
PAM finds authentication configuration for various services in /etc/pam.d/.
(OpenBSD uses BSD Auth rather than PAM.)
NSS unifies various sources of name information and configuration data (e.g., for users, groups, hosts), like /etc/passwd, DNS, NIS, and LDAP.
The file /etc/nsswitch.conf defines the sources for such information for various services on the local system.
Each service may list several sources.
NSS queries sources in the listed order.
Functions in the C standard library access NSS to get information; this is how ls knows about users and groups, for example.
AD is the 800-pound gorilla of identity management systems. These components comprise AD:
With single sign-on a user authenticates identity with one central identity store, rather than each application maintaining its own. Most commonly, Kerberos (through a Kerberos realm or AD domain) provides the central identity store. Another option is a certificate authority in a public key infrastructure with smart cards.