Using LDIF
can use the LDAP Data Interchange Format (LDIF) to import and export entries into and out of your local directory. For example, when you perform a search of your directory using the ldapsearch command line utility, the resulting output is in LDIF format. When you create entries using ldapmodify, you use a form of LDIF called LDIF update statements.
If you are using a directory server to manage your users and groups, see the Directory Server Administrator's Guide for more complete information on using LDIF with the directory server.
The LDIF format
The LDAP Data Interchange Format (LDIF) is used to represent directory entries in text form. The basic form of an LDIF entry is:
[<id>]
dn: <distinguished name>
objectClass: <object class>
objectClass: <object class>
...
<attribute type>:<attribute value>
<attribute type>:<attribute value>
...
Note
Only the DN and at least one object class definition are required. Also required
are any attributes required by the object classes that you define for the entry.
All other attributes and object classes are optional. You can specify object
classes and attributes in any order. The object classes and attributes that you
can use with your directory server are defined by the directory server's schema.
The following table describes the LDIF fields shown in the previous definition:
Continued lines
When you specify LDIF, you can break and continue a line by indenting the continued portion of the line by exactly one space. For example, the following two statements are identical:
dn: cn=Jake Lupinski, ou=Accounting, o=Ace Industry, c=US
dn: cn=Jake Lup
inski, ou=Accoun
ting, o=Ace Industr
y, c=US
Creating databases using LDIF
You can create a directory database using LDIF. This method is useful when you are creating an entire directory database, or when you are importing entries from another directory service application.
In general, to create a database using LDIF, you:
- Create an ASCII file containing the entries you want to add in LDIF format. See "Creating LDIF entries" for more information. Make sure each entry is separated from the next by an empty line.
- Begin each directory in the database with the topmost, or the root, entry. The root point of the directory must represent a suffix you have set for your server. For example, if your server has the suffix:
- As you proceed with your directory creation, make sure that you create an entry representing a branch point before you create new entries under that branch. For example, if you want to place an entry in a Marketing and an Accounting subtree, then create the branch point for those subtrees before creating entries within those subtrees:
- Create the database from the LDIF file using the procedure described in "Importing a directory from LDIF".
o=Ace Industry, c=USthen the very first entry in your directory must be:
dn: o=Ace Industry, c=US
dn: o=Ace Industry, c=US
<list of attributes and object classes>
dn: ou=Marketing, o=Ace Industry, c=US
<list of attributes and object classes>
...
Marketing subtree entries.
...
dn: ou=Accounting, o=Ace Industry, c=US
<list of attributes and object classes>
...
Accounting subtree entries.
...
Creating LDIF entries
This section describes specifically how to create a series of entries using LDIF to describe the people in your organization. For the general format of the LDIF entry, refer to "The LDIF format".
Note that you can, and will, create many more types of entries than are discussed here. However, organizational person entries are the most common type of entry that you will store in your directory, so this is the kind of entry used for these examples. For a look at the most common type of object classes used in a directory server, see the object class discussion in Appendix A.
You can import LDIF formatted files into your directory using the procedure described in "Importing a directory from LDIF". You can export your directory to LDIF by using the procedure described in "Exporting a database to LDIF".
Specifying entries for an organizational person
The most common type of entry that you will include in your directory will describe a person within your organization. The LDIF you specify to define an organizational person should appear as follows:
dn: distinguished name
The following defines each aspect of the LDIF-formatted entry:
cn: common name
sn: surname
list of optional attributes
...
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
dn: distinguished name
Specifies the DN for the entry. DNs are described in "Distinguished names".
A DN is required.
cn: common name
Specifies the common name for the person. That is, the full name
commonly used by the person. For example, cn: Bill Anderson. A
common name is required.
sn: surname
Specifies the person's surname, or last name. For example,
sn: Anderson. A surname is required.
objectClass: top
Specifies the top object class. This object class specification is optional.
Some older LDAP clients will require the existence of object class top
during search operations.
objectClass: person
Specifies the person object class. This object class specification should be
included because many LDAP clients will require the existence of object
class person during search operations for a person or an organizational
person.
objectClass: organizationalPerson
Specifies the organizationalPerson object class. This object class
specification should be included because some LDAP clients will require
the existence of object class organizationalPerson during search
operations for an organizational person.
objectClass: inetOrgPerson
Specifies the inetOrgPerson object class. The inetOrgPerson object
class is recommended for the creation of an organizational person entry
because this object class includes the widest range of attributes. For a list of
the attributes you can use with an object class, refer to Appendix A, "Object
classes and attributes" in the online documentation that comes with the
server.
LDIF file example
The following example shows an LDIF file that contains three organizational person entries:
dn: cn=June Rossi, ou=accounting, o=Ace Industry, c=US
cn: June Rossi
sn: Rossi
givenName: June
mail: rossi@aceindustry.com
userPassword: {sha}KDIE3AL9DK
telephoneNumber: 2616
roomNumber: 220
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
dn: cn=Marc Chambers, ou=manufacturing, o=Ace Industry, c=US
cn: Marc Chambers
sn: Chambers
givenName: Marc
mail: chambers@aceindustry.com
userPassword: {sha}jdl2alem87dlacz1
telephoneNumber: 2652
roomNumber: 167
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
dn: cn=Robert Wong, ou=manufacturing, o=Ace Industry, c=US
cn: Robert Wong
cn: Bob Wong
sn: Wong
givenName: Robert
givenName: Bob
mail: bwong@aceindustry.com
userPassword: {sha}nn2msx761
telephoneNumber: 2881
roomNumber: 211
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson