Understand PAM and NSS
It helps to break things down like this in your head:
NSS - A module based system for controlling how various OS-level databases are assembled in memory. This includes (but is not limited to)
passwd
,group
,shadow
(this is important to note), andhosts
. UID lookups use thepasswd
database, and GID lookups use thegroup
database.PAM - A module based system for allowing service based authentication and accounting. Unlike NSS, you are not extending existing databases; PAM modules can use whatever logic they like, though shell logins still depend on the
passwd
andgroup
databases of NSS. (you always need UID/GID lookups)
The important difference is that PAM does nothing on its own. If an application does not link against the PAM library and make calls to it, PAM will never get used. NSS is core to the operating system, and the databases are fairly ubiquitous to normal operation of the OS.
Now that we have that out of the way, here's the curve ball: while pam_ldap is the popular way to authenticate against LDAP, it's not the only way.
- If
shadow
is pointing at the ldap service within/etc/nsswitch.conf
, any authentication that runs against the shadow database will succeed if the attributes for those shadow field mappings (particularly the encrypted password field) are present in LDAP and would permit login.- This in turn means that
pam_unix.so
can potentially result in authentication against LDAP, as it authenticates against the shadow database. (which is managed by NSS, and may be pointing at LDAP)
- This in turn means that
- If a PAM module performs calls against a daemon that in turn queries the LDAP database (say,
pam_sss.so
, which hookssssd
), it's possible that LDAP will be referenced.