Validating Your Transition Strategy

3.1 Validation of the Selected Strategy

After choosing a strategy to transition Directory Server Enterprise Edition to Oracle Unified Directory, the next step is to validate your selected strategy.

To validate that you have selected the best transition strategy, you should consider all of these aspects for your chosen strategy: (O)DSEE release, password policy version used, and whether (O)DSEE-specific features like Roles and Class of Services are used in addition to what was identified in Choosing a Transition Strategy.

3.2 Considerations for DSEE Versions

The DSEE version impacts the transition process when replication gateway is used for transition.

The DSEE version impacts the transition in the following ways:

Password Policy State Replication

DSEE 5.2 uses a set of password policy attributes. Starting with DSEE 6.0, a new set of standard password policy attributes (DS6-mode) was introduced. The choice between DSEE 5.2 password policy and DS6 password policy is made by configuration.

OUD and the Replication Gateway manage standard attributes. Fully-functional password policy between (O)DSEE and OUD requires every (O)DSEE instance to run in DS6-mode.

The switch from default password policy mode to DS6-mode requires administrative action.

For information on password policy, see Password Policy Compatibility in Administrator's Guide for Oracle Directory Server Enterprise Edition.

DSEE 5.2 instances or any (O)DSEE instance with old password policy mode in the existing (O)DSEE topology, requires schema extension on both (O)DSEE and OUD.

Replication Gateway Integration

The Replication Gateway must communicate with one compatible ODSEE master instance. This means that the ODSEE server connected to the Replication Gateway must be at least an ODSEE 11g R1 (11.1.1.5) instance. If none is available, ODSEE 11g must be added to the topology for use by the Replication Gateway. You can keep this ODSEE 11g R1 and its Replication Gateway located on the same box, or you can upgrade any existing instance to at least ODSEE 11g R1 (11.1.1.5).

Note:
With OUD 14c the replication gateway can communicate with a DSEE 6.3 instance, while older versions, such as DSEE 5.2, still require the addition of an ODSEE 11g instance.

Figure 3-1 Transition process to OUD using the Replication Gateway

Description of "Figure 3-1 Transition process to OUD using the Replication Gateway"

3.3 Overview of (O)DSEE Legacy Features

Oracle Unified Directory adopts certain features from (O)DSEE for its use, regardless of the strategy chosen.

This section contains the following topics:

3.3.1 Role-based ACIs

You can use Role-based ACIs to manage access to data, based on user role. Oracle Unified Directory 14c (14.1.2.1.0) does not support Role-based ACIs, so such ACIs must be adapted and replaced by group-based ACIs during the transition process, regardless of the strategy in use.

With the Replication Gateway Strategy, every directory metadata are replicated, including ACIs. This means that role-based ACIs must be replaced by group-based ACIs on (O)DSEE before putting coexistence in place.

When the DIP Strategy is used, you need to either adapt such ACIs on (O)DSEE before deploying synchronization, or consider excluding synchronization of such ACIs.

For more information on Role-based ACIs, see Directory Server Access Control in Administrator's Guide for Oracle Directory Server Enterprise Edition.

3.3.2 Roles and Class of Services (CoS)

You must replace (O)DSEE Roles and Class of Services to equivalent OUD mechanisms. In some cases, the corresponding OUD mechanism requires the use of directory metadata. For example, you can replace Class of Service definitions by OUD Collective Attributes definitions stored along with user data.

See Overview of Roles Transition to OUD, and Understanding Class of Service (CoS) for more information.

When the Replication Gateway Strategy is used, these OUD-specific metadata may be replicated back to (O)DSEE. In such cases, (O)DSEE schema must be extended to support these additional attributes and objectclasses. An extract of the OUD schema that can be used on (O)DSEE servers for compatibility reasons is available with OUD: INSTALL_DIR/config/ds2oud/99OudSchemaExtract.ldif

For more information on Roles and CoS in ODSEE, see Directory Server Groups, Roles, and CoS in Administrator's Guide for Oracle Directory Server Enterprise Edition.

3.3.3 Custom Password Policies

You can store custom password policies as part of the data in (O)DSEE. Such password policy definitions are made of standard attributes (supported by OUD) and (O)DSEE-specific attributes (replaced by other attributes in OUD). Furthermore, assignment of a password policy to a given user entry differs between (O)DSEE and OUD.

With the Replication Gateway Strategy, some OUD-specific metadata may be replicated back, requiring (O)DSEE schema extensions. An extract of the OUD schema that can be used on ODSEE servers for compatibility reasons is available with OUD: INSTALL_DIR/config/ds2oud/99OudSchemaExtract.ldif

For more information on Custom Password Policies, see Directory Server Password Policy in Administrator's Guide for Oracle Directory Server Enterprise Edition.

3.3.4 Impact of Data Inconsistencies

Characteristics of user data stored in (O)DSEE may impact transition because OUD implements full schema check, including attribute value syntax validation. (O)DSEE does not implement full schema check so, some values accepted on the (O)DSEE side might be rejected by OUD.

These data inconsistencies can be identified using diagnostic tools that ship with OUD. These issues may be addressed in several ways, including fixing the data before transition, fixing the schema, or making some checks on OUD, flexible.

3.4 Review: Impact of Technical (O)DSEE Characteristics

The technical characteristics of (O)DSEE impact the transition from Directory Server Enterprise Edition to Oracle Unified Directory.

In the following tables, the impact of technical (O)DSEE characteristics are summarized. Also, note that an asterisk (*) indicates the preferred option if your transition does not require two-way replication. Using this option reduces the impact on the (O)DSEE side since one-way replication only replicates changes from (O)DSEE to OUD.

Table 3-1 Existing Directory Server Release

Directory Server Release	Replication Gateway	DIP	Direct
DSEE 5.2	Deploy one ODSEE 11g instance as a gateway companion. Extend DSEE schema with OUD password policy (*). Limitation: password policies on (O)DSEE and OUD are decoupled	Limitation: password policies on (O)DSEE and OUD are decoupled	Limitation: password policy state is reset during transition.
DSEE 6.x/7.x	Extend DSEE schema with OUD password policy (*). Upgrade DSEE password policy mode if needed.	Limitation: password policies on (O)DSEE and OUD are decoupled.	Limitation: password policy state is reset during transition.
ODSEE 11gR1+	Extend DSEE schema with OUD password policy if no global password policy needed & stick to old password policy mode (*). Upgrade DSEE password policy mode if needed.	Limitation: password policies on (O)DSEE and OUD are decoupled.	Limitation: password policy state is reset during transition.

Table 3-2 Existing Directory Server Data

Existing Directory Server Data	Replication Gateway	DIP	Direct
Metadata: Role-based ACIs	Update DSEE ACIs before transition.	Update DSEE ACIs before transition or Adapt ACIs on OUD and do not synchronize ACIs.	Adapt ACIs.
Metadata: CoS/Roles	Adapt CoS/Roles. Optionally, extend DSEE schema (*).	Adapt CoS/Roles (not synchronized).	Adapt CoS/Roles.
Metadata: Password policies as sub entry (in the data)	Adapt password policies. Optionally, update password policies before transition.	Custom password policies not synchronized or adapted if possible.	Adapt password policies.
Invalid data in DSEE (do not fully match LDAP schema).	Fix data in DSEE or Relax schema checks on OUD or Update schema on OUD.	Fix data in DSEE or Relax schema checks on OUD or Update schema on OUD.	Fix data in DSEE or Relax schema checks on OUD or Update schema on OUD.

3.5 Identification of Relevant (O)DSEE Features using ds2oud

Oracle Unified Directory provides ds2oud, a diagnostic tool that automatically identifies (O)DSEE features that impact your transition.

In diagnostic mode, ds2oud can also identify (O)DSEE-specific features currently in use which do not have an exact counterpart on OUD. This includes Roles and Class of Services. The ds2oud tool is useful for every strategy as it transitions configuration and schema, and identifies (O)DSEE features that must be adapted. The ds2oud tool is especially useful when the Replication Gateway strategy is used because the gateway replicates directory metadata in addition to user data. This tool also analyses (O)DSEE schema and data to make sure they conform to the LDAP schema as implemented by OUD. For more information about running the ds2oud command in diagnostic mode, see ds2oud in Administering Oracle Unified Directory.