From AdminWiki

PAM and NSS are the two services you have to mess around with if you need more than passwd and shadow. Both use backends as their data sources, and these usually have seperate configuration files.

Name Switch Service

NSS is, basically, the glibc resolver. It can resolve lots of different stuff for you: hosts, networks, protocol names, users, groups, etc. Data for the resolver can be provided by more than one backend, but not all backends make sense for every data type ("database" in NSS-speak).

/etc/nsswitch.conf defines which backends glibc will use to resolve a particular data type. The backends are distributed in form of Shared Objects, carrying the names /lib/libnss_*.so* . Which databases are available is documented in man nsswitch.conf. Changes to nsswitch.conf will require a restart of the affected applications.

Caching

nscd provides the Name Service Caching Daemon, which caches the output of the resolver backends. Running nscd gets you a big speed improvement, but burns you when debugging NSS problems. In this case just stop nscd, your applications will revert to non-caching mode automatically. If you see strange behaviour or old data it's a good idea to restart nscd.

Troubleshooting Multicast DNS packets

Newer glibcs ship with support for MDNS - multicast DNS. Useful if you have a home network, no working DNS, probably a .local domain and a recent Linux distro or OS X systems (Windows?). If you 'do' have a working DNS for your .local domain (e.g. company lan), this gets quite annoying (slow, unneeded network traffic, etc).

The solution: remove mdns from the hosts: line in nsswitch.conf. Reboot, and you should have gotten rid of that mdns stuff. Sadly, some particular versions of glibc distributed by some vendors (SuSE) have mdns support built-in and it can't be disabled. Rumour has it, that there are now updated rpms which fix this.

Pluggable Authentication Modules

While NSS provides the lookup and mapping of your users, PAM will provide the login handling, authentication and session setup.

PAM is configured per-application, and applications will have to support it explicitly (most daemons now support pam, vsftpd NOT by default). It's config files are /etc/pam.conf (rather obsolete) and /etc/pam.d/{service name}.

Debian provides a set of files called common-* which get included in every service configuration file. Modify them if you want to setup server-wide PAM. RedHat does not provide such a thing, but most configurations can be set up using the authconfig program.

PAM backends are distributed as Shared Object files, located in /lib/security/pam_*.

Upgrade Troubles

Be careful when upgrading glibc and/or pam/nss backends: it's easy to shoot yourself.

Usually running applications will have to be restarted after upgrading one of libc or backends, due to the nature of the integration of libc with the backends (libc dyna-links the backends at runtime and sometimes releases them - which will cause problems when it loads them again but are different versions then).