Authentication caching with nscd

*Edited post to clarify issues with original wording. | 10-31-2007, 1:40 ET

Distributed authentication is increasingly popular as home networks add more computers and business networks continue to expand. Using a central authentication system such as LDAP or NIS with other technologies like Kerberos has become somewhat of a standard in large networks.

On the server side, Linux has been able to adapt easily and even lead with ease-of-use when becoming a part of such networks or controlling them. Combining OpenLDAP, Samba, and Kerberos, you can rival the features of the more expensive Active Directory on Windows implementations. On the client side, PAM modules like pam_ldap and others allow for easy integration of the Linux client in such networks.

An equally important service on the client side is nscd: the Name Service Caching Daemon. Nscd caches authentication lookup information on the local machine. Services consult the local nscd cache, if available, for user/group lookups prior to other directories, be it LDAP or NIS, or something else altogether. This makes using a Linux laptop in a distributed authentication network very easy. I can continue to use the obtained user/group information provided by the central authentication server (with the exception of Kerberos, if implemented), even if the laptop is not connected to the network.

Caching user/group information for other desktops or servers in the network is ideal because it reduces the amount of traffic over the network for doing simple user/group lookups. Every time you execute ls -al, the username mapped to the uid that the files belong to must be looked up; if you do this every few minutes, you'll have many connections to the central authentication server for nothing more than indicating that the user name "joe" is associated with uid 512.


        server-user             nscd
        debug-level             0
        reload-count            unlimited
        paranoia                no

        enable-cache            passwd          yes
        positive-time-to-live   passwd          3600
        negative-time-to-live   passwd          20
        suggested-size          passwd          211
        check-files             passwd          yes
        persistent              passwd          yes
        shared                  passwd          yes

        enable-cache            group           yes
        positive-time-to-live   group           3600
        negative-time-to-live   group           60
        suggested-size          group           211
        check-files             group           yes
        persistent              group           yes
        shared                  group           yes

        enable-cache            hosts           no

Once the file has been edited, start the nscd service (usually as simple as issuing service nscd start). The above configuration tells nscd to cache group and passwd entries and to let them persist for 3600 seconds, or one hour. On a laptop that routinely leaves the office for long stretches of time, you will want to adjust the positive-time-to-live times appropriately -- perhaps to 604800 (60*60*24*7 or 7 days).

Enabling host caching is generally not a very good idea; a caching DNS server is a much better, and safer, implementation.

Once nscd has started and has a few cached entries under its belt -- if you are already logged in and then disconnect from the network -- you will still be able to continue using the system just as if you were on the network -- apart from accessing shares and printers, utilizing Kerberos, and performing new login sessions. This is largely due to the fact that those shares would not be available, as well as the Kerberos service, and that nscd does not cache authentication information such as passwords. As such, new login attempts would fail because nscd does not cache the equivalent of shadow passwords, which would allow new logins to succeed. However, established login sessions will continue to function as normal.




Quotes from the official SAMBA guides contraindicate the use of nscd. Of course, the guide is on how to setup winbind along with ldap/kerberos. Since you work for Redhat, i am surprised Redhat's own sssd / freeIPA was not mentioned. sssd says it can cache credentials for offline logon. Please clear up the confusion. [quote] NSCD Problem Warning Warning Do not under any circumstances run nscd on any system on which winbindd is running. If nscd is running on the UNIX/Linux system, then even though NSSWITCH is correctly configured, it will not be possible to resolve domain users and groups for file and directory controls. [/quote] [quote] Make absolutely certain that you disable (shut down) the nscd daemon on any system on which winbind is configured to run. [/quote]


After recent patching of nscd I found it has created a new group namely NSCD. Any body has any idea why it is created?


I'm about to be forced to turn NSCD on so that I can interface to a Oracle DB and they say to turn NSCD on to cache the host. Why is it not a good idea ? Thanks, Denis


Maybe I don't understand something here, but authentication takes place at the Directory server for LDAP, there is nothing cached in the way of password hashes. In an LDAP implementation, I've not seen any *nix variant behave well when the LDAP service is unavailable, even with nscd running (which it should be default when running any federated name service!). Help me here.


You're right. It doesn't cache the actual credentials (passwords); it caches the authenticated information (as opposed to authentication information). IOW, nscd caches the passwd/group entries (uid, gid info), but not the actual passwords (i.e. shadow entries). My bad. This one should have been written a little clearer. My apologies on that one.