AddThis Social Bookmark Button


Demystifying LDAP

by Brian K. Jones

If you've been struggling to understand what LDAP is and how it can be useful to you without picking up a 1,000-page tome, look no further. LDAP is great for some problems, pretty good for some others, and completely inappropriate for yet another batch of problems. In this first part of a series on understanding just what LDAP is, I hope I can help make LDAP easier to deal with by explaining, in English, what LDAP is and what it is good at. After that, looking at the data and writing code will be much easier.

Definition and Components

LDAP stands for Lightweight Directory Access Protocol, which is to say that, by definition, LDAP is a protocol, and nothing else. However, the protocol exists to perform operations on data, and is really pretty useless without it. This brings up the components that make up an LDAP deployment: client software used to send LDAP requests, the server daemon that handles incoming LDAP requests, and the back-end data store. I will refer to the last two collectively as a "directory service."

Back-end Data Storage

Of these components, the back-end data storage mechanism is the least relevant to you unless you're administering a production LDAP deployment. Developers writing code that accesses an LDAP server and end users who access a directory service via some client utility should be happy to let the protocol do the job of getting data to them without knowing anything about the back end. Adding, removing, updating, deleting, and fetching data from a directory service occurs through the LDAP protocol.

LDAP Server Daemon

The LDAP server daemon handles incoming requests for data. It uses port 389 for unencrypted and TLS-encrypted requests, and port 636 for SSL requests by default. In every LDAP product I've ever seen, open source or not, the server daemon is also responsible for determining who can perform what operations on which data, which clients can connect, and other security measures. In other words, the data is the castle, and the server daemon is the gatekeeper and the moat.

In addition to these duties, the server daemon also keeps a wealth of logging and accounting information. For example, most daemons will record the user who committed the last change to a piece of data and the date of that change.

On top of all of this, some daemons even store their configuration in the back-end data store, meaning that you can configure and manage them almost completely using LDAP itself!

The good news, if you need to deploy an LDAP service, is that the server daemon and back end almost always come in a single package from software vendors and open source projects alike. The more popular open source LDAP servers are OpenLDAP and Fedora Directory Server (FDS). On the commercial side, products include Novell's eDirectory, Sun's Java System Directory, and solutions from IBM, Computer Associates, and other heavyweights in the software arena.

What Is LDAP Used For?

An LDAP directory service stores information for use by systems as well as end users (and their various applications). Probably the most common use of LDAP is for replacing either flat-file authentication (think /etc/passwd) or legacy networked authentication (think NIS). The benefit of any networked authentication mechanism over a flat file system is clearly that it lifts the burden of having to keep files on all of your systems in sync. The benefit of LDAP over, say, NIS is (among other things) a finer-grained control over the data and how it is accessed (and by whom). You can also make encrypted connections to LDAP servers using TLS or SSL, and you never have to muck with flat file "maps" or complicated Makefiles to change the data.

Because LDAP is a transaction-based system, operations that complete successfully are immediately "live." Modern Unix-based systems (including Linux, BSD, and OS X) can rely on LDAP to get just about any information they could store in flat files or NIS, including hosts, automounter configuration, users, groups, and more. Add to that the ability to have Samba, Apache, PAM, tcpwrappers, Sendmail, and other applications talk to LDAP for authentication, aliases, and other tidbits of useful information, and you have the beginnings of a very well-integrated, easily maintained, authoritative data source for your entire infrastructure.

LDAP is also popular for use as a "white pages" directory for a department or corporation. For example, most email applications, from Mutt and Pine to Outlook, Evolution, and KMail all know how to talk to an LDAP server. This makes it very easy to, for example, tell KMail to autocomplete addresses as you type using an LDAP directory as its addressbook source instead of (or in addition to) local files.

Why Yet Another Data Store? Why Not Just Use a Database?

Why not just use a relational database? There are multiple reasons to consider LDAP instead of a relational database for certain subsets of your data. One main issue here is standardization: LDAP is a standard protocol, with published, standardized schemas available to manage data in LDAP directory services.

For example, if I were to write an authentication module for a corporate website, LDAP does away with the need to schedule a meeting with a database guru to have him explain the layout of the user database. Instead, I can just ask the LDAP administrator for a link to the published schema he uses to store user information, and code for that schema. Even better, the schema is likely to be widely used (because it is published), so there might already be some code out there that does exactly what I need, which means less time coding, and a quicker delivery time for my project.

The benefits to an open source project are even greater. When you write, for example, a portal application that you want everyone in the world to use, you have the design option of requiring users to register, storing the resulting user information in a database. Why not simply allow users to point the application at a directory server for the user information? Decent models are available from Moodle and Horde.

By using a standard schema for storing user data, you don't have to ask the user, "What does your data look like?" Instead, just have the user type in the location of the LDAP server, and the name of the subtree to search under for user information, and you're practically finished! What makes it even easier is that you don't have much of a data access API to write, and most programming languages (including Perl, PHP, Python, Ruby, and plenty of others) already have modules for talking to LDAP servers no matter what brand of LDAP server you choose. Further, because LDAP is a standard protocol, you can use one interface to talk to just about any LDAP server product on the market. No goofy database abstraction layers required!

Pages: 1, 2

Next Pagearrow