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.
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.
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 -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: email@example.com 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
$ 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.
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.
Return to O'Reilly SysAdmin