AddThis Social Bookmark Button

Print

Demystifying LDAP
Pages: 1, 2

A Closer Look at LDAP Data

It's extremely important when learning about LDAP and how it deals with data to separate the structure (or topology) of the data from the definitions of the objects themselves.



Simply, the structure of LDAP data is a hierarchical collection of objects. Objects can represent anything from people to printers and take their places within the hierarchy using whatever logic you like.

Objects?

Yes, objects. Each object has a list of attributes associated with it that describe that particular object. When you add or delete an object, make a request for an object, or change the value of an object's attribute, you do so solely using the LDAP protocol. In short, LDAP exists to manipulate or fetch data about objects.

Hierarchical?

The layout of the data in an LDAP directory is the Directory Information Tree (DIT). You can customize it to the needs of your organization, but it's still a hierarchical tree structure. This tree is not dissimilar to a typical filesystem; there's a "top" or "root" directory, under which are high-level objects (directories in a filesystem). Those help you to categorize the lower level objects that you're really interested in (in a filesystem, these are the files themselves).

Suppose you want to store information about people using a hierarchical collection of objects. Viewing things as a filesystem, you could create a /People directory, and under that, create a file--/People/jonesy. That file contains attribute name and value pairs to describe "jonesy." One attribute might be "firstname," with a value of "Brian." Save the file, and create a new one for each person. Eventually, you have a filesystem that looks something like:

/People
    jonesy
    mary
    tom
    jane

Of course, your organization might have slightly different needs. Because the structure of the DIT is completely up to you, you might choose something more like:

/People
    /Engineering
        jonesy
        mary
    /Accounting
        tom
        jane
    /IT
        fred
        mark
    /Groups
        mygroup
        yourgroup

Notice that, of course, I can have more than one high-level object, representing a different type of object I want to store data about. In this case, I've stored information about People and Groups. I can also have as many subtrees as I wish, arranged in any order I want.

A Peek at a Person

Just to whet your appetite, here's a quick look at a request for a "person" object. It's actually a fake account entry from our departmental LDAP server that I've changed to look like a typical "person" object that systems use to authenticate users. The request comes from a Linux workstation running the OpenLDAP client utility ldapsearch.

$ ldapsearch -x '(uid=ajonesy)'

dn: cn=ajonesy,ou=People,dc=cs,dc=princeton,dc=edu
    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: posixAccount
    objectClass: inetLocalMailRecipient
    objectClass: shadowAccount
    objectClass: jabberUser
    cn: ajonesy
    uid: ajonesy
    uidNumber: 30406
    homeDirectory: /u/ajonesy
    sn: Jones
    givenName: Brian
    roomNumber: 101B
    displayName: Brian Jones
    facsimileTelephoneNumber: 1113
    gecos: Brian K. Jones, GUEST, 6080
    mail: ajonesy@cs.princeton.edu
    telephoneNumber: 6080
    loginShell: /bin/bash
    gidNumber: 931
    description: GUEST
    labeledUri: http://www.cs.princeton.edu/~ajonesy

The output format is LDAP Data Interchange Format (LDIF). As you can see, LDIF is a way to make pointy-haired bosses recoil in fear at what amounts to key-value pairs. The very first line in the entry is the dn (distinguished name). The value of that attribute uniquely identifies this object among all of the objects in the directory. After that are a list of objectclass attributes, each having a different value. What those values point to are objectclass definitions which exist in human-readable schemas that the server daemon has read. The definitions of the objectclasses consist mainly of a list of attribute definitions, followed by a statement saying "if an object is of this objectclass, it MUST have these attributes, and it MAY also have these attributes."

Schemas get only slightly more complicated than that if you want to create your own objects or entire schemas. For most, just understanding that using an objectclass implies the use of certain attributes will do just fine.

Lest you think that all of this data must necessarily come at you in the form of a whole object and nothing else, there are a couple of quick notes to make. First, notice that there's no userPassword attribute in the above output. That isn't because I've sanitized the output, it's because the user account used to perform the search that returned this object doesn't have sufficient rights to see this user's password. Second, I could alter my search command to return, say, only ajonesy's roomNumber attribute:

$ ldapsearch -x '(uid=ajonesy)' roomNumber
dn: cn=ajonesy,ou=People,dc=cs,dc=princeton,dc=edu
roomNumber: 101B

You can see how this is likely to dramatically reduce the amount of time needed to retrieve, say, the room numbers for the 3,000 people in your Los Angeles headquarters.

Stay Tuned!

This article has just scratched the surface of LDAP, but hopefully by now you're better able to visualize your directory service and its data. The next part will take a closer look at the definition of objects that live in the directory themselves, and how to create and access objects and their attributes with code.

Brian K. Jones is an infrastructure architect, and system/network/database administrator, and co-author of Linux Server Hacks, Volume Two .

Return to O'Reilly SysAdmin