Introduction to LDAP - Part II

After deploying the basics of LDAP from the first part, now you dive into practical usage of LDAP in the wild. Some of the biggest ISPs authenticate everything they can against their LDAP trees, starting with RADIUS (Remote Authentication DIalin User Service), going over to the complete employee index, up the authentication of the firewalls and SecureID cards. Each of these LDAP trees are big. Searches take time before matches are returned. A service like RADIUS runs fast into a timeout, so think about this before you plan your LDAP tree.

The next issue worth your attention is LDAP security. By default, LDAP's only built-in features are the access lists of the slapd.conf file, where you can define read-only or write access for certain users or certain distinguished names. This strong and complex feature is fairly useful. However, you must add a extra layer of security when sending LDAP data over the wires. It is clear text per default, but TLS (transport layer security) can be used. Newer versions (many vendors ship a version < 2.0) do support TLS.

Here is an example of such an access list. In this case, the attribute userPassword may only be changed by the admin ("cn=admin" entry) or by yourself after a successful authentication.

access to attribute=userPassword

by dn="cn=admin,ou=People,dc=linux,dc=com" write

by self write

by * none

How do I convince my application to authenticate against LDAP and not a plain text file? Under Linux, there's more than one possibility. You either can hope that someone has already written a patch for the application which authenticates against LDAP or you can use PAM for this issue.

PAM, introduced (but undocumented at the beginning) in Solaris, is an abbreviation for Pluggable Authentication Modules. Nowadays, every common application uses PAM to authenticate a user. PAM in turn checks the /etc/passwd and /etc/shadow files, whether the user is allowed to login or not. PAM has an unbeaten flexibility, because the application does not have to care for the backend. The people from PADL software wrote pam_ldap, the PAM module, which connects to an LDAP database for doing authentication checks. So if your application supports PAM, you do not need to worry whether it supports authentication against LDAP. It just does it.

If you want to use pam_ldap with your pop daemon, just put these entries in your /etc/pam.d/pop file, if your pop daemon supports PAM.

auth sufficient /lib/security/pam_ldap.so

auth required /lib/security/pam_unix_auth.so try_first_pass

account sufficient /lib/security/pam_ldap.so

account required /lib/security/pam_unix_acct.so

You observed that you can handle a lot of data at a central place. Would this not be ideal for a university? You store every user in your LDAP tree, and he can login at every Linux machine on the campus with the same password and the admin does not have the hassle to sync the password files.

Until now you have learned only that you can compare passwords against an LDAP tree, but if you actually log into your Linux machine, there's much more than authentication which needs to be read out of the LDAP tree. A lot of system calls need to changed, such as all the get functions (getpwuid, getpwname, getpwent). Normally data like UID, GID, GECOS is simply taken out of the passwd file. Here again strikes a dynamic solution, which decreases trouble greatly.

It is the GNU Name Service Switch, short NSS, again shamelessly stolen from Solaris. After installing the nss_ldap package, again hacked-together PADL software, you make the following lines in your /etc/nsswitch.conf, which tell NSS also to look up everything via LDAP if it is not found in the files.

passwd: files ldap

shadow: files ldap

group: files ldap

After changing the /etc/pam.d/login file (the provided one in the pam_ldap package normally works out of the box), you are able to login at your PC, perform an ls and should get resolved UIDs even at LDAP entries. If you encounter bugs, you should recheck the config file for the NSS LDAP module, which normally is placed under /etc/ldap.conf. The most important part here is that you do comment out 'ldap_version 3' as if it is not supported fully yet, if you are using OpenLDAP.

Is this all? you might ask yourself. No, of course not. You can handle nearly everything with LDAP, user management, accounting, complete virtualdomain solutions or roaming profiles for Netscape. You can even handle your NIS data in an LDAP backend. This protocol is also used in non-Unix environments (actually it is derived from NDS, the Novell directory service) and will develop further in the future, so it is really worth a try!

URL List

http://www.openldap.org, an LDAP server was written derived from the now stopped umich-ldap.

http://www.padl.com, a LDAP specialized company. They make nss_ldap and pam_ldap available free.

http://www.ispman.org, a software to maintain your virtualhosting/LDAP solution via the Web.

http://biot.com/gq/, a graphical GTK-based LDAP browser.

http://www.rudedog.org/auth_ldap/, an apache module to authenticate against a LDAP server

http://joker.rhwd.de/doc/ISP-LDAP-HOWTO/, aimed to create a complete LDAP & Linux-based virtualhosting solution.

http://python-ldap.sourceforge.net

http://perl-ldap.sourceforge.net