AddThis Social Bookmark Button


Demystifying LDAP Data

by 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.113730.3.2.2
    NAME 'inetOrgPerson'
    DESC 'RFC2798: Internet Organizational Person'
    SUP organizationalPerson
    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.

The 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.

The 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.

The 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. The 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 top objectclass.

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.

The 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 inetOrgPerson.

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
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

Next Pagearrow