3 Validating Your Transition Strategy

After choosing a strategy, the next step is to validate it. This chapter provides guidance for uncovering potential roadblocks and for validating your strategy choice. The following topics are included in this chapter:

• Section 3.1, "Validate the Selected Strategy"

• Section 3.2, "Considering DSEE Versions"

• Section 3.3, "Adapting (O)DSEE Legacy Features"

• Section 3.4, "Review: Impact of Technical (O)DSEE Characteristics"

3.1 Validate the 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 Chapter 2, "Choosing a Transition Strategy."

3.2 Considering DSEE Versions

The DSEE version impacts transition when replication gateway is used 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 the "Password Policy Compatibility" section of the Administrator's Guide for Oracle Directory Server Enterprise Edition. That document can be found in the Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7) library located at http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html

  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 needs to be at least an ODSEE 11gR1 (11.1.1.5) instance. If none is available, a ODSEE 11g must be added to the topology for use by the Replication Gateway. You can keep this ODSEE 11gR1 and its Replication Gateway located on the same box, or you can upgrade any existing instance to at least ODSEE11gR1 (11.1.1.5.)

  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 Adapting (O)DSEE Legacy Features

The following must be adapted for OUD use regardless of the strategy chosen:

• Role-based ACIs

• Roles and Class of Services (CoS)

• Custom Password Policies

3.3.1 Role-based ACIs

Role-based ACIs can be used to manage access to data, based on user role. Role-based ACIs are not supported by OUD 11g R2 Release 2 (11.1.2.2), 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 the Administrator's Guide for Oracle Directory Server Enterprise Edition. That document can be found in the Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7) library located at http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html

3.3.2 Roles and Class of Services (CoS)

(O)DSEE Roles and Class of Services must be replaced to equivalent OUD mechanisms as described in section Section 4.6.6, "Transitioning Roles to OUD," and Section 4.6.5, "Managing Class of Service (CoS)." In some cases, the corresponding OUD mechanism requires the use of directory metadata. For example, Class of Service definitions can be replaced by OUD Collective Attributes definitions stored along with user data.

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 see the Administrator's Guide for Oracle Directory Server Enterprise Edition. That document can be found in the Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7) library located at http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html

3.3.3 Custom Password Policies

Custom password policies can be stored 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 the Administrator's Guide for Oracle Directory Server Enterprise Edition. That document can be found in the Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7) library located at http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html

3.3.4 Managing 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

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	Deploy one ODSEE 11g instance as a gateway companion. 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 & don't 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.4.1 Using ds2oud to Identify Relevant (O)DSEE Features

OUD 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 Section A.2.3, "ds2oud," in the Administrator's Guide for Oracle Unified Directory.

The Administrator's Guide for Oracle Unified Directory can be found at http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html