The garbage collection engine triggers the corresponding background database

35-10 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory the changelog purging configuration entry. This example configures time-based purging for 120 hours 5 days. Use an LDIF file similar to this: dn: cn=changelog purgeconfig,cn=purgeconfig,cn=subconfigsubentry changetype:modify replace: orclpurgetargetage orclpurgetargetage: 120 To apply the ldif file mod.ldif, type: ldapmodify -D cn=orcladmin -q -p port -h host -D dn -q -f mod.ldif Note: The container for the change log garbage collector is cn=changelog purgeconfig, cn=purgeconfig,cn=subconfigsubentry. See Also: Oracle Internet Directory Configuration Schema Elements in Oracle Fusion Middleware Reference for Oracle Identity Management 36 Migrating Data from Other Data Repositories 36-1 36 Migrating 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: ■ Introduction to Migrating Data from Other Data Repositories ■ Migrating Data from LDAP-Compliant Directories ■ Migrating User Data from Application-Specific Repositories Introduction to Migrating Data from Other Data Repositories During an Oracle Internet Directory installation, Oracle Identity Management 11g Installer creates a default schema and directory information tree DIT. Chapter 3, Understanding Oracle Internet Directory Concepts and Architecture, and Chapter 33, Planning, Deploying and Managing Realms, describe this default DIT framework. The framework is flexible and you can modify it to suit the needs of your deployment. In Oracle Internet Directory, 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. 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 36-2 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory that directory into the default directory structure environment, then follow the instructions in this section. Two tools that are commonly used for migrating data are bulkload and syncProfileBootstrap. Table 36–1, Features of bulkload and syncProfileBootstrap lists the features of bulkload, as compared with syncProfileBootstrap. Migrating LDAP Data by Using an LDIF File and bulkload The bulk loader, bulkload, is a command-line tool for loading a large number of entries into a directory server. It uses Oracle SQLLoader 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. 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 36–1, Using an LDIF File and bulkload . Figure 36–1 Using an LDIF File and bulkload 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. Table 36–1 Features of bulkload and syncProfileBootstrap Feature bulkload syncProfileBootstrap 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 See Also: ■ Oracle Internet Directory Data Management Tools in Oracle Fusion Middleware Reference for Oracle Identity Management for bulkload syntax information and examples, ■ Oracle Fusion Middleware Administrators Guide for Oracle Directory Integration Platform for more information about syncProfileBootstrap. Oracle Internet Directory Third-Party Directory bulkload LDIF File Migrating Data from Other Data Repositories 36-3 When using an LDIF file and bulkload to migrate data to Oracle Internet Directory, you must perform the following 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: ■ 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 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 before 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 20, Managing Directory Schema for tips on how to extend the directory schema in Oracle Internet Directory. You can do this by using either Oracle Directory Services Manager or the SchemaSynch tool, which is documented in Oracle Fusion Middleware Reference for Oracle Identity Management. If you have users who are using other Oracle products, you must create users with object class 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 Fusion Middleware Reference for Oracle Identity Management. 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 Services 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 See Also: RFC 2849 of the IETF, available for download at: http:www.ietf.org