These classnotes are depreciated. As of 2005, I no longer teach the classes. Notes will remain online for legacy purposes

LDAP01/LDIF Basics

Classnotes | LDAP01 | RecentChanges | Preferences

The LDAP Interchange Format (LDIF), defined in RFC 2849, is a standard text file format for storing LDAP configuration information and directory contents. In its most basic form, an LDIF file is:
  • A collection of entries separated from each other by blank lines
  • A mapping of attribute names to values
  • A collection of directives that instruct the parser how to process the information

We will focus on the first two characteristics for now, and return to the fourth later on in the course.

LDIF files are most often used to import new data into your directory or make changes to existing data. They can also be used to backup entire LDAP directories to external text files and to "jump-start" replication servers.

The data in LDIF files must obey the schema rules of your LDAP directory. You can think of the schema as a data definition for your directory. Every item which is added or changed in the directory is checked against the schema for correctness. A schema violation occurs if the data does not correspond to the existing rules.

Before we proceed, let's get ourself a simple directory information tree (DIT) for a given entry:

How do we go about defining this in an LDIF file? First, we start by defining the topmost entry, namely the distinguished name (DN) dc=odyssey,dc=com:

 # LDIF listing for DN for Odyssey, Inc.
 dn: dc=odyssey,dc=com
 objectClass: domain
 dc: odyssey

So what can we observe about this entry?

  • Comments in an LDIF file, as with most other UNIX configuration files, begin with a pound (#) character at the beginning of a new line.
  • Attributes are listed on the left-hand side of the colon (:), and values are on the right. The colon character is separated from the value by a space.
  • The dn attribute uniquely identifies the distinguished name of the entry.

Distinguished Names and Relative Distinguished Names

It is important to realize that the full DN of an entry does not actually have to be stored as an attribute within that entry, it can be generated on the fly as needed. This is analogous to how a filesystem is organized, and it may help to relate it to this in order to fully understand it. A file or directory does not store the absolute path itself from the root of the filesystem. Instead, it keeps track of relative paths.

If the DN is like the absolute path between the root of a filesystem and a file, then the relative distinguished name (RDN) is like the filename itself.

Now, this visualization breaks down when we realize that the RDN itself can be made up of multiple attributes. This is similar to a compound index in a relational database system in which two or more fields are used in combination to generate a unique index key.

As multivalued RDN example, let's pretend that this ficticious company, Odyssey Inc., has two Brenda Smalls working for it. One works in Sales and the other works in PR. Now suppose that the entries for these employees have a common parent. Neither the common name (cn) nore the organizational unity (ou) attribute is unique in its own right. However, both can be used in combination to generate a unique RDN:

 # Example of two entries with multivalued RDN
 dn: cn=Brenda Smalls+ou=Sales,dc=odyssey,dc=com
 cn: Brenda Smalls
 ou: Sales
 ....

 dn: cn=Brenda Smalls+ou=PR,dc=odyssey,dc=com
 cn: Brenda Smalls
 ou: PR
 ....

In the multivalued RDN, the plus character (+) separates the two attribute values used to form the RDN. While using multivalued RDNs has its place, it should not be used excessively. Often, they can be avoided with better namespace design. For example, the previous example could have been avoided by creating organizationalUnits (ou) in the directory for both Sales and PR.

Escaping Special Characters

As we have seen, there are a number of special characters for use in an LDIF file. A sampling of special characters (including ones which we haven't seen yet) follows:
  • # at the beginning of a line
  • Comma (,), plus (+), double quote ("), backslash (\), angle brackets (< or >), semicolons (;)

What happens if you want to use any of these characters in your attribute values? For example, what if you have an entry for a "Dr. Carl, DDS" and you wish to have the ", DDS" preserved?

To escape the special attributes of these characters you preceed them with a backslash (\), so the cn for "Dr. Carl, DDS" would be

 cn: Dr. Carl\, DDS


Classnotes | LDAP01 | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited September 20, 2003 9:03 pm (diff)
Search:
(C) Copyright 2003 Samuel Hart
Creative Commons License
This work is licensed under a Creative Commons License.