It depends on what flavor of
pam_ldap we're talking about. You didn't mention an OS, but from the
libnss-ldapd I can gather that we're talking about some flavor of Debian.
libpam-ldapd are two separate beasts and both implement pam_ldap.so. The ldapd flavor has a dependency on nslcd (not
libnss-ldapd), which can be used without enabling the NSS component. I don't recall if nslcd has a hard dependency for
libnss-ldapd, but even so it will only get referenced if you add "ldap" to
/etc/nsswitch.conf. You needn't worry about it somehow doing something with NSS behind your back.
At this point you're probably wondering what the difference is (and why people would bother with the added dependency), so here's a freebie:
- PADL's pam_ldap module (
libpam-ldap) isn't actively developed. Nothing new and interesting will ever happen with it.
- Lack of daemon comes with a price: there is no way for library to share connections or state. Every invocation of the library must spin up its own unique LDAP connection and tear it back down. The primary strength of
libpam-ldapd (and sssd for that matter) are that the backend daemon can handle the actual LDAP connection and keep a running state regarding its reachability.
libpam-ldapd has at least one situational feature that is not present in either sssd or the other PAM module.
The inclusion of a daemon is more of a sticking point when you are using the NSS module, because every single program having to independently time out on reaching the LDAP server is less than ideal and why I envy every younger Linux admin who has never had to learn that the hard way.
So there you go: you can avoid NSS integration, and you can avoid the nslcd daemon depending on the module you choose. The implementation strategy is up to you.