Run the following ds2oud command:

$ ds2oud --diagnose -h host1.example.com -p 1389 \
  -D "cn=directory manager" -j pwdfile

In the command above, host1 is the (O)DSEE server, not the OUD server.

The --diagnose subcommand identifies the following elements of your directory server configuration:

• Unsupported plug-ins

• Extensions to the default schema

• The type of password policy used which may have an impact if you use the Replication Gateway Strategy

• Encrypted attributes

• Index settings

• Global configuration parameters

For each element above, ds2oud identifies what needs to transition and potential incompatibilities (if any). Below is an example of an output:

*** diagnose the deployment ...
 
 
*******************************************************************************
Diagnose ODSEE Server : host1:1389
*******************************************************************************
 
 
** Plugins : No user plugins are defined, nothing particular to migrate
 
** Plugins : No subtree counter plugins are enabled, nothing particular to
migrate
 
** Schema
 
The schema was extended regarding the original delivery. The following schema
should be added to the new OUD server
attributeTypes : ( 2.16.840.1.113730.9999 NAME 'customAttributeType' DESC
'Oracle defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE X-ORIGIN ( 'Custom' 'user defined' ) )
 
** Password Policy
 
A compatible password policy is defined, nothing particular to migrate
 
** Naming context(s) available on the ODSEE server :
o=migration
 
 
No incompatibility has been detected for naming context o=migration
 
** Indexes
 
Only default indexes are defined, nothing particular to migrate
 
** Encrypted attributes
No encrypted attributes are defined, no action is required 

To verify that your directory server data is compliant with OUD schema before importing the data:

Schema errors may be reported for the following reasons:

• Default schema is different.

• OUD has a more recent version of standard schema.

• Attribute value syntax validation and containment rules validations.

• Unsupported directory metadata. This includes role-based ACIs, Roles or Class of Services definitions currently not supported by OUD password policies as LDAP sub-entries. These sub-entries contain (O)DSEE specific extensions account-based resource limits that differ between (O)DSEE and OUD.

In the above cases, OUD provides the commands below to make schema constraints flexible and resolve those schema errors.

Structural objectclass errors:

Structural objectclass errors occur when your directory server data is rejected during an import. A common reason for this error is the structural object-class for the user entry. The user entry must have exactly one structural object-class. If the entry has zero or more than one, the entry will be rejected. Also, because your (O)DSEE directory server does not differentiate between the two object-class types, this kind of schema inconsistency is common. Use the following command to avoid this error:

dsconfig set-global-configuration-prop --set \
single-structural-objectclass-behavior:accept -n

Invalid attribute value errors:

Attribute values must conform to the attribute syntax defined in the schema. By default, attribute syntax checking is enabled in OUD. For example, an attribute with Boolean syntax can hold TRUE or FALSE values only. In addition, zero-length attribute values are rejected by OUD during an import. However it is possible to make this constraints flexible for the DirectoryString syntax by using this command:

dsconfig set-attribute-syntax-prop --syntax-name Directory\ String \
--set allow-zero-length-values:true -n

• Naming contexts

• Global configuration settings that are relevant for OUD

• Size-limit

• Look-through-limit

• Idle-time-limit

• Max-psearches

• Bind-with-dn-require-password

• Allidthresholds

• Database indexes

• Global default access controls

• Supported built-in plug-ins

• 7-bit check

• UID uniqueness plug-in

• Referential integrity plug-in

• Strong password policy check

To apply each of the above configuration settings to each OUD instance, you must run the ds2oud command in batch mode. It will then generate a list of commands to be applied with dsconfig. This is recommended to be able to complement changes and replay them easily on every target system.

To produce the administrative command batch file to transition the configuration, run the following command:

ds2oud --migrateConfiguration 
       --odseeBindDN "cn=directory manager"
       --odseePort <ODSEE_PORT>
       --odseeBindPasswordFile <ODSEE_ADMIN_PASSWORD_FILE>
       --oudBindDN "cn=directory manager"
       --oudBindPasswordFile <OUD_ADMIN_PASSWORD_FILE1>
       --oudPort <OUD_LDAP_PORT1>
       --oudAdminPort <OUD_ADMIN_PORT1>
       --no-prompt --batchFile <COMMAND_BATCH_FILE>

This section includes the following topics:

• Migrating SSL Certificates

• Configuring the PKCS#12 Keystore

• Configuring the LDAPS Connection Handler to use the PKCS#12 keystore

• Importing the Directory Server Certificate Key Pair

• Migrating Encrypted Attributes

Configuration changes generated in Migrating Configuration Settings Using the ds2oud Command, can be applied to the OUD directory server instance with the following command:

dsconfig -h <oud hostname> -p <oud admin port> -D cn="directory manager" -w <admin password> \
  -F command_batch_file -X -n

The -F or --batchFilePath option of the dsconfig command enables you to specify several operations that are completed in a single command by consolidating those operations in a file. This can significantly improve performance and simplify configuration of other instances when several dsconfig commands are required.

Additional configuration changes identified in Migrating SSL Certificates, need to be applied also.

Go to Understanding (O)DSEE Directory Server, Configuration, Schema and Data using ds2oud, for information on exporting to LDIF files.

For example, if you are using the Direct Transition Strategy or the Transition Strategy Using DIP, replication metadata that accounts for a large volume of the data on the disk should be filtered out at export time. But for the Transition Strategy using Replication Gateway, replication metadata is needed.

If you are using the Direct Transition Strategy or the Transition Strategy Using DIP, run the dsconf export command as shown in the following example to export the user data to LDIF:

$ dsconf export --no-repl --decrypt-attr \
-h host1.example.com -p 1389 \
dc=example,dc=com odsee-data.ldif

If you are using Transition Using Replication Gateway Strategy the replication metadata must be kept and adapted to OUD format. To export the user data to LDIF using this strategy, run the dsconf export command as shown in the following example:

$ dsconf export -f opends-export --decrypt-attr -h host1.example.com -p 1389 \
  dc=example,dc=com odsee-data.ldif

The following is an import-ldif example:

import-ldif -b <your user data suffix>  -n userRoot --excludeAttribute "nsds5replconflict"  -l <path to LDIF file>

When you use the opends-export option during transition, (O)DSEE-specific attributes might exist in some entries which will prevent these entries from being imported. For instance, nds5replconflict might exist in the (O)DSEE data so it is imperative to filter this attribute during import to OUD using the following import option:

--excludeAttribute "nsds5replconflict" 

The different strategies for directory metadata transition:

• For the Direct Transition Strategy: the directory metadata only must be adapted once.

• For the Replication Gateway Strategy: directory metadata are replicated between the directory server and OUD. The directory metadata must be kept compatible on both sides. However, some metadata are different between the two environments, so additional schema extensions will be required to avoid errors or loss of data.

• For the DIP Strategy: DIP should be configured to synchronize user data. The directory metadata is generally added manually on OUD. In some cases, you can configure DIP to synchronize the metadata.

Access to data is managed with access control instructions (ACIs) that specify the access rights of entries. ACIs can be stored as part of the user data or in the OUD configuration.

• Global ACIs versus ACIs in the data

  Global ACIs apply to all entries in the directory. They are stored in the configuration. (O)DSEE and OUD global ACIs can differ without causing errors as they are not replicated.

  The ds2oud tool migrates the global ACIs to OUD global ACIs automatically.

  ACIs that are stored as part of the data, are replicated.

• Differences with Syntax

  The roledn keyword is currently not supported in OUD 12c. ACIs with the roledn keyword cannot be imported into OUD because ACI syntax checking fails. Roles can be replaced by groups and the roledn keyword can be replaced by groupdn (See Roles and ACIs).

  A new value for the targetscope keyword, subordinate, is introduced in OUD. This value is not supported by (O)DSEE so it must not be used in a two-way replication topology between (O)DSEE and OUD.

• Behavioral Differences

  In a few cases, evaluation of the same ACI differs between (O)DSEE and OUD. Since OUD grants less access by default than (O)DSEE, you will need to grant additional write access during the transition so that OUD behaves like (O)DSEE. In such cases, OUD ACI evaluation would be more inflexible than on the (O)DSEE side.

  By default, OUD ACIs do not allow users to reset another user's password. With OUD, a privilege must be added to achieve behavior that is equivalent to that of (O)DSEE. Alternatively, it is possible to disable the privilege subsystem. For example, the command below allows the admin to reset user passwords in (O)DSEE (this type of password reset is refused by default in OUD):

  ldapmodify -p <dsee port> -D "cn=directory manager"-w <admin password
  dn: dc=example,dc=com 
  changetype: modify 
  replace: aci 
  aci: (targetattr = "*") (version 3.0;acl "Custom LDAP Administrator";allow (all)(userdn = "ldap:///uid=admin,dc=example,dc=com");)
   

  With OUD, the following privilege below must be added to achieve the equivalent behavior:

  dn: uid=admin,dc=example,dc=com 
  changetype: modify 
  add: ds-privilege-name 
  ds-privilege-name: password-reset
  

  Alternatively, the privilege subsystem can be disabled using the following command:

  dsconfig set-global-configuration-prop  -add disabled-privilege:password-reset 
  

To deploy DIP:

1. Choose the (O)DSEE master instance and the OUD directory server instance that will be synchronized. The OUD directory server must have an embedded replication server because the external changelog services is provided by replication servers.

2. Synchronize password storage schemes.

   Password storage schemes must be identical and compatible between (O)DSEE and OUD. To configure password storage schemes to enable synchronization, see Managing Password Policies in Administering Oracle Unified Directory.

3. Create a directory suffix holding DIP metadata in (O)DSEE.

   Use the following command on DSEE 6.x (or higher) to create the suffix cn=products,cn=oraclecontext to hold DIP metadata:

   dsconf create-suffix -i -c -p $PORT -D "$ADMIN" -w "$PW_FILE" cn=products,cn=oraclecontext
   

   For instructions on how to create the directory suffix for DSEE 5.2, see Creating Suffixes in Sun ONE Directory Server Administration Guide.

4. Enable changelog.

   Changelog must be enabled on the directory that will contain changes. Enable changelog on (O)DSEE with the following command:

   dsconf set-server-prop -p $PORT -w "$PW_FILE" retro-cl-enabled:on
   

   For two-way synchronization, external changelog must be enabled on OUD. By default, the external changelog is automatically enabled when the OUD instance is part of a replication topology. For testing purposes, set up a standalone OUD directory server instance and enable external changelog with the following command:

   dsreplication enable-changelog --no-prompt --baseDN "dc=example,dc=com" --hostname "$HOST" --port $APORT --bindDN "$ADMIN" --adminPasswordFile "$PW_FILE" --trustAll
   

5. Install and configure DIP.

   1. Install DIP in a Weblogic container.

      For more information on installing DIP in a WebLogic container, see Configuring the Oracle WebLogic Server Domain for Oracle Directory Integration Platform with Oracle Unified Directory in Administrator's Guide for Oracle Directory Integration Platform.

   2. Configure DIP with the command below:

      $ORACLE_HOME/bin/dipConfigurator setup -wlshost <hostname> -wlsport <admin_server_domain_Port> -wlsuser weblogic -ldaphost <dsee_host> -ldapport <dsee_port> -ldapuser "dsee_administrator" -metadatasuffix cn=products,cn=oraclecontext -isldapssl false
      

      The <dsee_administrator>, for example, cn=directory manager must be granted read and write access to the DIP metadata suffix (cn=products,cn=oraclecontext).

      In the default password policy, the allow-pre-encoded option must be 'true.' This will allow the <dsee_administrator> to have access to write pre-encoded password.

      For LDAP users, the following command will change the default password policy:

      dsconfig set-password-policy-prop --policy-name Default\ Password\ Policy --set allow-pre-encoded-passwords: true
      

      SSL users refer to the DIP Administrator's Guide to manage certificates.

6. Create synchronization profiles.

   Ensure that the oud_ldap_administrator (for example, cn=directory manager) has read and write access to the suffix to be synchronized. Also, when two-way synchronization is used, it must have read access on the OUD external changelog.

   There are two ways to synchronize profiles: the command line and DIP graphical user interface (EM). The following is an example to synchronize profiles using the command line:

   $ORACLE_HOME/bin/expressSyncSetup -h <dip_hostname> -p <dip_domain_port> -D weblogic -conDirType IPLANET -conDirUrl <OUD_host>:<oud_port> -conDirBindDN <oud_ldap_administrator> -conDirContainer <target_suffix> -backendDirContainer cn=products,cn=oraclecontext  -pf <profile_name>
   

   The command above creates one import file and one export file with the following naming convention:

   • If the profile name (-pf argument) is profile1, expresSyncSetup creates the two following profiles profile1Export and profile1Import.

   To create synchronization profile using EM, see Creating Synchronization Profiles in Administrator's Guide for Oracle Directory Integration Platform. Use the DIP graphical user interface to update the list of attributes to be synchronized.

   Oracle recommends that you create 1-1 exact attribute mappings (for example, cn<->cn) and one extra mapping for each attribute alias (for example, commonName->commonName).

7. Configure ACIs.

   Additional directory ACIs must be created on the backend directory server for DIP to operate correctly.

   The following command is an example of ACIs created on the backend directory on the suffix to be synchronized (dc=example,dc=com):

   ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF
   dn: dc=example,dc=com
   changetype: modify
   add: aci
   aci: (target="ldap:///dc=example,dc=com")(version 3.0; acl "Entry-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; )
   -
   add: aci
   aci: (targetattr="*")(version 3.0; acl "Attribute-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext";)
   EOF
   

   Export profile's entry must be added to the Export group:

   ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF
   dn: cn=odipegroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext
   changetype: modify
   add: uniqueMember
   uniqueMember: orclodipagentname=profile1Export,cn=subscriber profile,cn=changelog subscriber,cn=directory integration platform,cn=products,cn=oraclecontext
   EOF
   

   Note that the profile name (profile1Export in the example) is part of the DN of the new member

   When two-ways synchronization is used, the Import profile's entry must be added to the Import group:

   ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF
   dn: cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext
   changetype: modify
   add: uniqueMember
   uniqueMember: orclodipagentname=profile1Import,cn=subscriber profile,cn=changelog subscriber,cn=directory integration platform,cn=products,cn=oraclecontext
   EOF
   

   In the example above, notice that the profile name (profile1Export in the example) is part of the DN of the new member.

8. Managing Directory Bootstrapping.

   Bootstrapping refers to the initial transition of data between the (O)DSEE back-end directory and OUD. Because the synchronization process can handle the transition of data between an (O)DSEE and OUD, you are not required to perform directory bootstrapping. However, relying on the synchronization process to perform the initial transition will be a time-consuming process. For this reason, you should perform directory bootstrapping when you first deploy DIP.

   There are two possibilities to initialize the two directory topologies:

   1. Enable the synchronization so that DIP creates every (O)DSEE entry to OUD.

   2. Export the content of the (O)DSEE directory to an LDIF file, then import the content to OUD and configure DIP to use the (O)DSEE changelog.

   The first solution is simpler but it is much slower than with the Direct Transition Strategy which uses this procedure.

   To use the first solution you must:

   1. Enable the synchronization profiles.

   2. Run the following commands:

   $ORACLE_HOME/bin/syncProfileBootstrap -h <dip_host> -p <dip_domain_port> -D weblogic -pf profile1Import
   
   $ORACLE_HOME/bin/syncProfileBootstrap -h <dip_host> -p <dip_domain_port> -D weblogic -pf profile1Export
   

   Directory Boostrapping is described in Bootstrapping a Directory in Oracle Directory Integration Platform in Administering Oracle Directory Integration Platform.

   To use the LDIF bootstrapping:

   1. Use the following command to export entries from DSEE to data.ldif file without the replication metadata and with the backend server in off-line mode:

      $ dsconf export --no-repl -h host -p port suffix-DN LDIF-file
      

   2. Retrieve the change number of the last update applied before the export began. To do so, start the export procedure then write down the time and convert it in Generalized Time in YYYYMMDDHHMMSSZ format: An example of a time stamp in a generalized time format is 20130508200557Z, which specifies a time (in the UTC time zone) of 8:05:57 PM on May 28, 2013.

   3. Restart the (O)DSEE server (if needed) after the export has completed.

   4. Run the following search command:

      ldapsearch -p <dsee_port> -D <dsee_admin> -w <password> -b "cn=changelog" "changetime>= <timeStamp>" changeNumber
      

   5. Note the value of the smallest changeNumber value returned by doing the following:

      ldapsearch -p PORT -h DSEE HOSTNAME -D "cn=directory manager" -w PASSWORD -b "cn=changelog" "changetime>=20130508200557Z" changeNumber
      dn: changenumber=16747773,cn=changelog
      changeNumber: 16747773
      dn: changenumber=167477734,cn=changelog
      changeNumber: 167477734
      dn: changenumber=1674777345,cn=changelog
      changeNumber: 1674777345
      

   6. Use the DIP management console (EM) as described in Managing Synchronization Profiles Using Fusion Middleware Control in Administrator's Guide for Oracle Directory Integration Platform.

      Or you can use the manageSyncProfiles updatechgnum command to start synchronization to update the last change number parameters of the DIP synchronization export profile with the above value. The manageSyncProfiles updatechgnum command is described in manageSyncProfiles utility in Administrator's Guide for Oracle Directory Integration Platform.

   7. Enable the DIP synchronization profiles using GUI or CLI as described in Enabling and Disabling Synchronization Profiles in Administrator's Guide for Oracle Directory Integration Platform.

   Synchronization will now begin based on the changelog.

As a reminder, (O)DSEE makes the distinction between three types of replicas:

1. A master replica is a read-write database that contains a master copy of the directory data.

2. A consumer replica is a read-only database that contains a copy of the information held in a master replica.

3. A hub replica is a read-only database, like a consumer replica, but stored on a directory server that supplies one or more consumer replicas.

For more information on (O)DSEE replicas, see Introduction to Replication in Reference for Oracle Directory Server Enterprise Edition.

The OUD replication model is a multi-master model. In other words, all directory server replicas in a replicated topology can process both read and write operations.

Since the release of DSEE 6.x, Oracle have recommended multi-master replica with typical deployments, which eliminated the need for consumer and hub replicas.

In most deployments, using read-only replica is not needed for performance reason and should only be done if the applications require it. In this case it is achieved by configuring the writability mode of the back end. However, you can configure an OUD directory server to be read-only, in which case add, modify, and delete operations from LDAP clients are rejected on this server and a referral is returned containing pointers to others (read-write) servers within the replicated topology.

In (O)DSEE, hub replicas are introduced with cascaded replication to make the replication protocol operate better. Cascading replication is useful in the following scenarios:

• When there are a lot of consumers.

• Because the masters in a replication topology handle all update traffic, it could put them under a heavy load to support replication traffic to the consumers. You can off-load replication traffic to several hubs that can each service replication updates to a subset of the consumers.

• To reduce connection costs by using a local hub in geographically distributed environments.

In OUD, hub replicas do not exist. Replication is built around a centralized publish-subscribe architecture. Each directory server communicates with a central service, and uses the central service to publish its own changes and to receive notification about changes on other directory servers. This central service is called the replication service. OUD read-write masters are the default so in most cases they are deployed.

The replication service can be made highly available by using multiple server instances running on multiple hosts. Within the replication architecture, a server instance that provides the replication service is called a replication server. A server instance that provides the directory service is called a directory server.

In a small topology (up to four directory servers) it makes sense to configure each server to function as both a directory server and a replication server. In a large topology (more than twenty directory servers) it is advisable to separate the directory server and replication server instances into separate JVMs, and to limit the number of replication servers.

Between these two extremes, you can decide on the configuration that works best for your requirements. Having all servers functioning as both directory servers and replication servers is generally a simpler topology and easier to administer. Separating the directory servers and replication servers lowers the disk requirements of the directory server instances because they do not need to store a replication change log.

In large topologies with several directory servers and several replication servers, it is more efficient to spread the directory servers out across the replication servers in a predefined manner. This is particularly important if the replication servers run on different types of machines with different capabilities. If the estimated performance of the machines differs significantly from one replication server to another, it is useful to balance the load on the replication servers according to their power.

You must understand the replication concepts of OUD because they are different than those of (O)DSEE. For more information about configuring Replication Servers and Load-balancing, see Undestanding Replication Server Load Balancing in Administering Oracle Unified Directory.

This example assumes a replication configuration with replication servers on two hosts: host1 and host2. The example makes the directory server on host2 a read-only replica and uses the dsconfig command which accesses the server configuration using the administration connector.

For more information on configuring an OUD read-only replica, see Understanding Replication Server Load Balancing in Administering Oracle Unified Directory.

You can configure OUD as a read-only replica using the dsconfig command to set the writability-mode of host2:

$ dsconfig -h host2 -p 4444 -D "cn=Directory Manager" -j <password_file> -X -n \
  set-global-configuration-prop --set writability-mode:internal-only

A writability mode of internal-only means that replication operations are processed on the server, but the server is not writable directly by LDAP client applications.

To create new OUD instances:

For deploying servers in a replicated topology, see Configuring Data Replication with dsreplication in Administering Oracle Unified Directory.

Once an OUD server is loaded with (O)DSEE data, you can either import the same file on every other OUD instance or use binary copy or initialize a replicated server with the data from another replicated server as described in Administering Oracle Unified Directory.

If you are using the Replication Gateway Strategy, you must ensure that the OUD reference instance is loaded with (O)DSEE data that was exported before the (O)DSEE replication purge delay configured on (O)DSEE.

The four options are:

• Run the dsreplication command to initialize each empty OUD instance. See Initializing a Replicated Server With dsreplication in Administering Oracle Unified Directory.

• Initialize each OUD instance at the same time. See Initializing an Entire Topology With dsreplication in Administering Oracle Unified Directory.

• Perform a binary copy of the database files from the reference OUD to each OUD instance. See Adding a Directory Server to an Existing Replicated Topology in Administering Oracle Unified Directory.

• Export entries from the reference OUD and reimported them into each empty OUD instance.