LDAP Introduction

The Big Picure

LDAP is basically a specialized database. Some of the characteristics are:

• It consists of entries organized in a hierarchy.
• It favors reading over writing.
• Every entry has a primary key called the Distinguished Name (DN).
• It’s notion of schema is much more flexible than that of a RDBMS.

You typically use an LDAP directory to store information about entities like people, offices, machines and that sort. But you could equally well store most other relatively static information in there, e.g. information about books or movies or cars. Anything you can describe by a set of attributes.

For a more thorough and hand-holding explanation, read <a href=”http://ldapman.org/articles/intro_to_ldap.html”>Michael Donnelly’s article. It’s pretty good. The guy knows what he’s talking about.

What Is LDAP

LDAP is a protocol. Actually, it’s the Lightweight Directory Access Protocol. Lightweight, as opposed to its ancestor, the X.500 DAP protocol.

Being a protocol, you can implement it any which way you like, as long as the protocol is adhered to. There is a number of implementations to choose from, including the free OpenLDAP or <a href=”http://oradoc.photo.net/ora816/network.816/a77230/toc.htm”>Oracle’s LDAP server that runs on top of an Oracle database.

As for the client implementation, the OpenLDAP distribution includes client libraries that you can link into your C programs to LDAP-enable your application. Java 1.2 comes with <a href=”http://java.sun.com/products/jndi/docs.html”>JNDI, which includes client support for LDAP.

A word of warning: there are two versions currently out there; LDAPv2 and LDAPv3. LDAPv3 solves some important problems, including more secure authentication and transport security like SSL. The problem is that we’re still waiting for the open-source implementation of this from OpenLDAP. You can’t just assume that you can use a v3 client against a v2 server. They’re quite different.

Don’t forget where to find the standards. <a href=”http://ldapman.org”>Michael Donnelly has collected <a href=”http://ldapman.org/ldap_rfcs.html”>links to all the relevant RFCs.

What’s In A Directory

A directory contains objects, or entries. Each entry has a Distinguished Name (DN), that acts as the entry’s primary key. The entry could be me:

uid=lars, ou=persons, dc=arsdigita, dc=com

Or it could be a machine:

cn=ls.arsdigita.com, ou=machines, dc=arsdigita, ou=com

Or just about anything else. The entry itself will have a bunch of attributes holding the information. They could look like this:

dn: uid=lars, ou=persons, dc=arsdigita, dc=com
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: arsdigitaPerson
uid: lars
cn: Lars Pind
cn: Lars Holger Pind
sn: Pind
givenName: Lars
title: Developer
telephoneNumber: 718-387-0115
jpegPhoto:  (my portrait)
mail: lars@pinds.com
loginshell: /bin/bash
userPassword: {crypt}X5/DBrWPOQQaI
homeDirectory: /home/lars
uidNumber: 10
gidNumber: 10

The objectclass stuff is used to say something about what other attributes MUST or MAY be present. The other attributes contains various information we want to store about the user. The same attribute can have multiple values, as with the cn attribute above.

The Structure of the Directory

The directory structure is hierarchical. The tree structure will be familiar to every programmer (take DNS or the Unix file systems as other examples). Look at the DN again:

uid=lars, ou=persons, dc=arsdigita, dc=com

It shows the hierarchical structure: The top-level node here is dc=com. Then comes dc=arsdigita, dc=com hanging off of that. Then, under that is ou=persons, dc=arsdigita, dc=com, and under that is where you’ll find me.

As is customary with trees, you can also use the abbreviated form of a DN, called a Relative Distinguished Name (RDN). This is the leftmost part of the DN, and is relative to it’s position within the hierarchy.

Every LDAP server also has a base. For ArsDigita, the base of our directory would probably be dc=arsdigita, dc=com. Everything under this node is managed by out directory server, everything else in the world is (potentially) managed by some other directory server. This divides the LDAP name space between LDAP servers, like is done with DNS.

So in other words, the DN is composed of:

• The base DN: dc=arsdigita, dc=com
• The position relative to the base: ou=persons
• The RDN of the entry: uid=lars

How you structure this, your Drectory Information Tree (DIT), and what you choose for you base DN, is up to you. You can get a feel for the concerns by <a href=”http://developer.netscape.com/docs/manuals/isdirdeploy/chaptera.htm#1012406”>reading about what Netscape does (or thought they’d do as of October 1998). Like with all such cases, you should think about what needs you have and will have in the future.

One thing most people seem to agree on by now is, that using your DNS domain as your base DN as in dc=arsdigita, dc=com is a very good idea.

What’s the Schema

The schema definition of LDAP is a little messy, albeit very flexible. The LDAP schema, as with all database schemas, is the definition of what can be stored in the directory. The basic thing in an entry is an attribute, like givenName. Each attribute is associated with a syntax that determines what can be stored in that attribute (plain text, binary data, encoded data of some sort), and how searches against them work (case sensitivity, for example). An objectclass is a three-tuple, consisting of (must have, required, may have), saying what other attributes can or should be present.

There is a standard core of schema definitions (object classes, attributes and syntaxes), and you can define your own to suit your particular needs. Most every organization will want to do that.

Object Classes

Let’s take an example object class definition:

objectclass person requires sn cn allows userPassword
telephoneNumber seeAlso Description

To create an object (entry) of a specific class, you add an attribute to your entry that says objectclass: person, or whatever object class you want to use. When you do that, you must also add the other required attributes. You can have an object be an instance of multiple classes, simply by adding more objectclass attributes.

The object classes is furthermore arranged into an inheritance hierarchy, such that, e.g. objectclass: organizationalPerson is a subclass of objectclass: person. The caveat here is that LDAP doesn’t really deal with the inheritance (this is one of the things pulled out from X.500 to make it lightweight). What it does instead is that the definition of organizationalPerson requires that objects of this class also includes person. This is the reason my example entry given above contains four different values for the objectclass attribute.

Attributes

An attribute definition just contains a name, possibly an abbreviated name, and the syntax the attribute uses. It can also contain a description. It can say something like:

attribute commonName cn cis

This defines the attribute commonName, abbreviated as cn, syntax cis (case-insensitive string).

Syntaxes

Some common syntaxes include:

• bin: binary
• ces: case-sensitive (case exact) string
• cis: case-insensitive (case ignore) string
• tel: telephone number string
• dn: distinguished name string

The Standard Schema

Exactly what object classes are defined and how they’re defined is a bit unclear to me. Apparantly, the <a href=”http://ldapman.org/ldap_rfcs.html”>RFCs collectively define a bunch of them, although some are outdated. The best resource for information about this is the <a href=”http://www.hklc.com/ldapschema/”>LDAP schema repository where you can browse object classes, attributes, syntaxes and matching rules.

Defining Your Own

It’s pretty straight-forward to define your own attributes and object classes with OpenLDAP. Here’s an excerpt from the <a href=”http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos=0&manpath=OpenLDAP+1.2-Release”>man pages for slapd.conf:

        <B>attribute</B> &lt;<B>name</B>&gt; <B>[</B>&lt;<B>name2</B>&gt;<B>] { bin | ces | cis | tel | dn }</b>
              Associate  a  syntax  with  an  attribute  name. By
              default, an attribute is  assumed  to  have  syntax
              <B>cis</B>.   An  optional alternate name can be given for
              an attribute. The possible syntaxes and their mean-
              ings are:
                      <B>bin</B>    binary
                      <B>ces</B>    case exact string
                      <B>cis</B>    case ignore string
                      <B>tel</B>    telephone number string
                      <B>dn</B>     distinguished name

       <B>objectclass</B> &lt;<B>name</B>&gt; <B>requires</B>&lt;<B>attrs</B>&gt; <B>allows</B> &lt;<B>attrs</B>&gt;
              Define  the schema rules for the object class named
              &lt;name&gt;.  These are used  in  conjunction   with the
              schemacheck option.

The schemacheck option? I hear you ask. With OpenLDAP you can turn off the checks for whether the attributes required by the object class is in fact present. Huh.

References

• ldapman.org has some great introductory articles.
  
  
• The LDAP Schema Repository is indispensible for figuring out what to stuff in there and how.
  
  
• A System Administrator’s View of LDAP by Bruce Markey from Netscape is a very clear introduction to our use of it (note how his layout style resembles ours :-P).
  
  
• Jeff Hodge’s LDAP roadmap and faq which seems to be the authoritative guide to links. Unfortunately, it’s so badly organized that it’s almost not worth it. Beware that this guy is way confused about “versioning” his web site, so you may very well find yourself reading something out-of-date by more than a year! Check the “Last updated” on top of the page and try the other versions.
  
  
• <a href=”http://dir.yahoo.com/Computers_and_Internet/Communications_and_Networking/Protocols/LDAP__Lightweight_Directory_Access_Protocol_/”>The Yahoo! category has fine links.
  
  
• Here’s something about the Abstract Syntax Notation used in specifying the protocol.
  
  
• <a href=”http://renoir.vill.edu/~cassel/netbook/ber/node1.html”>Here’s something about the Basic Encoding Rules defining what the protocol looks like on the wire.
  
  
• More about BER, this time LDAP-specific