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:
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."
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
The following must be adapted for OUD use regardless of the strategy chosen:
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
(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
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
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.
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 |
|
|
|
DSEE 6.x/7.x |
|
|
|
ODSEE 11gR1+ |
|
|
|
Table 3-2 Existing Directory Server Data
Existing Directory Server Data | Replication Gateway | DIP | Direct |
---|---|---|---|
Metadata: Role-based ACIs |
|
or
|
|
Metadata: CoS/Roles |
|
|
|
Metadata: Password policies as sub entry (in the data) |
|
|
|
Invalid data in DSEE (do not fully match LDAP schema). |
or
or
|
or
or
|
or
or
|
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