Demystifying LDAP Databy Brian K. Jones
More Than You Could Ever Possibly Want to Know About LDAP Data
In response to some great feedback collected on my previous article on Demystifying LDAP, my editor has given me the okay to skip the coding and instead dive head first into explaining why the data in a directory server looks the way it does, where objectclasses and attributes come from, why an entry will have multiple objectclass attributes, and all kinds of other details that seem like minutiae until you face a problem as a developer or an administrator that you cannot solve without a solid grasp of how a directory manages data.
It's a non-trivial topic space, really. However, I believe that the content of this article evaporates all of the unnecessarily verbose theory and leaves behind something you can (I hope!) refer back to in times of need.
What Are Objectclasses?
Objectclasses are prototypes for entries that will actually exist in your directory server. The objectclass definition (which uses ASN.1 syntax) specifies which attributes may or must be used by LDAP entries declared as instances of a particular objectclass.
Get it? Let me explain it backward, in the way that most people get into LDAP: you want to store information about people. The most common attributes associated with people are:
- First name
- Last name
- Email address
- Phone numbers
- Room numbers
These attributes are great for setting up an office whitepages server that users can refer to for information about people in their office. The key now is finding out which objectclass definitions either require or allow for the use of these attributes. When I started with LDAP, I researched this by perusing the actual schema files that come with most (if not all) directory servers. These files are human-readable.
Object Class Definitions
My previous article mentioned that each user in the directory is an object which has one or more attributes. Here's the definition of the
inetOrgPerson objectclass, which is a good place to start:
objectclass ( 2.16.840.1.113718.104.22.168 NAME 'inetOrgPerson' DESC 'RFC2798: Internet Organizational Person' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 )
I'll go over each line of the entry here, but don't get flustered! Some of it will sound foreign to you until you create your first user entry.
The first line states that what follows is an objectclass definition, as opposed to an attributetype definition. The long number is the ASN.1 number assigned to the objectclass. If you create your own objectclasses, this number is significant; it's where you use your organization's IANA Enterprise Number to identify any objectclasses that you create.
NAME line should be self explanatory. It is the name that will appear in your users' entries to state that the user is of type
inetOrgPerson. This line gives you license to use any of the attributes in the objectclass definition to describe the user.
DESC line is usually a useful description that can help you use this object in a way appropriate to the intent of the definer. You don't want to use objectclasses in a completely unorthodox way, because when you reach out to others for help, they'll find themselves asking you more questions than you ask them, which is often a sign that you've gone off in the wrong direction.
SUP line is critical, and the theory is tough to describe without getting pretty verbose.
SUP is short for
SUPERIOR, and it names another objectclass from which this objectclass inherits. In this case, the superior or parent objectclass is
organizationalPerson class inherits from the
person objectclass, which inherits from an objectclass called
top. If an objectclass has no other superiors, it is always a child of the
It's an inheritance chain. You need to understand it, because some LDAP servers strictly enforce it, and if you violate it in the creation of your entries, the directory server will unceremoniously spit them back at you.
MAY line is actually a block. That block (between parentheses) contains a list, delimited with the
$ symbol, of all of the attributes that
MAY be used to describe an object declared of the type
Defining a Valid Entry
Enough chat. Here's a very simple
inetOrgPerson entry, which I hope will lend itself nicely to an expanded explanation of some of this gibberish:
dn: cn=jonesy,dc=linuxlaboratory,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson displayName: Brian K. Jones givenName: Brian sn: Jones uid: 101 mail: firstname.lastname@example.org roomNumber: 101B homePhone: 609-555-1212 title: System/Network Administrator telephoneNumber: 609-111-1111 cn: jonesy
The first line of this entry is the DN, or distinguished name. It uniquely identifies this entry across the entire directory hierarchy.
The next four lines lay out the inheritance chain that I mentioned earlier. I have the most interest in the
inetOrgPerson object, but because that inherits from
organizationalPerson, which inherits from
person, which inherits from
top, I had to name those objects here as well. I've done it starting with
top and listing the descendants in order, like a family tree. You're free to list them out of order if you like.
Pages: 1, 2