Let's get like all pedantic for a moment (please put on your geek beard and pocket protector for this). LDAP--Lightweight Directory Access Protocol--is a protocol, not a database. It accesses a special kind of database that is optimized for fast reads. Use it for relatively static information, such as company directories, user data, customer data, passwords, and security keys. OpenLDAP uses the Sleepycat Berkeley DB. Having said all that, I'm not the pedant police; I'm OK with calling the whole works a database and being done with it.

LDAP is not a good choice, though, when you need fast, frequent changes--for a retail backend, for example. It's not a relational database like Oracle, mySQL, or Postgres. In fact, its structure is very different from a relational database. Rather than storing information in columns and rows, and having a rigid set of indexes and fields, data are stored in attribute type/attribute value pairs. This structure offers great flexibility in designing records. A particular user record, for example, can have new types of data added without having to re-design the entire database. Any kind of text or binary data can be stored.

An LDAP directory follows the familiar Unix filesystem structure--root directory at the top of the "tree," with sub-directories branching off. A typical design is to have a single master root directory for the company. Sub-directories are then organized by department, location, function, who's been naughty/nice--anything that works and makes sense for you. Not only is this a nice tidy way to organize the master directory, it lets you grant access permissions to specific pieces of a central data pool in a precise, controlled fashion.

The next step is distributing bits in a sensible fashion. Any individual subdirectory can be replicated elsewhere--for example, on a server in the department it belongs to. Updates from the master directory can be synchronized at whatever intervals you like, providing redundancy and faster access for users, and also placing less of a strain on the master server.

Updates can be initiated in either direction--or, if you want a reason to use buzzwords, "push" or "pull." For example, the accounting department can make updates to their directory, then push the updates to the master server--again, saving the worthy sysadmin much tedious and unnecessary labor. This also conserves bandwidth and system resources.

What's really slick about the distributed nature of LDAP is you can start small. You can implement an LDAP directory in a limited way, testing and getting the hang of it, and then easily scale upwards and migrate more functions to it at your leisure.

Next: Of ACIs and ACLs »