Understanding the LDAP Data Interchange Format

What is LDIF?

LDIF is short for LDAP Data Interchange Format.

When working with directory servers on a daily basis, it is important to know how the LDAP data format, works. This is the data type that describes the directory and directory entries in a text format. It is used to populate the directory and to automate addition of large amounts of entries all at once. The LDIF format is also used to modify existing directory entries.

For this reason, most LDAP command line tools rely on LDIF for input and/or output.

LDAP administrators also have to rely on LDIF a great deal, because LDAP is really only a database. All LDAP does for you is storing information, using the LDIF format.

Most LDAP (server) packages include a set of layouts that you can use to map your organization's data on, but you will notice rather sooner than later that the default schemes never quite fit reality. The same goes for the standard tools: they are very useful for administrative use, but you wouldn't want your users to have to read through this document, for instance, before they are able to authenticate themselves on your network using an LDAP-enabled account.

In order to manage LDAP sensibly, and to configure the database and integrate LDAP-enabled services, you'll have to make yourself very familiar with the LDIF format. That is why we include a brief introduction to LDIF. You are encouraged to read the man page, man ldif (on Linux systems) or check out the RFC describing the LDIF format..

The basic format of an LDIF entry is as follows:

dn: <distinguished_name>
<attribute>: <value>
<attribute>: <value>
<attribute>:: <base-64-value>
<attribute>: < <URL>
...

Values for attributes may be UTF-8 or base 64 encoded data, or an URL (Universal Resource Locator) may be provided to locate the actual value for an attribute. Lines beginning with a hash mark (#) are ignored, lines beginning with a single space are interpreted as the continuation of the previous line. Multiple values for the same attribute are specified on separate lines.

LDIF example

A typical set of entries defining users looks like this:

dn: cn=Peter Petersen
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Peter Petersen
modifytimestamp: 0Z
postalAddress: Verkortingstraat 10
l: Leuven
postalCode: B-3000
                                                                                
dn: cn=Jan Jansen
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Jan Jansen
modifytimestamp: 0Z
postalAddress: Naamse Vest 174
l: Leuven
postalCode: B-3000

And these are a couple of entries defining hosts on the network:

# entry-id: 34
dn: cn=stella,ou=hosts,dc=example,dc=com
cn: stella
ipHostNumber: 192.168.13.103
objectClass: top
objectClass: iphost
creatorsName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
modifiersName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
createTimestamp: 20031127062446Z
modifyTimestamp: 20031127062446Z
nsUniqueId: 490fe981-1dd211b2-80bdd1dd-c2b06d66

# entry-id: 35
dn: cn=loburg,ou=hosts,dc=example,dc=com
cn: loburg
ipHostNumber: 192.168.13.105
objectClass: top
objectClass: iphost
creatorsName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
modifiersName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
createTimestamp: 20031127062515Z
modifyTimestamp: 20031127062515Z
nsUniqueId: 6cd32f81-1dd211b2-80bdd1dd-c2b06d66

The LDIF file is made up of one or more directory entries, separated by a blank line. Each entry consists of the following items:

  • An optional entry ID.

  • A required distinguished name (dn).

  • One or more object classes (at least one is required).

  • Multiple attribute definitions, as required by the object classes.

Distinguished names should be normalized: components are separated by commas, no spaces between components.

The object class “inetOrgPerson” is defined in RFC2798. Here you can read more about possible attributes and advised usage.

Additional object classes may be defined in the schema your LDAP server is using.

Binary data

Binary data can be represented using base 64 encoding. This type of data is identified by the “::” symbol. An example would be the statement

jpegPhoto:: <encoded image>

In addition to binary data, also values beginning with a semicolon (;) or a space, and any non-ASCII data must be specified using base 64 encoding.

Solaris systems come with a conversion tool, ldif, that you can find in /usr/ds/<version>/bin/slapd/server/.