The Ten-Minute LDAP Tutorial: Appendix B - Perl for System Administrationby David N. Blank-Edelman
This excerpt is from Perl for System Administration.
Perl for System Administration is aimed at all levels of administrators on the Unix, Windows NT, or MacOS platforms. Assuming only a little familiarity with Perl, it explores the pockets of administration where Perl can be most useful, including filesystem management, user administration, directory services, database administration, log files, and security and network monitoring. Perl for System Administration is for anyone who needs to use Perl for administrative tasks and needs to hit the ground running.
The Lightweight Directory Access Protocol (LDAP) is one of the pre-eminent directory services deployed in the world today. Over time, system administrators are likely to find themselves dealing with LDAP servers and clients in a number of contexts. This tutorial will give you an introduction to the LDAP nomenclature and concepts you’ll need when using the material in Chapter 6.
The action in LDAP takes place around a data structure known as an entry. Figure 2.1 is a picture to keep in mind as we look at an entry’s component parts.
An entry has a set of named component parts called attributes that hold the data for that entry. To use database terms, they are like the fields in a database record. In Chapter 6 we’ll use Perl to keep a list of machines in an LDAP directory. Each machine entry will have attributes like name, model, location, owner, etc.
Besides its name, an attribute consists of a
type and a set of values
that conform to that type. If you are storing employee information,
your entry might have a
phone attribute that has a
telephoneNumber. The values of this
attribute might be that employee’s phone numbers. A type also
has a syntax that dictates what kind of data can
be used (strings, numbers, etc.), how it is sorted, and how it is
used in a search (is it case-sensitive?).
Each entry has a special attribute called objectClass. objectClass contains multiple values that, when combined with server and user settings, dictate which attributes must and may exist in that particular entry.
Let’s look a little closer at the objectClass attribute for a moment because it illustrates some of the important qualities of LDAP and allows us to pick off the rest of the jargon we haven’t seen yet. If we consider the objectClass attribute, we notice the following:
- LDAP is object-oriented
Each of the values of an objectClass attribute is a name of an object class. These classes either define the set of attributes that can or must be in an entry, or expand on the definitions inherited from another class.
Here’s an example: an objectClass in an entry may contain the string
residentialPerson. RFC2256, which has the daunting title of “A Summary of the X.500(96) User Schema for use with LDAPv3,” defines the
residentialPersonobject class like this:
residentialPerson ( 184.108.40.206 NAME 'residentialPerson' SUP person STRUCTURAL MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) )
This definition says that an entry of object class
residentialPersonmust have an
lattribute (short for locality) and may have a whole other set of attributes (
postOfficeBox, etc.). The key part of the specification is the
SUP personstring. It says that the superior class (the one that
residentialPersoninherits its attributes from) is the
personobject class. That definition looks like this:
person ( 220.127.116.11 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
So an entry with object class
cn(common name), and
l(locality) attributes and may have the other attributes listed in the
MAYsections of these two RFC excerpts. We also know that
personis the top of the object hierarchy for
residentialPersonsince its superior class is the special abstract class
In most cases, you can get away with using the pre-defined standard object classes. If you need to construct entries with attributes not found in an existing object class, it is usually good form to locate the closest existing object class and build upon it, like
- LDAP has its origins in the database world
A second quality we see in objectClass is LDAP’s database roots. A collection of object classes that specify attributes for the entries in an LDAP server is called a schema. The RFC we quoted above is one example of an LDAP schema specification. We won’t be addressing the considerable issues surrounding schema in this book. Like database design, schema design can be a book topic in itself, but you should at least be familiar with the term “schema” because it will pop up later.
- LDAP is not limited to storing information in strict tree structures
One final note about objectClass to help us move from our examination of a single entry to the larger picture: our previous object class example specified
topat the top of the object hierarchy, but there’s another quasi-superclass worth mentioning:
aliasis specified, then this entry is actually an alias for another entry (specified by the
aliasedObjectNameattribute in that entry). LDAP strongly encourages hierarchical tree structures, but it doesn’t demand them. It’s important to keep this flexibility in mind when you code to avoid making incorrect assumptions about the data hierarchy on a server.
So far we’ve been focused on a single entry, but there’s very little call for a directory that contains only one entry. When we expand our focus and consider a directory populated with many entries, we are immediately faced with the question that began this chapter: How do you find anything?
The stuff we’ve discussed so far all falls under what the LDAP specification calls its “information model.” This is the part that sets the rules for how information is represented. But for the answer to our question we need to look to LDAP’s “naming model,” which dictates how information is organized.
If you look at Figure 2.1, you can see we’ve discussed all of the parts of an entry except for its name. Each entry has a name, known as its Distinguished Name (DN). The DN consists of a string of Relative Distinguished Names (RDNs). We’ll return to DNs in a moment, but first let’s concentrate on the RDN building blocks.
An RDN is composed of one or several attribute name-value pairs. For
cn stands for “common name”) could be
an RDN. The attribute name is
cn and the value is
Neither the LDAP nor the X.500 specifications dictate which attributes should be used to form an RDN. They do require RDNs to be unique at each level in a directory hierarchy. This restriction exists because LDAP has no inherent notion of “the third entry in the fourth branch of a directory tree” so it must rely on unique names at each level to distinguish between individual entries at that level. Let’s see how this restriction plays out in practice.
Take, for instance, another example RDN:
cn=Robert Smith. This is probably not a good RDN choice, since there
is likely to be more than one Robert Smith in an organization of even
moderate size. If you have a large number of people in your
organization and your LDAP hierarchy is relatively flat, name
collisions like this are to be expected. A better entry would combine
two attributes, perhaps
l=Boston. (Attributes in RDNs
are combined with a plus sign.)
Our revised RDN, which appends a locality attribute, still has
problems. We may have postponed a name clash, but we haven’t
eliminated the possibility. Furthermore, if Smith moves to some other
facility, we’ll have to change both the RDN for the entry
and the location attribute in the entry. Perhaps
the best RDN we could use would be one with a unique and immutable
user ID for this person. For example, we could use that
person’s email address so the RDN would be
uid=rsmith. This example should give you a taste
of the decisions involved in the world of schemas.
Astute readers will notice that we’re not really expanding our focus; we’re still puttering around with a single entry. The RDN discussion was a prelude to this; here’s the real jump: entries live in a tree-like structure known as a Directory Information Tree (DIT) or just directory tree. The latter is probably the preferred term to use, because in X.500 nomenclature DIT usually refers to a single universal tree, similar to the global DNS hierarchy or the Management Information Base (MIB) we’ll be seeing later when we discuss SNMP.
Let’s bring DNs back into the picture. Each entry in a directory tree can be located by its Distinguished Name. A DN is composed of an entry’s RDN followed by all of the RDNs (separated by commas or semi-colons) found as you walk your way back up the tree towards the root entry. If we follow the arrows in Figure 2.2 and accumulate RDNs as we go, we’ll construct DNs for each highlighted entry.
In the first picture, our DN would be:
cn=Robert Smith, l=main campus, ou=CCS, o=Hogwarts School, c=US
In the second, it is:
uid=rsmith, ou=systems, ou=people, dc=ccs, dc=hogwarts, dc=edu
ou is short for organizational unit,
o is short for organization,
stands for “domain component” à la DNS, and
c is for country (Sesame Street notwithstanding).
An analogy is often made between DNs and absolute pathnames in a filesystem, but DNs are more like postal addresses because they have a “most specific component first” ordering. In a postal address like:
|288 St. Bucky Avenue|
|Anywhere, MA 02104|
you start off with the most specific object (the person) and get more vague from there, eventually winding up at the least specific component (the country or planet). So too it goes with DNs. You can see this ordering in our DN examples.
The very top of the directory tree is known as the directory’s suffix, since it is the end portion of every DN in that directory tree. Suffixes are important when constructing a hierarchical infrastructure using multiple delegated LDAP servers. Using an LDAPv3 concept known as a referral, it is possible to place an entry in the directory tree that essentially says, “for all entries with this suffix, go ask that server instead.” Referrals are specified using an LDAP URL, which look similar to your run-of-the-mill web URL except they reference a particular DN or other LDAP-specific information. Here’s an example from RFC2255, the RFC that specifies the LDAP URL format:
 It is called
tree-like rather than just tree
alias object class we
mentioned earlier allows you create a directory structure that is not
strictly a tree (at least from a computer-science,
If you enjoyed this excerpt, buy a copy of Perl for System Administration