|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) Part No. B14082-01 |
|
 Previous |
 Next |
|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) Part No. B14082-01 |
|
|
Previous |
Next |
This chapter explains how to migrate data from both LDAP Version 3-compatible directories and application-specific directories into Oracle Internet Directory. It also explains how to migrate an existing directory into the default directory structure explained in Chapter 19, " Deployment of Oracle Identity Management Realms".
This appendix contains these topics:
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:
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.
To migrate data from LDAP-compliant directories, you perform the tasks explained in these topics:
Task 1: Export Data from the Non-Oracle Internet Directory Server into LDIF File Format
Task 2: Analyze the LDIF User Data for Any Required Schema Additions Referenced in the LDIF Data
Task 4: Remove Any Proprietary Directory Data from the LDIF File
Task 6: Remove Incompatible userPassword Attribute Values from the LDIF File
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 mentioned in "About the Data Migration Process"
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".
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 as explained in Oracle Identity Management Integration Guide.
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.
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.
Oracle Internet Directory 10g Release 2 (10.1.2) supports the following userPassword attribute hash algorithms:
No encryption
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.
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:
|
Migrating user data from an application-specific repository requires:
Collecting the user data from the application-specific repository and formatting it in a way that the directory can read it
Making that data available to the directory administrator who must then:
Specify where to place it in the directory
Import it into the directory
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:
Exporting the application-specific data as an intermediate template file
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
You, the directory administrator, loading the data, now in pure LDIF, into Oracle Internet Directory
The application completing the migration process according to its own specifications
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:
|
To migrate data from application-specific repositories, you create an intermediate template file, then run the OID Migration Tool.
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-1 shows the overall structure of the intermediate template file containing user entries.
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.
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.
Each user entry has mandatory and optional attributes.
Table 23-1 lists and describes the mandatory attributes in a user entry.
Table 23-1 Mandatory Attributes in a User Entry
|
See Also:
|
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 OID Migration Tool (ldifmigrator) Syntax" for instructions about using the OID Migration Tool |
During an Oracle Internet Directory installation, Oracle Universal Installer creates a default schema and directory information tree (DIT). This default DIT framework, described in Chapter 19, " Deployment of Oracle Identity Management Realms", is flexible: 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:
Root Oracle Context (cn=OracleContext)—This is the container where Oracle products store enterprise-wide configuration data.
Default identity management realm (dc=dns_domain_of_host,dc=com)—This is the container under which Oracle products expect to find enterprise users and groups. It approximates the enterprise DIT structure. For example, if Oracle Internet Directory is installed on a computer whose host name is: my_computer.us.my_company.com, then the default identity management realm created at installation of Oracle Internet Directory would be dc=us,dc=my_company,dc=com. Oracle products expect to find all users under the container cn=users,dc=us,dc=my_company,dc=com and all groups under cn=groups,dc=us,dc=my_company,dc=com. In addition to creating the default identity management realm entry, the Oracle Internet Directory Configuration Assistant stores a pointer to it in the Root Oracle Context so that other Oracle Internet Directory-enabled components can bootstrap themselves.
You can change this default identity management realm to suit your deployment requirements—for example, to store all of enterprise users in a different container.
