Skip Headers
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2)
B14082-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

23 Migration of Data from Other Data Repositories

This chapter explains how to migrate data from both LDAP Version 3-compatible directories and application-specific data repositories into Oracle Internet Directory.

This chapter contains these topics:

23.1 The Default Directory Structure of Oracle Internet Directory

During an Oracle Internet Directory installation, Oracle Universal Installer creates a default schema and directory information tree (DIT). This default DIT framework is described in Chapter 2, "Directory Concepts and Architecture" and in Chapter 19, "Deployment of Oracle Identity Management Realms". The framework is flexible and you can modify it to suit the needs of your deployment.

In Oracle Internet Directory 10g Release 2 (10.1.2), the following directory elements are created by default:

You can change this default identity management realm to suit your deployment requirements.

23.2 Migrating Data from LDAP-Compliant Directories

This section provides practical information for migrating data from an LDAP-compliant, third-party directory to Oracle Internet Directory. If you have a directory with an already-established structure, and you want to migrate the data from that directory into the default directory structure environment, then follow the instructions in this section.

This section contains these topics:

23.2.1 Tools

Three tools are commonly used for migrating third-party LDAP data to Oracle Internet Directory. They are:

Which tool or tools you use depends on several factors, including the size of the data you are importing and whether the data must be mapped.

23.2.1.1 bulkload

The Bulk Loading Tool, bulkload, is a command-line tool for loading a large number of entries into a directory server. It uses Oracle SQL*Loader to load the directory entries. The bulkload tool expects the input file to be in LDAP Data Interchange Format (LDIF). The bulkload tool can validate LDIF input for referential integrity, but it cannot perform any mapping or other transformation on the data.

Table 23-1, "Features of bulkload and dipassistant" lists the features of bulkload, as compared with dipassistant bootstrap. For bulkload syntax information and examples, see "Oracle Internet Directory Data Management Tools" in Oracle Identity Management User Reference.

23.2.1.2 dipassistant

The Directory Integration and Provisioning Assistant, dipassistant, is a command-line tool for administering the synchronization profiles scheduled by the Oracle directory integration and provisioning server. An administrator can use the dipassistant bootstrap operation to perform the initial migration of data between a connected directory and Oracle Internet Directory when configuring the Oracle directory integration and provisioning server to perform ongoing synchronization. You also use it for a one-time data migration, without ongoing synchronization.

The dipassistant bootstrap operation can take data either directly from a third-party LDAP-compliant directory or from an LDIF file, tagged file, or CSV file. You must provide mapping rules, either as a synchronization profile or in a configuration file.

Table 23-1, "Features of bulkload and dipassistant" lists the features of dipassistant bootstrap, as compared with bulkload. For dipassistant syntax information, configuration file properties, information about input file types, and examples, see "Oracle Directory Integration and ProvisioningTools" in Oracle Identity Management User Reference and Oracle Identity Management Integration Guide.

Table 23-1 Features of bulkload and dipassistant

Feature bulkload dipassistant

Speed

Fast

Slow

Data transfer method

SQL

LDAP

Input types accepted

LDIF file only

LDIF file, LDAP directory, tagged file, CSV file

Transforms data

No

Yes

Validates LDIF input

Yes

No


23.2.1.3 Oracle Directory Integration and Provisioning Server

Under some circumstances, an administrator might choose not to use dipassistant when configuring the Oracle directory integration and provisioning server. Once configured, the Oracle directory integration and provisioning server itself can migrate data from a connected directory to Oracle Internet Directory. You can also use the Oracle directory integration and provisioning server for a one-time data migration. For more information, see Oracle Identity Management Integration Guide.

23.2.2 Common Usage Scenarios

This section describes different scenarios for using the tools described in the "Tools" section. They include:

23.2.2.1 Scenario 1: Using an LDIF File and bulkload

When no translation is required and data is very large (500,000 or more), bulkload is the best choice for migrating data from a third-party directory to Oracle Internet Directory. It is fast and it can validate LDIF input. To use this method, you must first export data from the third-party directory to an LDIF file, as shown in Figure 23-1, "Using an LDIF File and bulkload".

Figure 23-1 Using an LDIF File and bulkload

Described in text.

LDIF is the IETF-sanctioned ASCII interchange format for representing LDAP-compliant directory data as a file. All LDAP-compliant directories should have tools to export their contents into one or more LDIF files representing the DIT at the time of export.


See Also:

RFC 2849 of the IETF, available for download at: http://www.ietf.org

When using an LDIF file and bulkload to migrate data to Oracle Internet Directory, you must perform the following tasks.

These tasks are explained in"Tasks For Migrating Data from LDAP-Compliant Directories" .

23.2.2.2 Scenario 2: Using dipassistant Directly

If you must perform mapping when migrating the data from the third-party directory to Oracle Internet Directory, and if the data is small in size, you can use dipassistant. As shown in Figure 23-2, "Using dipassistant Directly", you can use the third-party directory itself as input to dipassistant.

Figure 23-2 Using dipassistant Directly

Using dipassistant Directly

23.2.2.3 Scenario 3: Using an LDIF File and dipassistant

Scenario 3 is a variation on Scenario 2. If you do not have direct access to the third-party directory, you can have the administrator export the data to an LDIF file. As shown in Figure 23-3, "Using an LDIF File and dipassistant", dipassistant can take its input from an LDIF file. You could also use Oracle directory integration and provisioning server to migrate the data.

Figure 23-3 Using an LDIF File and dipassistant

Described in text.

Whenever you use an LDIF file and bulkload to migrate data to Oracle Internet Directory, you must perform certain tasks. In this scenario, you will be using a mapping file with dipassistant or Oracle directory integration and provisioning, so do not have to perform all the tasks listed in "Scenario 1: Using an LDIF File and bulkload". You only have to perform the following tasks:

23.2.2.4 Scenario 4: Using dipassistant, bulkload, and LDIF Files

If you have a large amount of data and you must perform mapping on the data, you can use a combination of tools. As shown in Figure 23-4, "Using dipassistant, bulkload, and LDIF Files", you can export the data from the third-party directory to an LDIF file, then use dipassistant bootstrap to perform the mapping into another LDIF file, which you then load with bulkload.

Figure 23-4 Using dipassistant, bulkload, and LDIF Files

Described in text.

As in Scenario 3: Using an LDIF File and dipassistant, you only have to perform these tasks:

23.2.2.5 Scenario 5: Using the Oracle Directory Integration and Provisioning Server

The Oracle directory integration and provisioning server allows you to configure bidirectional, ongoing integration between Oracle Internet Directory and a Third-party directory, as shown in Figure 23-5, "Using the Oracle Directory Integration and Provisioning Server". For more information, see Oracle Identity Management Integration Guide.

Figure 23-5 Using the Oracle Directory Integration and Provisioning Server

Described in text.

23.2.3 Tasks For Migrating Data from LDAP-Compliant Directories

To migrate data from LDAP-compliant directories using an LDIF file, you perform the tasks explained in this section.

As described in "Common Usage Scenarios", you do not need to perform Tasks 4-7 if you're using dipassistant or Oracle directory integration and provisioning with a mapping file.

23.2.3.1 Task 1: Export Data from the Non-Oracle Internet Directory Server into LDIF File Format

See the vendor-supplied documentation for instructions. If flags or options exist for exporting data from the foreign directory, be sure to select the method that:

  • Produces LDIF output with the least amount of proprietary information included

  • Provides maximum conformance to the IETF Request for Comments 2849 of the IETF, available for download at: http://www.ietf.org

23.2.3.2 Task 2: Analyze the LDIF User Data for Any Required Schema Additions Referenced in the LDIF Data

Any attributes not found in the Oracle Internet Directory base schema require extension of the Oracle Internet Directory base schema prior to the importation of the LDIF file. Some directories may support the use of configuration files for defining extensions to their base schema (Oracle Internet Directory does not). If you have a configuration file you can use it as a guideline for extending the base schema in Oracle Internet Directory in "Task 3: Extend the Schema in Oracle Internet Directory".

23.2.3.3 Task 3: Extend the Schema in Oracle Internet Directory

See Chapter 8, "Directory Schema Administration" for tips on how to extend the directory schema in Oracle Internet Directory. You can do this by using either Oracle Directory Manager or the SchemaSynch tool, which is documented in Oracle Identity Management User Reference Integration Guide.

If you have users who will be using other Oracle products, you must create users with object classes orclUserV2 and its required attributes. If you are integrating with Active Directory, you must create users with object class orclADUser and its required attributes. These object classes and their attributes are documented inOracle Identity Management User Reference.

23.2.3.4 Task 4: Remove Any Proprietary Directory Data from the LDIF File

Certain elements of the LDAP v3 standard have not yet been formalized, such as ACI attributes. As a result, various directory vendors implement ACI policy objects in ways that do not translate well across vendor installations.

After the basic entry data has been imported from the cleaned up LDIF file to Oracle Internet Directory, you must explicitly reapply security policies in the Oracle Internet Directory environment. You can do this by using either Oracle Directory Manager, or command-line tools and LDIF files containing the desired ACP information.

There may be other proprietary metadata unrelated to access control. You should remove this as well. Understanding the various IETF RFCs can help you determine which directory metadata is proprietary to a given vendor and which complies with the LDAP standards, and is thus portable by way of an LDIF file.

23.2.3.5 Task 5: Remove Operational Attributes from the LDIF File

Four of the standard LDAP v3 operational attributes, namely, creatorsName, createTimestamp, modifiersName, and modifyTimestamp are automatically generated by Oracle Internet Directory whenever entries are created or imported. It is not possible to instantiate these values from existing directory data, for example by using LDIF file importation. Therefore you should remove these attributes from the file before attempting to import.

23.2.3.6 Task 6: Remove Incompatible userPassword Attribute Values from the LDIF File

Oracle Internet Directory 10g Release 2 (10.1.2) supports the following userPassword attribute hash algorithms:

The userPassword attribute hash values used by some vendor products are not compatible with Oracle Internet Directory. As a result, you must remove all lines corresponding to the userPassword attribute and value from the LDIF data file unless they are represented in plain text or contain no value. After importation of the LDIF data, you must manually re-enter or upload hashed userPassword information separately into the directory. Be sure that the passwords comply with the Oracle Internet Directory password policies and are in clear text.

23.2.3.7 Task 7: Run the bulkload.sh -check Mode and Determine Any Remaining Schema Violations or Duplication Errors

Before generating and loading an LDIF file, always perform a check on it by using the bulkload utility check mode. The bulkload output reports any inconsistencies in the data.


Note:

To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:


See Also:

The "bulkload" command-line tool reference in Oracle Identity Management User Reference for instructions on how to use the bulkload check mode

23.3 Migrating User Data from Application-Specific Repositories

Migrating user data from an application-specific repository requires:

23.3.1 The Intermediate Template File

To enable this migration to happen, the Oracle Directory Provisioning Integration Service requires the application-specific repository to export its data to an intermediate template file. Records in this template file are not in pure LDIF; they contain substitution variables that have to do with, for example, the location in the directory where the information is finally to reside. The application leaves these variables undefined, so that you, the directory administrator can define them later on.

To convert the user data from this intermediate template file into proper LDIF, you use the OID Migration Tool (ldifmigrator). Once the data is converted to LDIF, you can load it into the directory.

To summarize: Migrating data from application-specific repositories involves these general steps:

  1. Exporting the application-specific data as an intermediate template file

  2. You, the directory administrator, using the OID Migration Tool (ldifmigrator) to read these partial LDIF entries and convert them to pure LDIF entries based on the deployment choices

  3. You, the directory administrator, loading the data, now in pure LDIF, into Oracle Internet Directory

  4. The application completing the migration process according to its own specifications

23.3.2 Reconciling Data in Application Repository with Data Already in Oracle Internet Directory

The data you are migrating from an application-specific repository may already reside in Oracle Internet Directory. If this is the case, then you can reconcile differences between the two directories by using the reconciliation feature of the OID Migration Tool (ldifmigrator).


See Also:

The "ldifmigrator" command-line tool reference in Oracle Identity Management User Reference for information about the reconciliation feature of the OID Migration Tool

23.3.3 Tasks For Migrating Data from Application-Specific Repositories

To migrate data from application-specific repositories, you create an intermediate template file, then run the OID Migration Tool.

23.3.3.1 Task 1: Create an Intermediate Template File

Applications generating data in national languages must store that data in AL32UTF8 in the intermediate template file as specified in the IETF RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification" available at http://www.ietf.org.

When generating the intermediate template file, migrating applications must list all user records sequentially with a record separator as defined in RFC 2849. The OID Migration Tool (ldifmigrator) assigns all of these users to the default identity management realm, which corresponds to the enterprise itself.

Figure 23-6 shows the overall structure of the intermediate template file containing user entries.

Figure 23-6 Structure of the Intermediate User File

Description of Figure 23-6  follows
Description of "Figure 23-6 Structure of the Intermediate User File"

The intermediate template file uses the following format to generate a valid user entry. All of the strings in bold text are supplied from the application-specific repository.

dn: cn=UserID, %s_UserContainerDN%
sn: Last_Name
orclGlobalID: GUID_for_User
%s_UserNicknameAttribute%: UserID
objectClass: inetOrgPerson
objectClass: orclUserV2

In this template, the strings %s_UserContainerDN% and %s_UserNicknameAttribute% are substitution variables for which the OID Migration Tool provides values. The OID Migration Tool determines these values according to deployment-specific considerations. Either the application passes the arguments to the OID Migration Tool, or the tool retrieves them from the directory.

23.3.3.1.1 Example: User Entries in an Intermediate Template File

The following intermediate template file includes user entries generated by the application-specific migration logic. In this example, all of the data listed in bold text is from the application-specific user repository.

dn: cn=jdoe, %s_UserContainerDN%
sn: Doe
%s_UserNicknameAttribute%: jdoe
objectClass: inetOrgPerson
objectClass: orclUserV2
title: Member of Technical Staff
homePhone: 415-584-5670
homePostalAddress: 234 Lez Drive$ Redwood City$ CA$ 94402

dn: cn=jsmith, %s_UserContainerDN%
sn: Smith
%s_UserNicknameAttribute%: jsmith
objectClass: inetOrgPerson
objectClass: orclUserV2
title: Member of Technical Staff
homePhone: 650-584-5670
homePostalAddress: 232 Gonzalez Drive$ San Francisco$ CA$ 94404

dn: cn=lrider, %s_UserContainerDN%
sn: Rider
%s_UserNicknameAttribute%: lrider
objectClass: inetOrgPerson
objectClass: orclUserV2
title: Senior Member of Technical Staff
homePhone: 650-584-5670

Once all of the user data is converted to the intermediate file format, the OID Migration Tool further converts it into a proper LDIF file that can be loaded into Oracle Internet Directory.

You can find examples of intermediate template files in $ORACLE_HOME/ldap/schema/oid.

23.3.3.1.2 Attributes in User Entries

Each user entry has mandatory and optional attributes.

Table 23-2 lists and describes the mandatory attributes in a user entry.

Table 23-2 Mandatory Attributes in a User Entry

Attribute Description

dn

Distinguished name of the user entry with appropriate substitution variables. The relative distinguished name of the entry MUST contain the cn attribute.

sn

Surname—that is, the last name—of the user

objectclass

Object classes the entry should minimally belong to: inetOrgPerson and orclUserV2



See Also:

  • IETF Request for Comments 2798: "Definition of the inetOrgPerson LDAP Object Class," available at http://www.ietf.org, for a description of each attribute in the inetOrgPerson object class

  • "Object Class Reference for Oracle Identity Management" in Oracle Identity Management User Reference for information about optional attributes of the orclUserV2 object class


23.3.3.2 Task 2: Run the OID Migration Tool

Once you have set up the intermediate template file, the OID Migration Tool enables you to bring all pertinent data from the application-specific repository into Oracle Internet Directory. Once you have migrated the data, you can update whatever portion of it is relevant to the application by synchronizing that application with Oracle Internet Directory. You synchronize by using the Oracle Directory Synchronization Service.


See Also:

The "ldifmigrator" command-line tool reference in Oracle Identity Management User Reference for instructions about using the OID Migration Tool