A Transitioning Synchronization Services

This appendix describes how to transition Identity Synchronization for Windows (ISW) configured with Microsoft Active Directory (AD) as the connected directory and Oracle Directory Server Enterprise Edition (ODSEE) as the backend to Oracle Directory Integration Platform (DIP). This section also includes information to configure DIP to synchronize the directory server sources to function as they previously functioned with ISW.

This appendix includes the following sections:

A.1 Understanding the Transition to Oracle Directory Integration Platform

The transition process described in this appendix allows you to replace an existing deployment of Identity Synchronization for Windows with Oracle Directory Integration Platform. The following sections can help you understand and plan this transition:

A.1.1 Transition Components

This transition process covers the following components:

  • Identity Synchronization for Windows 6.0 Service Pack 1 11g Release 1

    ISW is a component of Oracle Directory Server Enterprise Edition (ODSEE), formerly Sun Java System Directory Server. ISW includes a set of Core components (configuration directory, console, command-line utilities, system manager, and central logger), individual connectors, connector subcomponents, and Oracle Message Queue.

    ISW synchronizes user account information, including passwords, between ODSEE and Microsoft Active Directory. ISW requires two directory server instances: one instance for the user data that is synchronized and another instance for the ISW configuration data.

    For more information, see the Oracle Fusion Middleware Installation and Configuration Guide for Identity Synchronization for Windows 6.0.

  • Oracle Directory Integration Platform 11g Release 1 (11.1.1.9.0)

    DIP allows you to integrate your applications and directories, including third-party LDAP directories, with a master back-end directory being ODSEE, Oracle Internet Directory, or Oracle Unified Directory. DIP supports both uni-directional and bi-directional synchronization between ODSEE and Active Directory.

    The DIP back-end directory stores the DIP metadata and also serves as a synchronization endpoint. The DIP metadata information consists of the DIP-specific schema and directory information tree (DIT).

    For more information, see the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

In general, all the steps in the next sections requires compliance with the DIP certification matrix. To view this matrix:

  1. Go to the Oracle Fusion Middleware Supported System Configurations page:

    http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

  2. Find System Requirements and Supported Platforms for Oracle Fusion Middleware 11gR1 and open the xls file.

  3. In the xls file, click the FMW on WLS - Id&Access tab.

A.1.2 Using This Documentation

The goal of this appendix is to help you configure DIP, so you can synchronize your directory server to have the same functionality you previously had with ISW.

This appendix describes the transition steps to DIP and will help you find the equivalent basic ISW administration tasks in DIP.

This appendix considers only replacing an ISW deployment with DIP. If you also need to transition from ODSEE to OUD, see Chapter 1, "Understanding the Transition to Oracle Unified Directory."

A.1.3 Transition Process

Before the transition, ISW manages the synchronization between the ODSEE and Active Directory source directories. ISW uses one ODSEE instance for the user data that is synchronized and another ODSEE instance to store the ISW configuration data.

The transition process replaces ISW (and its components) with DIP (and its components) and moves the synchronization functionality from ISW to DIP.

After the transition is finished, DIP will manage the synchronization between ODSEE and Active Directory. DIP will then use only one ODSEE instance to store the user data and the DIP metadata that is synchronized. The ODSEE instance that stored the ISW configuration data before the transition will no longer be used.

A.2 Planning the Transition to Oracle Directory Integration Platform

The following sections can help you plan your transition from ISW to DIP:

A.2.1 Checking Compliance with the DIP Certification Matrix

The transition process described in Section A.4, "Executing the Transition to Oracle Directory Integration Platform" requires compliance with the DIP certification matrix.

To find and check the DIP certification matrix, see Section A.1.1, "Transition Components."

A.2.2 Comparing the ISW and DIP Functionality

The following sections provide a comparison of the features and functionality available in ISW and DIP:

A.2.2.1 ISW Functionality Available in DIP

The following table describes the ISW functionality that is also available in DIP.

Table A-1 Identity Synchronization for Windows Functionality Available in Oracle Directory Integration Platform

Functionality Identity Synchronization for Windows
 Oracle Directory Integration Platform

Synchronization scope

ISW supports Synchronization User Lists (SULs) that are the smallest synchronization units. An SUL contains a base DN from ODSEE and Active Directory that is mapped for synchronization. One or more SULs can be created under a single domain.

DIP supports domain mapping rules that allow multiple domains (DITs) to be mapped under a base DN.

Unlike ISW, DIP has all domains in a single profile share the same filter. However, DIP also allows users to have several profiles with multiple filters.

Direction of synchronization

ISW supports both uni-directional and bi-directional synchronization capabilities.

DIP achieves both uni-directional and bi-directional synchronization capabilities using export and import profiles. The type of profile (export or import) depends on the back-end.

Synchronization change types

ISW supports synchronization of add, modify, and delete operations, selectively. The selection can be modified anytime with the UI.

DIP supports synchronization of all LDAP operations, but it is not possible to select a subset of operation types to synchronize.

Password synchronization

ISW defaults to password synchronization. The synchronization of passwords cannot be avoided.

DIP provides synchronization of all LDAP attributes including user passwords.

User account creation, modification, and delete synchronization

Supported

Supported

User account activation and inactivation

ISW synchronizes account activation/inactivation between Active Directory and ODSEE and vice versa.

DIP synchronizes account activation/inactivation between Active Directory and back end and vice versa.

User account lockout/unlockout synchronization

ISW synchronizes lockout/unlockout events between Active Directory and ODSEE and vice versa. As a pre-requisite, the password policies at both ends are expected to be same.

DIP synchronizes lockout/unlockout events between Active Directory and the back end and vice versa. As a pre-requisite, the password policies at both ends are expected to be same.

Server redundancy

ISW has only one instance, so there is no redundancy.

Multiple instances of DIP can be configured in the WebLogic domain to synchronize the same endpoints. The DIP Quartz Scheduler takes care of providing the failover and load balancing capabilities.

However, like ISW, DIP does not provide redundancy when the configuration directory (back-end directory) is not available.

Failover support of endpoints

Supported

DIP does not support failover with ODSEE but does support failover with OUD.

Group synchronization

ISW has special hard-coded handling for group synchronization.

DIP achieves this functionality through a dnconvert() function that must be explicitly be added in the attribute mapping rules.

Synchronization with multiple Active Directory domains.

One or more Active Directory connectors can be installed to synchronize with a single ODSEE domain.

DIP achieves this functionality by setting up multiple export and import profiles between different Active Directory domains and the back-end endpoint.

DIP also provides a mechanism to handle Foreign Security Principals.

Reconciliation of pre-existing entries

ISW uses resynchronization functionality to run a refresh operation that synchronizes the pre-existing entries from ODSEE to Active Directory or vice versa. However, this operation does not synchronize user passwords.

DIP achieves this functionality by resetting the orclLastAppliedChangeNumber attribute to some older values, so that the pre-existing entries can be synchronized between the back end to Active Directory and vice versa.

Searchfilter

ISW supports specifying a search filter for each Synchronized User List (SUL).

DIP supports specifying one search filter per profile. You can achieve this filtering using an OR operator in the search filter. You can also have a different profile for a different domain mapping and search filter.

Domain exclusion list

ISW uses a search filter.

DIP supports providing the DomainExclusionList to exclude the changes for synchronization.

Logging

ISW supports log per connector and global logs.

DIP supports global logs.

A.2.2.2 ISW Functionalities Not Available in DIP

DIP does not support high availability (HA) with ODSEE.

A.2.2.3 DIP Functionalities Not Available in ISW

DIP supports the following features that are not available in ISW:

Table A-2 DIP Functionalities Not Available in ISW

Feature ISW DIP

Attribute Exclusion List

Not supported

DIP provides an AttributeExclusionList to exclude synchronizing a specified list of attributes.

Mapping functions

Not supported

DIP supports enhanced attribute mapping with mapping functions that operate on source attribute values to derive the destination attribute values.

Mapping plug-ins

Not supported

DIP allows you to enrich the mapping functions through a Java plug-in mechanism.

A.2.2.4 DIP Functionality That Requires a Plug-in

The following DIP functionality requires the ODSEE plug-in:

  • On demand password synchronization from the connected directory (Active Directory) to the backend directory

  • Translate password from the backend to the connected directory (Active Directory)

For both of these features, you must install the ODSEE plug-in, which is released with DIP. See "Installing Oracle Directory Server Enterprise Edition Plug-in" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

A.2.3 ISW Parameters to Consider in Planning the Transition

Before you begin the transition, consider the ISW parameters and configuration described in the following sections. You will then know if the transition from ISW to DIP will ensure that you have the same level of functionality.

Note:

Carefully read Section A.2.3.1, "ISW Deployment Considerations" and Section A.2.3.2, "Planning the Transition" so you will know if the transition from ISW to DIP will provide you with the same level of functionality, or if you also need to consider a transition from ODSEE to OUD.

A.2.3.1 ISW Deployment Considerations

Before you begin the transition, consider the following ISW parameters and configuration:

  • Synchronization direction of passwords

    These features require that you install and configure the ODSEE plug-in. You can find the ODSEE plug-in in one of the following locations in the Oracle Identity Management distribution package, depending on your platform:

    • On Windows systems: Disk1\utils\dip-plugin\dip-plugin.dll

    • On UNIX or Linux systems: Disk1/utils/dip-plugin/dip-plugin.so

    For more information, see "Installing Oracle Directory Server Enterprise Edition Plug-in" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

  • Synchronizing the creation of new users

    ISW allows you to not synchronize the creation of new users. DIP doesn't make any difference and considers an object creation as a synchronization. If the object doesn't exist, it will be created with the attributes defined in the mapping rules of the profiles. So all the attributes defined as mandatory in the schema need to have a mapping rules in the profile; if not, the first synchronization of the object (that is, creation) will fail.

    See the "Configuring Directory Synchronization" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

  • Number of Windows domains

    There is no limitation in DIP. Many profiles can be created.

  • High Availability (no changes lost when ISW goes down)

    When ISW is down, Message Queue keeps any changes already read. When ISW is up again, Message Queue and ISW synchronize the changes that occurred when ISW was down.

    To support high availability, DIP is deployed on an Oracle WebLogic Cluster that has at least two servers as a part of the cluster. Oracle WebLogic Cluster starts, stops, and monitors DIP in the cluster. See "Oracle Directory Integration Platform High Availability" in the Oracle Fusion Middleware High Availability Guide.

  • Security

    DIP, as ISW does, can manage connections over SSL, if SSL is required for your deployment.

  • Bidirectional account lockout and unlockout synchronization

    For these features to work correctly, set the symmetric password policy at both ends (the same as recommended for ISW).

  • Bidirectional group synchronization

    DIP allows you to manage group synchronization by using the uniquemenber attribute and dnconvert in the mapping rule.

  • Multi-Master Replication (MMR) Deployment:

    This item will have consequences in the transition to DIP. If Identity Synchronization for Windows is configured as an MMR deployment, consider the number of Directory Server masters, hubs, and read-only replicas in the deployment.

    In a deployment with multiple Directory Servers, the Identity Synchronization for Windows Directory Server Plug-in must be installed on each master, hub, and read-only replica. When configuring Identity Synchronization for Windows, one Directory Server master is designated as the preferred master. The Directory Server Connector detects and applies changes at the preferred master if it is running. If the preferred master is down, the Connector can optionally apply changes at a second master.

DIP (via WebLogic Cluster) can be configured in high availability (HA) mode, but it will talk to the same ODSEE instance. However, DIP can handle two OUD instances, so if you want to manage the second master, you must also plan a transition from ODSEE to OUD at the same time you are doing the transition from ISW to DIP.

The following table describes the differences in high availability (HA) and multi-master replication (MMR) deployments for ISW and DIP.

Table A-3 Differences for ISW and DIP in HA and MMR Deployments

Function Identity Synchronization for Windows
 Oracle Directory Integration Platform

High Availability (HA)

ISW does not support HA in the true sense. There is only one instance of ISW and if it goes down, no synchronization can be achieved. For other cases, ISW uses Message Queue, which stores the unapplied changes.

DIP deployed on a Oracle WebLogic Cluster can be configured in HA mode. See the Oracle Fusion Middleware High Availability Guide.

Multi-Master Replication (MMR)

ISW configuration allows you to specify a preferred and secondary master server. ISW can switch to the secondary server when the preferred server is down.

DIP configuration doesn't allow you to specify two ODSEE servers. However, if OUD is the backend, DIP supports two OUD instances behind a load balancer.

A.2.3.2 Planning the Transition

At this point, you should know which of the following cases you have, and you can plan your transition accordingly:

  • Your ISW configuration is not using replicated directory sources, so your plan is to transition ISW to DIP only. See Section A.4, "Executing the Transition to Oracle Directory Integration Platform."

  • Your configuration for ODSEE and ISW is in a multi-replicated directory source, so you might have two choices:

    • DIP will talk to your directory server master only, so your plan is to transition ISW to DIP only (same case as above).

    • You want a configuration with two directory server instances, so you must also transition ODSEE to OUD, which must be done before you transition from ISW to DIP. DIP will be then be configured with OUD as the backend.

The following table describes your transition choices.

Table A-4 Planning the ISW to DIP Transition

ISW Configuration DIP Configuration Transition to Plan

No replicated directory sources

No replicated directory sources

ISW to DIP

Replicated directory sources

No replicated directory sources

ISW to DIP

Replicated directory sources

Replicated directory sources

ODSEE to OUD

and

ISW to DIP

The transition from ODSEE to OUD is described in Chapter 1, "Understanding the Transition to Oracle Unified Directory."

The transition from ISW to DIP is described in the Section A.4, "Executing the Transition to Oracle Directory Integration Platform."

A.3 Components Involved in the Different Transition Steps

This section describes the components involved in the transition. Depending on your ISW configuration and the transition case you have selected (see Section A.2.3.2, "Planning the Transition"), the components involved in the transition are different, because the backend can be either ODSEE or OUD.

ODSEE is the Backend

If ODSEE is the backend, the following components are involved in the transition, as shown in Figure A-1:

  • Source directories that need to be synchronized: ODSEE (backend) and Active Directory (connected directory)

  • ISW (and its components) that will be replaced by DIP (and its components)

After the transition, synchronization will be managed by DIP and no longer by ISW. The directory servers are not changed.

Figure A-1 Components Involved in the Transition from ISW to DIP When ODSEE is the Backend

Description of Figure A-1 follows
Description of "Figure A-1 Components Involved in the Transition from ISW to DIP When ODSEE is the Backend"

OUD is the Backend

If OUD is the backend, the transition from ODSEE to OUD has already been done, and you are in an intermediate situation where ISW is synchronizing changes between Active Directory and ODSEE. ODSEE is replicated to OUD with one of the strategies described in Section 1, "Understanding the Transition to Oracle Unified Directory." DIP will be configured with OUD as the backend, and the components and the transition process are the same as described above, except for the directory backend.

A.4 Executing the Transition to Oracle Directory Integration Platform

This section describes the tasks to perform the transition from ISW to DIP, including:

A.4.1 Step 1: Collect Identity Synchronization for Windows Information

The purpose of this section is to help you collect all the ISW information needed to configure DIP. Fill in the tables in the following sections to order the data and to be able to create the DIP profiles:

A.4.1.1 Using the Identity Synchronization for Windows Console

Identity Synchronization for Windows provides an administration Console that centralizes the ISW configuration and administration tasks. You can use the ISW Console to:

  • Configure directory sources to be synchronized

  • Define mappings for user entry attributes to be synchronized, in addition to passwords

  • Specify the users and attributes within a directory or domain topology that will, or will not, be synchronized

  • Monitor system status

  • Start and stop synchronization

To login to the ISW Console, you must know the Administration Server URL (host name, domain name, and port), administrator (admin) credentials (user ID and password), and the ISW configuration password.

After you log in, you can access the various ISW tasks and configuration tabs to collect the ISW information needed to configure DIP during the transition.

A.4.1.2 ISW Servers Connection Information

If you need information about the ISW Console, see Section A.4.1.1, "Using the Identity Synchronization for Windows Console."

In the ISW Console, identify the following ISW Directory sources:

  • Sun Directory Server on ISW for the DIP back-end directory (ODSEE): host, port, user, and password

  • Active Directory on ISW for the DIP connected directory (Active Directory): host, port, user DN, and password.

Note:

Clear-text passwords are not retrievable from ISW, so you must get them by other means.

Save this information in a table for the transition to DIP. For example:

Table A-5 Directory Servers for Transition

DIP Server Host Non-SSL Port SSL Port Admin User Password

Backend Directory (ODSEE or OUD)

odsee-host

5389

5636

cn=Directory Manager

password1

Connected Directory (Active Directory)

ad-host

389

636

cn=Administrator,cn=Users,dc=example,dc=com

password2

A.4.1.3 Synchronization User Lists

For each Synchronization User List (SUL) in ISW, identify the following:

  • Sun Directory Server (ODSEE), identify the base DN: ou=people,dc=example,dc=com.

  • Windows Directory Source (Active Directory), identify the base DN: cn=users,dc=ad,dc=com synchronization list

These two base DNs will be translated in DIP as Domain rules source and destination. Save this information in a table for the transition to DIP. For example:

Table A-6 Synchronization User Lists for Transition

SUL Source Domain Name Destination Domain Name

SUL1

ou=people,dc=example,dc=com

cn=users,dc=ad,dc=com

SUL2

ou=people2,dc=example,dc=com

ou=isw-people2,dc=ad,dc=com

Each entry under ou=people,dc=example,dc=com and ou=people,dc=example,dc=com will be synchronized. The type of object synchronized under this container is determined by the attribute-level mapping rules that follow the DN mapping rules described in the next section.

You can also identify domains to be excluded during synchronization by adding a DomainExclusionList header in map files and identify domains to be excluded during synchronization.

A.4.1.4 ISW Configuration: Mapping User Attributes

ISW supports two types of attributes:

  • Significant: attributes that are synchronized between systems when you create or modify user entries.

  • Creation: attributes that are synchronized between systems only when you create user entries.

DIP synchronizes attributes between systems when you create or modify user entries. If a referenced object class requires the presence of a certain attribute, the object creation will fail if the attribute is not synchronized. This failure is caused when a mapping rule is not defined in the profile for the attribute. Once an attribute is defined in a mapping rule, it will be synchronized, and the object creation will succeed.

The goal of this section is to collect all the attribute mappings independently of the ISW types (creation and modification) and to sort them in the way that helps to create DIP profiles. So, consider the mapping of the following user attributes in the ISW configuration:

A.4.1.4.1 Map Attributes for Synchronization

If you need information about the ISW Console, see Section A.4.1.1, "Using the Identity Synchronization for Windows Console."

For each attribute listed in the ISW Console Attributes tab, map the attribute as shown in the following table:

Table A-7 Attributes to Map for Synchronization

Directory Server Attribute Active Directory Attribute

uniquemember

member

cn

cn

sn

sn

uid

SAMAccountName

userpassword

unicodepwd

If you are synchronizing passwords (On Demand password or Translate Password) you will need to install the ODSEE plug-in, which is part of DIP delivery, on the ODSEE backend.

For DIP, for each attribute you want to synchronize, you must write a mapping rule. Here is the definition of the attribute mapping rule format:

srcAttrName:[ReqAttrSeq]:[SrcAttrType]:[SrcObjectClass]:[dstAttrName]:[DstAttrType]:[DstObjectClass]:[MappingFuntion]

Note:

You must write an attribute mapping rule on a single line. If the above definition displays as two lines in your browser or viewer, it is formatting purposes only.

For more information, see "Configuring Mapping Rules" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

For examples, see "Supported Attribute Mapping Rules and Examples" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

A.4.1.4.2 Synchronization Flow

If you need information about the ISW Console, see Section A.4.1.1, "Using the Identity Synchronization for Windows Console."

From the ISW Console Object Creation tab, check the synchronization flow and create tables as follows:

  • From the backend (ODSEE or OUD) to Active Directory, you will need to create an export profile. Fill in an export table with the creation attributes.

  • From Active Directory to backend (ODSEE or OUD), you will need to create an import profile. Fill in the import table with the creation attributes.

Fill in the following tables below with the creation attributes and their objectclass.

Table A-8 Export Table: From ODSEE or OUD to Active Directory

ODSEE or OUD Attribute Active Directory Attribute

cn

cn

uid

SAMAccountName

userpassword

unicodepwd

Table A-9 Import Table: From Active Directory to ODSEE or OUD

Active Directory Attribute ODSEE or OUD Attribute

cn

cn

SAMAccountName

uid

unicodepwd

userpassword

A.4.1.4.3 Attributes Modification

If you need information about the ISW Console, see Section A.4.1.1, "Using the Identity Synchronization for Windows Console."

From the ISW Console Attribute Modification tab, for each attribute, check the synchronization flow to determine in which table (export, import, or both) you will have to add the attribute mapping.

Special case: Object activation/Inactivation with Active Directory

In ISW, there are three options to synchronize object activation and inactivation with Active Directory:

  • Interoperating with Directory Server tools

  • Modifying the Directory Server's nsAccountLock attribute directly

  • Using a custom method for Directory Server

In DIP, account activation and inactivation are configured with the Account Disabling feature. See "Account Disabling Synchronization" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

A.4.1.4.4 Groups Synchronization

ISW can be configured to work with "Domain Global Security" as well as "Domain Global Distribution" groups on Active Directory.

In DIP (as with ISW), you must use the following configuration. Map the following Directory Server attributes to Active Directory:

  • Directory Server uid to Active Directory SAMAccountName

  • Directory Server cn to Active Directory cn

If ISW group synchronization is enabled, specific mapping rules must exist in the DIP configuration.

# Mapping rules to map groups
cn           : : : groupofuniquenames:cn           : : groupofuniquenames :
member       : : : groupofuniquenames:member       : : orclgroup          :
uniquemember : : : groupofuniquenames:uniquemember : : orclgroup          :  
owner        : : : groupofuniquenames:owner        : : orclgroup          :

At this point, you should have filled the following tables with attribute mappings:

If an attribute is synchronized in both directions, a row should exist in both tables.

A.4.1.5 Account Disabling

If the account disabling feature is enabled in ISW, specific mapping rules will be added in DIP.

See "Account Disabling Synchronization" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

A.4.1.6 Synchronization Flow

Identify the synchronization flow of your data for the profiles you will need to create in DIP and identify the profiles by giving them a name. For example:

Table A-10 Synchronization Flow of Data for DIP Profiles

Flow Synchronization in ISW Table Type to Fill Profile Name Source Destination

From the back-end directory to the connected directory

Export

For example: ODSEEToAD

Back-end directory

Connected directory

From the connected directory to the backend directory

Import

For example: ADToODSEE

Connected directory

Back-end directory

A.4.1.7 Synthesis of ISW Configuration Data

The ISW data have been collected and are now ready to be sorted in order to prepare the DIP profiles. Here are the different tables that should have been filled.

Table A-11 Profiles Data for DIP

Flow Synchronization in ISW Table Type to Fill Source Destination

From ODSEE (or OUD) to Active Directory

Export

odsee-host

ad-host

From Active Directory to ODSEE (or OUD)

Import

ad-host

odsee-host

For an export table, identify the following information:

Table A-12 Export Table Information

Item ODSEE Source (backend) Active Directory Destination (connected directory)

Server name: host

odsee-host

ad-host

Server name: port

5389

389

Server name: SSLport

5636

636

Server name: password

odsee-host-password

ad-host-password

Server name: user

cn=Directory Manager

cn=Administrator,cn=Users,dc=ad,dc=com

Domain rules

ou=people,dc=example,dc=com

ou=isw-ou,dc=ad,dc=com

Domain Exclusion List

    

Identify the data for the export table and update Table A-13, "Export Attributes Mapping".

Table A-13 Export Attributes Mapping

Source (backend) ODSEE or OUD Attribute Name Source Attribute Object Class Destination (connected directory) Active Directory Attribute Name Destination Attribute Object Class

ou

organizationalUnit

ou

organizationalUnit

cn

inetorgperson

cn

inetorgperson

uid

inetorgperson

SAMAccountName

user

mail

inetorgperson

mail

user

sn

person

sn

user

Use Table A-14, "ISW Features Enabled in Direction Backend to Active Directory (Export)" to list the features that need to be translated in mapping rules in DIP if the features are enabled in ISW.

Table A-14 ISW Features Enabled in Direction Backend to Active Directory (Export)

Feature Enabled in ISW Yes/No

Password synchronization

yes

Group synchronization

no

Account activation/inactivation

yes

For an import table, identify the following information:

Table A-15 Import Table Information

Item Active Directory Source (connected directory) ODSEE Destination (backend)

Server name: host

ad-host

odsee-host

Server name: port

389

5389

Server name: SSLport

636

5636

Server name: password

ad-host-password

odsee-host-password

Server name: user

cn=Administrator,cn=Users,dc=ad,dc=com

cn=Directory Manager

Domain rules

ou=isw-ou,dc=ad,dc=com

ou=people,dc=example,dc=com

Domain Exclusion List

    

Identify the data for the import table and update Table A-16, "Import Attributes Mapping".

Table A-16 Import Attributes Mapping

Source Active Directory (connected directory) Attribute Name Source Active Directory Object Class Destination Backend (ODSEE or OUD) Attribute Name Destination Backend (ODSEE or OUD) Object Class

cn

user

cn

inetorgperson

SAMAccountName

user

uid

inetorgperson

sn

user

sn

person

Use Table A-17, "ISW Features Enabled in Direction Active Directory to Backend (Import)" to list the features that need to be translated in mapping rules in DIP if the features are enabled in ISW.

Table A-17 ISW Features Enabled in Direction Active Directory to Backend (Import)

Feature Enabled in ISW Yes/No

Password synchronization

Yes

Group synchronization

No

Account Activation/Inactivation

Yes

Now that you have collected all the information related to your ISW and ODSEE configuration, you must install and configure DIP, as described in the next sections.

A.4.2 Step 2: Backing Up the Backend Directory Data

Caution:

In subsequent transition steps, the DIP configuration modifies the schema, and an undo operation is not available. Therefore, Oracle recommends that you backup your existing backend data before you continue.

The backup operation might impact the backend service availability.

To back up your existing ODSEE data:

  1. Stop the ODSEE server instance:

    $ dsadm stop odsee-instance

  2. Backup the ODSEE data:

    $ dsadm backup odsee-instance ./backup-IDATA

  3. After the backup is completed, start the ODSEE server instance:

    $ dsadm start odsee-instance

If you later need to restore the data, use dsadm restore.

For more information about ODSEE, see the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Server Enterprise Edition.

To backup your OUD data, use the backup command. For more information, see "Backing Up and Restoring Data" in the Oracle Fusion Middleware Administering Oracle Unified Directory.

A.4.3 Step 3: Install Oracle Directory Integration Platform

You must install Oracle Directory Integration Platform, as described in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

A.4.4 Step 4: Configure Oracle Directory Integration Platform

To configure Oracle Directory Integration Platform:

  1. Run the dipConfigurator setup command in the Oracle home bin directory with the arguments in Table A-18.

    Table A-18 dipConfigurator Properties for Oracle Directory Server Enterprise Edition

    Properties Description

    wlshost

    Oracle WebLogic Server host name where Oracle Directory Integration Platform is deployed.

    wlsport

    Listening port number of the Oracle WebLogic Managed Server where Oracle Directory Integration Platform is deployed.

    wlsuser

    Oracle WebLogic Server login user name.

    ldaphost

    Oracle Directory Server Enterprise Edition host name, which is odsee-host.

    ldapport

    Oracle Directory Server Enterprise Edition server port number. The default value is 636.

    isldapssl

    Specify true or false to specify if ldapport is SSL or not.

    ldapuser

    The bind DN to connect to the Oracle Directory Server Enterprise Edition.

    isclustered <BOOLEAN>

    Specify if the Oracle Directory Integration Platform instance is in a cluster environment.

    clustercheckininterval <INT>

    Specify the frequency (milliseconds) at which an instance checks for server status (For example, detecting failed instances) with the other instances of the cluster.

    For example, on Linux and UNIX systems:

    $ ORACLE_HOME/bin/dipConfigurator setup -wlshost localhost -wlsport 7001 \ 
-wlsuser weblogic -ldaphost odseehost -ldapport 389 -ldapuser \ 
"cn=Directory Manager" -isldapssl true

    Or, on Windows systems:

    C:\> ORACLE_HOME\bin\dipConfigurator setup -wlshost localhost -wlsport 7001 \
-wlsuser weblogic -ldaphost odseehost -ldapport 389 -ldapuser \
"cn=Directory Manager" -isldapssl true

  2. Configure the Oracle Directory Integration Platform plug-ins by running the dipConfigurator setupPlugin command from the command line:

    $ ORACLE_HOME/bin/dipConfigurator setupPlugin -wlshost localhost \
-wlsport 7001 -wlsuser weblogic -ldaphost odseehost -ldapport 636 -ldapuser \
"cn=Directory Manager" -isldapssl true

    Note:

    You can view the dipConfig.log file at ORACLE_HOME /ldap/log/dipConfig.log.

  3. Start the Oracle Directory Server Enterprise Edition instance. For example:

    $ dsadm start instance-path

  4. Add ACIs by using the ldapmodify command. You can derive the suffix (dn: dc=example,dc=com in the example) from the information you previously collected. For example, using an LDIF file:

    $ ldapmodify -h localhost -p 389 -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

A.4.5 Step 5: Create Synchronization Profiles

The section describes the synchronization profiles creation, using the information you collected in the tables in "Step 1: Collect Identity Synchronization for Windows Information." You can use either the CLI or GUI to create these profiles, as described in the following sections:

When you install DIP, template profiles are created for synchronization with the different directory types, including ODSEE. The files used to create the template profiles, as well as property and mapping files, are available in the following directory:

ORACLE_HOME/ldap/odi/conf

Note:

After you create these profiles, do not enable them. You will enable them later in a subsequent step.

For more information, see "Creating Synchronization Profiles" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

See also "Password Synchronization Mechanism" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

A.4.5.1 Export Profile Creation

To create an export profile using the template files in the ORACLE_HOME/ldap/odi/conf directory:

  1. Make a copy of these export profile template files: activeexport.properties, activeexp.cfg.master, and activeexp.map.master and then rename them as ODSEEToAD.properties, ODSEEToAD.cfg, and ODSEEToAD.map, respectively.

  2. Update the ODSEEToAD.properties file, as follows:

    • Profile name: ODSEEToAD

    • Information related to your Active Directory server, such as host and port:

      • odip.profile.condirurl: ad-host.com:636:2

      • odip.profile.condiraccount: cn=Administrator,cn=Users,dc=mat,dc=com

      Copy this information from Table A-12, "Export Table Information".

    • File names for ODSEEToAD.cfg and ODSEEToAD.map:

      • odip.profile.configfile = ODSEEToAD.cfg

      • odip.profile.mapfile = ODSEEToAD.map

    • odip.profile.oidfilter = (no value)

  3. Edit the ODSEEToAD.cfg file, as follows:

    Writer: oracle.ldap.odip.gsi.ActiveWriter

  4. Update the ODSEEToAD.map file with the correct domain rules. Here is the structure of the map file:

    DomainRules
%USERBASE%:%USERBASE%:
AttributeRules
srcAttrName:[ReqAttrSeq]:[SrcAttrType]:[SrcObjectClass]:[dstAttrName]:[DstAttrType]:[DstObjectClass]:[MappingFuntion]

    The %USERBASE% of the DomainRules section will be filled with the info collected in Table A-12, "Export Table Information". For example:

    DomainRules:
ou=people,dc=example,dc=com :ou=isw-ou,dc=mat,dc=com:

    One profile could be created for each ISW SUL, but because a profile contains many domain rules, it is possible to create one profile for many SULs that have the same mapping rules.

    The lines in the AttributesRules section are the mapping rules. For DIP, for each attribute you want to synchronize from ODSEE (or OUD) to Active Directory, you must write a mapping rule using the mapping rule format described in "Configuring Mapping Rules" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

    For examples, see also "Supported Attribute Mapping Rules and Examples" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

    For the data you have collected from your ISW configuration, you must have a mapping rule for each row in Table A-19, "Required Mapping Rules for the Export Profile".

    Table A-19 Required Mapping Rules for the Export Profile

    Source (backend)ODSEE or OUD Attribute Name Source Attribute Object Class Destination (connected directory)Active Directory Attribute Name Destination Attribute Object Class

    ou

    organizationalUnit

    ou

    organizationalUnit

    cn

    inetorgperson

    cn

    inetorgperson

    uid

    inetorgperson

    SAMAccountName

    user

    mail

    inetorgperson

    mail

    user

    sn

    person

    sn

    user

    For example, here are the mapping rules for this table:

    # Organizational unit mapping
ou    : : :organizationalunit:ou        : :organizationalunit :
cn    : : :inetorgperson:cn             : :inetorgperson      :
uid   : : :inetorgperson:SAMAccountName : :user               :
mail  : : :inetorgperson:givenname      : :user               :
sn    : : :person:sn                    : :user               :

    Here are considerations for writing the mapping rules in Table A-14, "ISW Features Enabled in Direction Backend to Active Directory (Export)".

A.4.5.2 Import Profile Creation

To create an import profile using the example files in the ORACLE_HOME/ldap/odi/conf directory:

  1. Make a copy of these import profile template files located in ORACLE_HOME/ldap/odi/conf: activechgimp.properties, activechgimp.cfg and activechgimp.map and then rename them as ADToODSEE.properties, ADToODSEE.cfg, and ADToODSEE.map, respectively.

  2. Update the ADToODSEE.properties file, as follows:

    • Profile name: ADToODSEE

    • Information related to your Active Directory server, such as host and port:

    • File names for ADToODSEE.cfg and ADToODSEE.map:

      • odip.profile.configfile = ADToODSEE.cfg

      • odip.profile.mapfile = ADToODSEE.map

    • odip.profile.oidfilter = orclObjectGUID

  3. Edit the ADToODSEE.cfg file as follows:

    Reader: oracle.ldap.odip.gsi.ActiveChgReader

  4. Edit the ADToODSEE.map file with the correct domain rules.

    The %USERBASE% of the DomainRules section will be filled with the information collected in Table A-17, "ISW Features Enabled in Direction Active Directory to Backend (Import)". For example:

    DomainRules
ou=isw-ou,dc=mat,dc=com:ou=people, dc=example, dc=com :

    The mapping rules in the AttributeRules section are filled with content from Table A-17, "ISW Features Enabled in Direction Active Directory to Backend (Import)". For example:

    AttributeRules
# Attribute rules for Windows organizationalunit
objectguid     : :binary:top  :orclobjectguid:string:orclADObject   :bin2b64(objectguid)
cn             : :      : User:cn            :      : inetorgperson :
sAMAccountName : :      : User:uid           :      : inetorgperson :
sn             : :      : User:sn            :      : person        :

    Here are considerations for the writing the mapping rules in Table A-17, "ISW Features Enabled in Direction Active Directory to Backend (Import)".

    • Password Synchronization

      The following mapping rule is specific, because it uses a mapping function, OnDemandPassword.

      pwdLastSet : : : user : orclODIPPwdLastSet : : top : onDemandPassword(pwdLastSet)

      The orclSourceObjectDN attribute is needed by the plug-ins. It belongs to several objectClasses: orclSunOneObject, orclADObject, orclNDSObject, orclOpenLDAPObject, and orclTDSObject. A rule assigning this value must be included in the (import) profile, although the templates already include it. For example:

      targetdn: : :top:orclSourceObjectDN: :orclADObject:

      For more information, see "Password Synchronization Mechanism" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

      If you are synchronizing passwords (OnDemand Password feature), you will need to install the ODSEE plug-in, which is part of DIP delivery, on the ODSEE backend. (For OUD, the plug-in is part of OUD). See Section A.4.4, "Step 4: Configure Oracle Directory Integration Platform."

    • Group Synchronization

      The following mapping rules must be added:

      # Mapping rules to map groups
cn           : : :groupofuniquenames:cn           : :groupofuniquenames :
member       : : :groupofuniquenames:member       : :orclgroup          :
uniquemember : : :groupofuniquenames:uniquemember : :orclgroup          :
owner        : : :groupofuniquenames:owner        : :orclgroup          :

      See "Supported Attribute Mapping Rules and Examples" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

    • Account Activation/Inactivation

      The mapping rule is specific, as it is using a mapping function, AccountDisable ****. It depends on the backend.

      If ODSEE is the backend:

      userAccountControl:1:::nsAccountLock::top:AccountDisable(userAccountControl)

      If OUD is the backend:

      userAccountControl:1:::ds-pwp-account-disabled::top:AccountDisable(userAccountControl)

      See "Account Disabling Synchronization" in the in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

A.4.5.3 General Remarks About DIP Profiles

Several considerations about DIP profiles are:

  • One DIP profile must be created for one ISW Synchronization User List (SUL).

  • One DIP profile is for one direction: source to destination. If synchronization is done in both directions, two profiles must be created and associated.

A.4.6 Step 6: Create a Profile for Metadata Creation in Existing ODSEE Entries

This profile will be used to create all of the metadata used by DIP in the existing entries of ODSEE.

The metadata is normally created during synchronization or during bootstrap; however, because the metadata in ODSEE has not been created with either of these operations, it must be added in the existing entries.

This profile will be created to be used once, just after the synchronization stop on ISW and before the synchronization start on DIP. This profile will add the metadata in the entries that have been synchronized with ISW.

When you install DIP, template profiles are created for synchronization with the different directory types, including ODSEE. The files used to create the template profiles, as well as property and mapping files, are available in the following directory:

ORACLE_HOME/ldap/odi/conf

To create a profile for the metadata using the template files in the ORACLE_HOME/ldap/odi/conf directory:

  1. Make a copy of these template profile files: activechgimp.properties, activechgimp.cfg, and activechgimp.map, and then rename them as MetaDataImp.properties, and MetaDataImp.cfg, and MetaDataImp.map, respectively.

  2. Update the MetaDataImp.properties file as follows:

    • Profile name: MetaDataImp

    • Paths of the MetaDataImp.cfg and MetaDataImp.map files

    • Following flag:

      odip.profile.updateChangeNumberatCreate = false

      If this flag is set to true, the Last Change Number attributes are updated with the current time stamp.

  3. Modify the MetaDataImp.cfg file as follows:

    [INTERFACEDETAILS]
Reader: oracle.ldap.odip.gsi.ActiveChgReader

  4. In the MetaDataImp.map file, modify the domain mapping rules based on your data and requirements that you collected in Table A-15, "Import Table Information". Here is the mapping rule format:

    DomainRules
%USERBASE%:%USERBASE%:
AttributeRules
srcAttrName:[ReqAttrSeq]:[SrcAttrType]:[SrcObjectClass]:[dstAttrName]:[DstAttrType]:[DstObjectClass]:[MappingFuntion]

A profile could have many Domain Rules, so we could create one profile for many SULs.

For DIP, for each attribute you want to synchronize from ODSEE (or OUD) to Active Directory, you must write a mapping rule using mapping rule format.

For more information, see "Configuring Mapping Rules" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

For examples, see "Supported Attribute Mapping Rules and Examples" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

So, regarding the data you have collected from your ISW configuration, for each line in Table A-15, "Import Table Information", you must have a mapping rule.

Notes

  • The domain rules must be updated with the data you have collected from the ISW configuration.

    The %USERBASE% of the DomainRules section will be filled with the information you collected in Table A-15, "Import Table Information". For example:

    DomainRules
ou=isw-ou,dc=ad,dc=com:ou=people,dc=example,dc=com

  • The following mapping rules are mandatory:

    objectguid: :binary:top:orclobjectguid:string:orclADObject:bin2b64(objectguid)
distinguishedName: : :top:orclSourceObjectDN: :orclADObject:

  • The odip.profile.updateChangeNumberatCreate flag should be set to false.

The profile will be enabled after the synchronization is stopped for ISW.

A.4.7 Step 7: Stop the Synchronization on Identity Synchronization for Windows

It is strongly recommended that you stop the ISW server. At least, plan for a decrease of activity on both Active Directory and ODSEE, and then stop the synchronization on ISW.

Note:

Be sure to note the value of the last change number that has been applied, because it will be used in the last step to check that no changes have been lost.

To stop the synchronization, open a terminal window (or a Command Window) and type the idsync stopsync command. For example:

$ idsync stopsync -w admin-password -q configuration_password

A.4.8 Step 8: Uninstall the Identity Synchronization for Windows Plug-in in ODSEE

Before you uninstall the ISW plug-in, check for any existing entries in ODSEE that still require a bind (On-Demand Password synchronization). To find these entries, use ldapsearch to check for:

  • The userPassword attribute has the following value:

    userPassword: {PSWSYNC}*ON-DEMAND*SYNCHRONIZATION*REQUIRED*

    and/or

  • The dspswvalidate attribute is set to true.

If you find entries that still require a bind, add the orclODIPInvalidPassword attribute (value is true) to every entry where the dspswvalidate attribute is set to true. The bind will then be performed by the DIP ODSEE plug-in.

Then, you can uninstall the ISW plug-in.

To unconfigure the ISW plug-in, open a terminal window (or a Command Window) and type the idsync dspluginconfig command. For example:

$ idsync dspluginconfig -U -w admin password -q configuration_password

Or, use ldapmodify:

$ ldapmodify -h host.example.com -p 5389 -D "cn=Directory Manager" -w admin-password
dn: cn=pswsync,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled:off

Restart the ISW server, and then remove the dspswvalidate attribute from the entries.

A.4.9 Step 9: Update the Metadata in ODSEE by Running the DIP Tester Utility

The ODSEE entries that have been created through a synchronization done with ISW don't contain the metadata needed by DIP.

Note:

In a typical DIP/ODSEE configuration, the entries are created during synchronization or during bootstrap and contain the metadata needed by DIP. In the current case, the user entries have not been created with one of these operations but synchronized with ISW, and therefore, they don't contain the metadata.

To add this metadata, a profile must be created and used once. No synchronization will trigger this profile execution, so you must run DIP Tester either through Oracle Enterprise Manager Fusion Middleware Control or the CLI (using manageSyncProfile -testProfile). This profile must also be registered first.

Register the profile using manageSyncProfiles:

$ manageSyncProfiles register -h $WLSHOST -p 7005 -D weblogic -f MetaDataImp.properties -pf MetaDataImp

Then, run DIP Tester using either Oracle Enterprise Manager Fusion Middleware Control:

  • In the Advanced tab, set lastChangeNumber to 0.

  • In the Filtering tab, the Source Matching Filter and Destination Matching Filter should be unset.

Or, run manageSyncProfile from the command line:

$ manageSyncProfile -testProfile -h $WLSHOST -p 7005 -D weblogic -pf MetaDataImp -changenumber 0

The entries that were previously synchronized with ISW are now ready to be synchronized with DIP, and the profile can be deleted.

For more information, see:

A.4.10 Step 10: Enable the Profiles in DIP

The synchronization is activated in DIP when the profiles are registered and enabled.

To register, associate, and enable the profiles:

  1. Register the profiles:

    $ ORACLE_HOME/bin/manageSyncProfiles register -h $myWLSHOST -p 7005 \
-wlsuser weblogic -pf ODSEEToAD -file ODSEEToAD.properties

$ ORACLE_HOME/bin/manageSyncProfiles register -h $myWLSHOST -p 7005 \
-wlsuser weblogic -pf ADToODSEE -file ADToODSEE.properties

  2. If the data is synchronized in both directions and you have export and import profiles for the same source and destination, you must also associate the two profiles. This association prevents loops from occurring in bi-directional synchronization where changes initiated from one directory return to the same directory.

    Associate the profiles:

    $ ORACLE_HOME/bin/manageSyncProfiles associateProfile -h $myWLSHOST -p 7005 \
-wlsuser weblogic -pf ODSEEToAD -assopf ADToODSEE

$ ORACLE_HOME/bin/manageSyncProfiles associateProfile -h $myWLSHOST -p 7005 \
-wlsuser weblogic -pf ADToODSEE -assopf ODSEEToAD

  3. Enable the profiles (synchronization will start once the profiles are enabled):

    $ ORACLE_HOME/bin/manageSyncProfiles activate -pf ODSEEToAD

$ ORACLE_HOME/bin/manageSyncProfiles activate -pf ADToODSEE

For more information, see "Managing Directory Synchronization Profiles" the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

A.4.11 Step 11: Check for Any Remaining Changes in Identity Synchronization for Windows

Some changes might have occurred while ISW synchronization was stopped. Check that the last change number of your source has been applied on the destination.

DIP Tester allows you to perform synchronization tests and to return detailed log messages generated during the tests. See "Troubleshooting Synchronization Profiles Using DIP Tester" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

A.4.12 Step 12: Check the Synchronization

To verify that the synchronization is working correctly, modify an attribute on one server and check that it is correctly synchronized on the other server.

Note:

The On-Demand Password synchronization feature should be working in the same way it was working with ISW. When a password is modified in Active Directory, the orclODIPInvalidPassword attribute is added and set to true in the ODSEE entry, and a bind is required to update the userPassword attribute.

A.5 Basic Administration Tasks

Table A-20 describes some basic administrative tasks in ISW and how you perform the equivalent tasks in DIP. Here are documentation references for performing the DIP tasks in this table:

Table A-20 Basic Administrative Tasks in ISW and DIP

ISW Task Equivalent DIP Task Command-Line GUI

Configuring directory sources

Edit or create profile

manageSyncProfiles

Enterprise Manager

Configuring synchronization settings

Edit or create profile

manageSyncProfiles

Enterprise Manager

Configuring attribute settings

Edit or create profile

manageSyncProfiles

Enterprise Manager

Configuring attribute modification settings

Edit or create profile

manageSyncProfiles

Enterprise Manager

Configuring group synchronization settings

Edit or create profile

manageSyncProfiles

Enterprise Manager

Configuring synchronization user lists (SULs)

Edit or create profile

manageSyncProfiles

Enterprise Manager

Installing connectors and initializing data (idsync command)

Not applicable

Not applicable

Not applicable

Starting and stopping synchronization

Register and activate profile

manageSyncProfiles

Enterprise Manager

Starting and stopping services (ISW and Message Queue)

Start and stop WebLogic Server

WebLogic Scripting Tool, scripts

WebLogic Admin Console

DIP also has the following tools to test synchronization profiles:

A.6 After the Transition to Oracle Directory Integration Platform

In case you have considered only the transition to DIP and your backend is still ODSEE, you might reconsider transitioning ODSEE to OUD in a second step.

In you transition ODSEE to OUD, OUD will be considered as a fresh installation, and you will have to create new profiles with OUD as the server instead of ODSEE. The new profiles will be similar to ODSEE profiles, but the main changes will be connection information such as server names and port numbers. Some attribute names and values might also have to be updated.

For more information, see Chapter 1, "Understanding the Transition to Oracle Unified Directory."