More about Directory Server and OpenDS Margin Notes

To get started with LDAP, you first need to know what a directory is. A directory is a specialized list that lets you quickly look up information about the things the directory references. For example, a telephone directory is an alphabetic list of people and organizations with phone numbers, and often addresses, too. A corporate directory is a database of people, network resources, organizations, and so forth. The corporate database probably holds not just phone numbers, but also other information like email addresses, employee and department numbers, and application configuration data. The corporate directory is managed by a directory server, which takes requests from client applications and serves them back directory data from the database.

LDAP, Lightweight Directory Access Protocol, provides a standard language that directory client applications and directory servers use to communicate with one another about data in directories. LDAP applications can search, add, delete and modify directory data. LDAP is a lightweight version of the earlier DAP, Directory Access Protocol, used by the International Organization for Standardization X.500 standard. DAP gives any application access to the directory through an extensible and robust information framework, but at a high administrative cost. DAP does not use the Internet standard TCP/IP protocol, has complicated directory naming conventions, and generally requires a big investment. LDAP preserves most features of DAP at lower cost. LDAP uses an open directory access protocol running over TCP/IP and uses simplified encoding methods. LDAP retains the X.500 standard data model and can support millions of entries for a comparatively modest investment in hardware and network infrastructure.

LDAP directories differ from relational databases. In LDAP, you do not look data up in tables. Instead, you look data up in trees, similar to the tree you get if you diagram the contents of a file system. The data is not in rows and columns, but in what are called entries. These entries are much like entries in the phone book. Entries may even actually contain phone numbers. Here is a text representation of an LDAP entry.

dn: uid=bjensen, ou=People, dc=example,dc=com
cn: Barbara Jensen
cn: Babs Jensen
sn: Jensen
givenname: Barbara
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
ou: Product Development
ou: People
l: Cupertino
uid: bjensen
mail: bjensen@example.com
telephonenumber: +1 408 555 1862
facsimiletelephonenumber: +1 408 555 1992
roomnumber: 0209
userpassword: hifalutin

An LDAP entry is composed of attributes and their values. At the outset of the text representation you see the DN, Distinguished Name, uid=bjensen, ou=People, dc=example,dc=com. The DN is a distinguished name, because it distinguishes the entry from all others in the directory. You also see attributes like CN, Common Name, which takes values Barbara Jensen and Babs Jensen. You further see attributes like SN, surname, which takes the value Jensen, and mail, which takes the value bjensen@example.com.

You also see some objectClass attribute values. The objectClass attribute tells you what other attribute types the entry can have. Object class definitions are found in directory schema. Schema specify all the known object classes and attribute types available for entries in the directory. You can add schema definitions to LDAP directories, making the LDAP entries easily extensible.

When you want to look up something in a directory, you typically know the values of one of the attributes. By analogy, if you want to look up a phone number, you already know the name of the person or organization whose telephone number you want. If you are looking up a phone number, you also probably have some idea where the person or organization is located. The same is the case for LDAP directories. You typically need to have some idea where the entry is located.

For example, assume you want to look up Barbara Jensen’s phone number in the LDAP directory holding the entry shown previously. You need to know one of the attributes. In this case, you know Barbara’s name. You also need to know approximately where her entry is located. If you know that she is in the directory at Example.com, and that the root of their tree starts at dc=example,dc=com, that is enough.

There are GUI tools out there for LDAP lookups, but many systems also have a command called ldapsearch. You guessed it, ldapsearch is for searching LDAP directories. Here is an ldapsearch command that searches the entries under dc=example,dc=com for entries having common name Barbara Jensen.

$ ldapsearch -b dc=example,dc=com "(cn=Barbara Jensen)"

The argument to the -b option is the base DN for the search. By default, the ldapsearch command searches through all the entries in the tree below the base DN. The "(cn=Barbara Jensen)" is called the filter, because it tells me the criteria for filtering through the entries found under the base DN. If you have set everything up correctly, your search returns something very much like the entry shown above, except that you almost surely will not see the user password attribute and its value. You can also narrow the search results to see only the DN of the entry and the telephone number. You do this by adding the attribute or attributes you want returned after the filter.

$ ldapsearch -b dc=example,dc=com "(cn=Barbara Jensen)" telephoneNumber

If everything works as expected, this search returns a partial entry.

dn: uid=bjensen, ou=People, dc=example,dc=com
telephonenumber: +1 408 555 1862

Stay tuned for more.