Skip Headers

Oracle Internet Directory Administrator's Guide
Release 9.2

Part Number A96574-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

E
Migrating Data from Other Directories

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

This appendix contains these topics:

Migrating Data from LDAP-Compliant Directories

This section contains these topics:

About the Data Migration Process

You can import data from a third-party LDAP-compliant directory into Oracle Internet Directory by saving the data in an LDIF file. LDIF is the IETF-sanctioned ASCII interchange format for representing LDAP-compliant directory data as a file. All LDAP-compliant directories should be able to export their contents into one or more LDIF files representing the DIT at the time of export.

Be aware that certain proprietary attributes or metadata may be included in a given product's LDIF output. You must remove this extraneous data from the LDIF file before you import the file into Oracle Internet Directory. In such cases, you need to perform some additional steps before importing the LDIF files into Oracle Internet Directory. The next section explains these steps.

See Also:

The LDIF technical specification available for download at:http://www.ietf.org/rfc/rfc2849.txt

Tasks For Migrating Data from LDAP-Compliant Directories

To migrate data from LDAP-compliant directories, you perform these tasks:

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:

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

Task 3: Extend the Schema in Oracle Internet Directory

See Chapter 6, "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 as explained in "The schemasync Tool".

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.

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.

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

Oracle Internet Directory Release 9.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 re-enter manually or upload hashed userPassword information separately into the directory.

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:

"bulkload Syntax" for instructions on how to use the bulkload check mode

Migrating User Data from Application-Specific Repositories

Migrating user data from an application-specific repository requires:

To enable this migration to happen, the Oracle Directory Provisioning Integration Service relies on the application-specific repository exporting its data to an intermediate template file. This is not a pure LDIF file. Rather, records in this template file are in LDIF, but with substitution variables that the application itself leaves undefined--for you, the directory administrator, to define later in the process. These variables have to do with, for example, the location in the directory where the information is finally to reside.

To convert the user data from this intermediate template file into proper LDIF, you use the OID Migration Tool. 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. (LDIF) template file
  2. You, the directory administrator, using the OID Migration Tool to read these partial LDIF entries and convert them to actual LDIF entries based on the deployment choices
  3. You, the directory administrator, loading the data, now in LDIF, into Oracle Internet Directory.
  4. The application completing the migration process according to its own specifications.

Tasks For Migrating Data from Application-Specific Repositories

You can run the OID Migration Tool in one of two modes:

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

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/rfc/rfc2849.txt.

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 User Migration Tool assigns all of these users to the default subscriber, which corresponds to the enterprise itself.

Figure E-1 shows the overall structure of the intermediate template file containing user entries.

Figure E-1 Structure of the Intermediate User File

Text description of oidag068.gif follows
Text description of the illustration oidag068.gif


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.

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 $SRCHOME/ldap/schema/oid.

Attributes in User Entries

Each user entry has mandatory and optional attributes.

Table E-1 lists and describes the mandatory attributes in a user entry.

Table E-1  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 be cn.

sn

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

objectclass

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

The following are optional attributes from the inetOrgPerson object class:

orclGuid

userPassword

telephoneNumber

seeAlso

description

title

x121Address

registeredAddress

destinationIndicator

preferredDeliveryMethod

telexNumber

teletexTerminalIdentifier

internationaliSDNNumber

facsimileTelephoneNumber

street

postOfficeBox

postalCode

postalAddress

physicalDeliveryOfficeNameou

st

l

audio

businessCategory

carLicense

departmentNumber

displayName

employeeNumber

employeeType

givenName

homePhone

homePostalAddress

initials

jpegPhoto

labeledURI

mail

manager

mobile

pager

photo

preferredLanguage

roomNumber

secretary

uid

userCertificate

x500UniqueIdentifier

userSMIMECertificate

userPKCS12

See Also:

IETF Request for Comments 2798: "Definition of the inetOrgPerson LDAP Object Class," available at http://www.ietf.org/rfc/rfc2798.txt?number=2798, for a description of each attribute in this object class

The following are optional attributes from the orclUserV2 object class:

Table E-2  Attributes in the orclUserV2 Object Class
Attribute Description

OrclPassword

An Oracle-specific password identifier for custom authentication schemes like O3Logon for the database server

OrclHireDate

Specifies the date on which an employee starts working for a company or subscriber

OrclDefaultProfileGroup

Holds the name (DN) of the group to designate a default group for a user such that a default profile can be built for the user based on this attribute value.

OrclPasswordHint

Specifies the question set by a user for administering password on behalf of a user

OrclPasswordHintAnswer

Specifies the answer set for orclPasswordHint

OrclTimeZone

Indicates the geographical time zone of a user based on his office location.Valid values are the three letter time zone values--for example, EST, PST, GMT

OrclIsVisisble

Specifies whether the user entry should be displayed in people search applications

OrclDisplayPersonalInfo

Specifies if the user personal information should be displayed in white pages queries

OrclWorkflowNotificationPref

Specifies the preferred notification mechanism for Oracle Workflow.

OrclMaidenName

Specifies the maiden name of an individual

OrclDateOfBirth

Specifies the date on which an individual was born

orclActiveStartDate

The date on which the user can successfully begin to authenticate to the Oracle9iAS Single Sign-On server. Values are represented in Universal Time format.

orclEnddate

The date after which the user can no longer authenticate to the Oracle9iAS Single Sign-On server. Values are represented in Universal Time format.

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 either the Oracle Directory Synchronization Service or the Oracle Directory Provisioning Integration Service.

See Also:

"The OID Migration Tool" for instructions about using the OID Migration Tool


Go to previous page Go to next page
Oracle
Copyright © 1999, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback