Security

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.

The nscd service comes as part of glibc, which means every Linux distribution will provide it. It is also extremely simple to set up. Once installed, edit the /etc/nscd.conf file to look similar to this:

        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.

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

Editor's Picks