Importing LDIF Data

If the directory you are importing the LDIF data to already contains entries that match some of those in your LDIF file, you will getentry already exists

errors on those entries. In this case, look for an option of the import utility that will continue importing entries even if errors occur. The import utility should

directory. This allows you to easily verify whether all entries have successfully been added.

4.7.5.1 Moving Data Between Homogeneous Directories When moving data between directories, there are several factors that influence the complexity of the task. From an LDAP perspective, these factors include the hardware and software platform of the server, the vendor supplying the directory software, and the implementation or support of LDIF. Beginning with the simplest, these factors present the following interesting combinations of source and target directory:

• Homogeneous: same vendor, product, and version (same or different hardware platform)

• Heterogeneous: different vendor, product, and version (both LDAP, supporting LDIF)

• Legacy data: from non-LDAP directory or database

The differences and difficulties involved in moving data between platforms tend to be minor compared to those introduced when moving data between directories from different vendors.

When homogeneous directories are involved, the process of moving data from one server to another follows the basic steps of:

1. Export the data from the source directory server to an LDIF file. 2. Transport the LDIF file to the target directory server system. 3. Import the data from the LDIF file into the target directory.

Before beginning this data migration process, compare the schema of the source and target directories. If the source directory server has definitions of attribute types or object classes that are not included in the target directory’s schema, you should update its schema to add them to ensure that the target directory can accept all the data exported from the source.

The IBM SecureWay Directory server includes the command line utilities db2ldif to export data to an LDIF file and ldif2db to import from an LDIF file.

The method used to update the schema in the target directory is vendor, product, and release dependent (for example, the IBM eNetwork LDAP Directory V2.1 and the newer IBM SecureWay Directory V3.1 do not use the same schema file syntax).

The Web browser-based administration GUI (UNIX and Windows NT

platforms only, see 7.2, “The Administrator Graphical User Interface” on page 166) also provides these export/import interfaces. When moving data

between two instances of the directory server, the steps might look like: 1. Export the data on system A:

db2ldif -o dirdata.ldif

2. Move the LDIF (text, not binary) file to system B, for example, using FTP. 3. Import the data on system B:

ldif2db -i dirdata.ldif

4.7.5.2 Moving Data Between Heterogeneous Directories

The process of transferring data between LDAP directories can be more difficult if the two directories are from different vendors. This is due to differences in access control models, which have not yet been standardized for LDAP, as well as other features that may or may not be identical.

As an example of the sort of problems that might be encountered, let’s take a closer look at moving data from a Netscape Directory Server to an IBM SecureWay Directory Server. The definition of access control is quite different between the two directories. It is different enough that it would not be

practical to attempt to transfer the access controls along with the data. Instead, you will need to strip out the access control information from the LDIF file, load the data into the IBM SecureWay Directory, and then use the administrative interfaces to redefine the appropriate access controls. When the data is dumped to an LDIF file from the Netscape directory, the access controls (if any were defined) will appear asACIattributes with the entries. These lines of the file should be removed prior to loading the data to the IBM SecureWay Directory directory. For example, on a UNIX platform, these lines can be very easily removed using the following command: # grep -v “^ACI” filename.ldif > newname.ldif

Examples of ACL information in LDIF form for each of the directory implementations follow.

Data exported in LDIF format will be in readable format. Entries in the directory that were protected by controlling access will be exported without regard to access control rights.

Example IBM SecureWay Directory ACL format: dn: cn=John Doe, ou=Austin, o=IBM, c=US objectclass: top objectclass: person objectclass: organizationalPerson cn: John Doe sn: Doe dept: abcd

aclEntry: access-id:cn=Bert Hello, ou=Austin, o=IBM, c=US:object:da:normal:rwsc:sensitive:rsc

aclEntry: group:cn=Anybody::normal:rsc

aclEntry: access-id:cn=Amy Too, ou=Austin, o=IBM, c=US:object:da:normal:rwsc:sensitive:rsc:critical:rsc aclPropagate:TRUE

entryOwner: group:cn=personnel, ou=Austin, o=IBM, c=US ownerPropagate: TRUE

inheritOnCreate: FALSE

Example Netscape Directory representation of Access Controls: dn: o=airius.com

objectClass: top

objectClass: organization

ACI: (target = "ldap:///cn=administrators,o=airius.com") (targetattr="member||uniquemember")(version 3.0; acl

"write-admingrp"; allow (write)userdn = "ldap:///uid=ssarette, o=airius.com" ||

"ldap:///uid=bjensen, o=airius.com";)

As you can see from these examples, the access control policies and representations are very different. The approach of removing and then reapplying access control will be similar when moving data from an IBM SecureWay Directory to a Netscape directory. In this case, the attributes to be removed from the (IBM SecureWay Directory) LDIF file includeaclEntry,

aclPropagate,entryOwner, andownerPropagate.

In addition to differences in access control, there may be other differences in the attributes that are valid from one server to another. Compare the schema definitions of the servers you are using. In some cases, the schema for the

• If you do not want an access ID to have permission to a particular class, do not specify the class.

• Attributes are assigned to their respective classes in the slapd.at.conf file.

target directory can be modified to add attribute definitions from the schema of the originating directory server. In other cases, there may be attributes related to extended features that are not part of the LDAP standard and, therefore, cannot be added to the target server. In those cases, it may make more sense to strip those particular attributes out of the LDIF file as was done for the ACI attributes.

4.7.5.3 Migrating Data to LDAP from Legacy Directories/Databases Lastly, if you have data in legacy databases or directories (not based on LDAP), you may well wish to migrate your data to an LDAP directory. The use of a well-defined, text-based interchange format facilitates development of tools to import data from legacy systems. A fairly simple set of tools, for example, written in UNIX shell script language, can convert a database of personnel information into an LDIF file, which can then, in turn, be imported into the LDAP directory regardless of the internal database representation the target directory server uses.