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.
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 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/.