4 Deployment Configurations

This chapter discusses the following deployment configurations of Oracle Identity Manager:

• Provisioning Configuration

• Reconciliation Configuration

• Integration Between LDAP Identity Store and Oracle Identity Manager

4.1 Provisioning Configuration

Provisioning is the process by which any action to create, modify, or delete a target system identity initiated in the provisioning system (Oracle Identity Manager) is communicated to the target system. Changes made to the identity triggers a set of provisioning actions. For deployments on which Oracle Identity Manager has the identities in its own repository, changes made to the identity attributes are detected and the provisioning actions are triggered accordingly.

You can use Oracle Identity Manager to create, maintain, and delete users on target systems. In this configuration, Oracle Identity Manager acts as the front-end entry point for managing all the user data on the target systems. After accounts are provisioned, the users for whom the accounts have been provisioned can access the target systems without any interaction with Oracle Identity Manager. This is the provisioning configuration of Oracle Identity Manager.

The purpose of provisioning is to automate the creation and maintenance of users on target systems. Provisioning is also used to accommodate any requirement for workflow approvals and auditing that can be a component of that provisioning life cycle. Figure 4-1 illustrates the working of the provisioning module.

Figure 4-1 Provisioning Configuration

Description of "Figure 4-1 Provisioning Configuration"

Provisioning events can be started through any of the following ways:

• Request-based provisioning

  A request can be manually created by an administrator or, in certain instances, by users themselves. Approval workflows are started after a request is submitted and provisioning of the approved account profile is started after the approval is completed.

• Policy-based provisioning

  This type of provisioning refers to the automation of target resources being granted to users through access policies. Access policies are used to define the association between roles and target resources. By default, each member of these roles gets a predefined account in the target resource.

• Direct provisioning

  This type of provisioning is a special administrator-only function. An authorized administrator can create an account. An account for a particular user can be created on a target system without having to wait for any approval processes.

4.2 Reconciliation Configuration

Reconciliation is the process by which operations, such as user creation, modification, or deletion, started on the target system are communicated to Oracle Identity Manager. The reconciliation process compares the entries in Oracle Identity Manager repository and the target system repository, determines the difference between the two repositories, and applies the latest changes to Oracle Identity Manager repository.

Reconciliation of roles, role memberships, and role hierarchy changes are handled as separate reconciliation events. Ideally role events must be submitted first and then only the membership events in order to avoid race conditions. For race conditions, the automatic retry logic allows the reconciliation engine to handle it. More details in race condition section. For information about roles, role memberships, and role hierarchies, see "Managing Roles".

See Also:

"Handling of Race Conditions" for information about race conditions in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager

Figure 4-2 shows that provisioning and reconciliation involve synchronization from Oracle Identity Manager to the target system or from the target system to Oracle Identity Manager. Provisioning and reconciliation enable the provisioning system to build the managed identities in the target system as well as replicate the managed identities as they already exist in the target system.

Figure 4-2 Provisioning and Reconciliation

Description of "Figure 4-2 Provisioning and Reconciliation"

In Figure 4-2, a user is created by the HR representative when a new employee joins. The user is reconciled to Oracle Identity Manager by trusted source reconciliation. When the user is created in Oracle Identity Manager, the account for the user is provisioned in the target system. In the target system, the target system administrator can make changes in the account, which must be reconciled to Oracle Identity Manager.

In terms of data flow, provisioning provides the outward flow from the provisioning system by using a push model, in which the provisioning system indicates the changes to be made to the target system. Reconciliation provides the inward flow into the provisioning system by using either a push or a pull model, by which the provisioning system finds out about any activity on the target system.

The reconciliation process involves generation of events to be applied to Oracle Identity Manager. These events reflect atomic changes in the target system, and contain the data that has changed, the type of change, along with other information. The reconciliation events that are generated consequently because of changes occurring in the target system are managed by using the Reconciliation Event Manager in Oracle Identity Manager Administration console, which addresses these event management needs.

See Also:

"Managing Reconciliation" for information about managing reconciliation events by using Oracle Identity Manager Administration console in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager

This section consists of the following topics:

• Types of Reconciliation

• Reconciliation Architecture

4.2.1 Types of Reconciliation

Reconciliation can be of different types, as shown in Table 4-1:

Table 4-1 Types of Reconciliation

Classification Criteria	Reconciliation Type
Object being reconciled	Based on identity being reconciled, such as user, account, role, or relationship that includes role hierarchy and role membership Note: Oracle Identity Manager does not support reconciliation of organizations.
Mode of reconciliation	Changelog
	Regular
Approach used for reconciliation	Incremental reconciliation
	Full reconciliation

This section describes the following topics:

• Reconciliation Based on the Object Being Reconciled

• Mode of Reconciliation

• Approach Used for Reconciliation

4.2.1.1 Reconciliation Based on the Object Being Reconciled

Reconciliation depends on the entity object that is being reconciled. The following entities in Oracle Identity Manager are reconciled:

• User: A user is an identity that exists within and is managed through Oracle Identity Manager.

• Account: An account is granted to a user to give the user the ability to log in to Oracle Identity Manager and access Oracle Identity Manager features. At the minimum, these features involve self-service and request. An account can be granted additional privileges including the ability to define workflows and the delegated administration of various entities, such as users, organizations, and roles.

• Role: A role is a logical grouping of users to whom you can assign access rights within Oracle Identity Manager, provision resources automatically, or use in common tasks such as approval and attestation.

• Role hierarchy: Role hierarchy is the inheritance of the parent role to child roles. The parent role has the same permissions and privileges on the members as the inherited roles.

• Role membership: Role membership means that the members of the inheritor role inherit from the inherited role. See "Managing Roles" for detailed information about membership and permission inheritance.

This section discusses the following topics:

• Trusted Source Reconciliation

• Account Reconciliation

• Reconciliation Process Flow

4.2.1.1.1 Trusted Source Reconciliation

If data is reconciled from a system that drives the creation of users, roles, role memberships, or role hierarchies in Oracle Identity Manager repository, then that reconciliation mode is called identity reconciliation, or authoritative source reconciliation, or trusted source reconciliation. The system that is being reconciled from is referred to as the authoritative source for the enterprise identities, and may be an HR system or a corporate directory.

Note:

If the user login is not passed for trusted reconciliation, then the login handler generates the user login. The password is generated in postprocessing event handler, and notification is sent for the same. See "Customizing Reconciliation Operations" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about event handlers.

As shown in Figure 4-3, the authoritative sources of identity may be more than one. The different authoritative sources may be the source of reconciliation for different categories of user identities or may be the source of reconciliation for different sets of attributes. The various events generated by the reconciliation engine are add, modify, and delete.

Figure 4-3 Trusted Source Reconciliation from Single and Multiple Authoritative Sources

Description of "Figure 4-3 Trusted Source Reconciliation from Single and Multiple Authoritative Sources"

In Figure 4-3, trusted source reconciliation from a single authoritative source and multiple authoritative sources are shown. Creation of user entities can be reconciled from multiple authoritative sources. In addition, different attributes can be reconciled from different multiple authoritative sources. For example, the user ID and e-mail ID can be provided by an authoritative source and role attributes can be provided by another authoritative source.

Trusted source reconciliation must be followed by account reconciliation when the target system is the source for identities as well as accounts. For instance, if Active Directory is the corporate LDAP repository in which user information is stored, then the user information is reconciled from the Active Directory target system. Subsequently, the Active Directory accounts are reconciled into Oracle Identity Manager by using a different connector. Identity reconciliation occurs only from trusted sources, by using connectors specific to those trusted sources.

Note:

A reconciliation connector is a component developed to reconcile identities or accounts from a specific target system. Typically, a reconciliation connector is configured to be run as a scheduled task. However, there are push-based connectors, such as the PeopleSoft HR connector, for which there is no scheduled task to trigger the reconciliation.

4.2.1.1.2 Account Reconciliation

If the target system identities are accounts that get reconciled to Oracle Identity Manager, then that is target resource reconciliation or account reconciliation. This type of reconciliation is to reconcile a specific resource object that represents the target system being managed. There is always a corresponding provisioning flow for it. The identity retrieved from the target system maps to a resource object instance that has been provisioned to a user or organization.

Account reconciliation takes place in the following scenarios:

Scenario I

Identity gets created in Oracle Identity Manager from an authoritative source. The identities are provisioned with resources on the target system. Any change on the target system is reconciled with Oracle Identity Manager. Figure 4-4 shows account reconciliation from a target system:

Figure 4-4 Account Reconciliation From a Target System

Description of "Figure 4-4 Account Reconciliation From a Target System"

Scenario II

In this scenario, the target system initially plays the role of an authoritative source. Later it plays the role of a regular provisioning target. Following are the sequence of steps:

1. Identities are created in Oracle Identity Manager based on the target system entity details. Corresponding accounts are also created for these entities.

2. The entities are updated as provisioned entities in the target system.

3. The resource administrator at the target system makes changes to the accounts.

4. The changes made on the target system are reconciled with Oracle Identity Manager.

Figure 4-5 shows identity reconciliation followed by account reconciliation:

Figure 4-5 Identity and Account Reconciliation

Description of "Figure 4-5 Identity and Account Reconciliation"

Note:

When the value of the XL.UserProfileAuditDataCollection property is set to an audit data collection level, then the account reconciliation performs the matching in the database layer at a batch-level and performs the event action by using the provisioning APIs. This in turn triggers the audit event handlers for account reconciliation. By default, the value of this property is set to Resource Form. See "Administering System Properties" for information about system properties in Oracle Identity Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.1.1.3 Reconciliation Process Flow

The reconciliation process flow is shown in Figure 4-6:

Figure 4-6 Reconciliation Process Flow

Description of "Figure 4-6 Reconciliation Process Flow"

Reconciliation process involves the following steps:

1. Changes in the target system: The various activities that can happen in the target system are creation, modification, or deletion of user, account, role, role membership, or role hierarchy.

   Note:

   If you create an entity on an external system and then modify it a short time later, reconciliation processes the create entity step, but the modify entity step fails with the Creation Failed event status. This is because reconciliation cannot process a create and a modify action for the same entity in the same batch process.

   However, the entity modification action can be resubmitted for reconciliation at a later time by one of the following built-in mechanisms:

   • The "Automated Retry of Failed Async Task" scheduled task will run to re-process the failed events without any manual intervention. See "Automated Retry Error Handling Mechanism" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for details.

   • The failed event will be re-processed if the "Manual Retry Error Handling Mechanism" is triggered. See "Manual Retry Error Handling Mechanism" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for details.

   Reconciliation failure messages that are caused by processing conflicts within the same batch process should be regarded as transitory failures only.

2. Providing reconciliation data: When the creation, modification, or deletion event occurs, data about that event is sent to the reconciliation service by using reconciliation APIs.

   Note:

   Reconciliation service refers to the collection of reconciliation engine, reconciliation APIs, and the associated metadata and schema.

3. Creation of reconciliation event record: When the data for a reconciliation event is provided to reconciliation service, a record of that event is stored in Oracle Identity Manager repository.

4. Processing of the reconciliation event data: The data received is then evaluated to determine the actual operation to be performed in Oracle Identity Manager based on the changes in the target system. The evaluation involves application of a specific set of rules that help in:

   1. Identifying whether the data is for an account or for an identity that Oracle Identity Manager already has a record of

   2. Identifying the owner of the account or identity that the data represents

   3. Defining the context-sensitive action to be taken

   4. Setting the status of the event at the end of evaluation and the action that the reconciliation engine must take

5. Taking action on the event: Based on the evaluation result of processing the reconciliation event data, the intended action is taken. The various actions can be:

   Note:

   The actions on the event can be manually performed through the UI, or they can be automatic actions.

   • Creating a new account and associating with proper owner identity

   • Updating the matched account

   • Deleting the matched account

   • Creating a new user in Oracle Identity Manager

   • Modifying an existing user in Oracle Identity Manager

   • Deleting an existing user

   • Enabling and disabling account status by updating the status attribute

   • Enabling or disabling user

   • Creating, updating, or deleting role

   • Creating or deleting role membership

   • Creating or deleting role hierarchy

   See Also:

   "Reconciliation Engine" for information about role membership and role hierarchy

6. Follow up actions triggered by the reconciliation event: After the action is taken, follow up tasks can be started based on the reconciliation event. An example of follow up tasks or post-processing task is creating a request to provision a resource, such as a laptop computer, after a user creation event.

4.2.1.2 Mode of Reconciliation

The mode of reconciliation is either pull or push that depends on the connector used. Most connectors, such as Active Directory, use the pull model. For the pull model, a pull reconciliation task is scheduled in the IAM Scheduler. The task runs at recurring intervals.

See Also:

"Managing Scheduled Tasks" for information about the IAM Scheduler in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager

Typically, the pull-based reconciliation connectors submit the reconciliation events within a scheduled task. Every time the scheduled task runs, a new reconciliation run is triggered and the reconciliation events are created in batches. When the batch size is met, the batch is submitted for processing. At the end of the scheduled task, an end of job listener is triggered, which submits all the batches whose size is not met.

Other reconciliation connectors, such as the PeopleSoft connector, use a push model. The connector comprises of an HTTP listener that detects any asynchronous messages issued by PeopleSoft. On receiving a message, the listener submits reconciliation events by calling the reconciliation API. The events are processed by the reconciliation engine in batches when the batch size is met. For batches where batch size is not met, a scheduled task runs periodically and submits the batches for reconciliation processing.

Pull or push model is used based on the nature of the target system and how the changes can be detected in the target system. But irrespective of the push or pull model being used, reconciliation is performed by using a scheduled task that runs in the IAM Scheduler.

Note:

You can also create the reconciliation events directly by using the reconciliation APIs.

Changelog reconciliation is the default reconciliation mode. In this mode, only changed attributes are reconciled. Unspecified fields are ignored. You typically use the Changelog reconciliation mode when a connector is aware of the list of changed attributes. Along with the changed attributes, Oracle Identity Manager needs a list of required fields for matching. The Changelog reconciliation mode was supported in previous Oracle Identity Manager releases, so all connectors work in this mode.

Regular reconciliation is a new reconciliation mode, introduced in this release, where the reconciliation engine completely replaces the existing snapshot of the entity. You typically use this reconciliation mode when the connector cannot determine which attributes have changed, and therefore, sends an entire snapshot of the entity. For new connectors, you can specify this mode when performing a full reconciliation. Using regular reconciliation mode results in better performance because the events are processed faster.

Note:

The mode of reconciliation depends on the connector implementation. For information about connector implementation, see "Connector for Reconciliation".

Table 4-2 lists the differences between regular and changelog reconciliation modes:

Table 4-2 Regular and Changelog Reconciliation Modes

Regular	Changelog
Must pass a full set of mapped attributes	Must pass a subset of mapped attributes that are required by the specific profile and used by matching a rule
Performs better in batch processing mode (no difference in performance while in single event processing mode)
Creates and updates all fields	Creates and updates only specified fields, and all other fields remain unchanged

See Also:

"Changing the Profile Mode" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about changing the reconciliation mode

4.2.1.3 Approach Used for Reconciliation

When you run reconciliation for the first time on a target system, all users and accounts on the target system are reconciled into Oracle Identity Manager by default. This is called full reconciliation. To perform full reconciliation, the connector sends the reconciliation events for each entity in the target system. The reconciliation engine processes the events as create or update events depending on whether or not the entity already exists in Oracle Identity Manager. The connector also identifies all the deleted entries and sends the deletion events to Oracle Identity Manager.

At the end of full reconciliation, the connector typically sets the last execution time parameter to the time when the reconciliation run ends. For the next reconciliation run, only the entity records that have been added, modified, or deleted after the first reconciliation run ended are fetched for reconciliation. This is called incremental reconciliation.

You can manually switch from incremental reconciliation to full reconciliation by setting the value of the timestamp IT resource parameter to 0.

4.2.2 Reconciliation Architecture

Reconciliation is the process of pulling entity data from the target system into Oracle Identity Manager to keep the entity data in a consistent state between the two systems. The various components of Oracle Identity Manager involved in reconciliation and the interaction between these components are shown in the Figure 4-7:

Figure 4-7 Reconciliation Architecture

Description of "Figure 4-7 Reconciliation Architecture"

The reconciliation architecture is described in the following steps:

1. Each connector has scheduled tasks associated with it. The scheduler triggers the connector scheduled task, which invokes reconciliation APIs to generate events. The event can be of type Regular, Changelog, or Delete. For more information about the scheduler, see "Managing Scheduled Tasks" for information about the Scheduler in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager. For more information about scheduled tasks, see "Connector for Reconciliation".

2. The reconciliation events are stored in the reconciliation event repository, which is Oracle Identity Manager database.

3. When batch size is met, an asynchronous message is submitted which processes the batch of events in bulk. At the end of the schedule task another asynchronous message is submitted for processing the events of the last batch.

   Note:

   • In Figure 4-7, the reconciliation engine encapsulates the Action JAVA Layer as well as parts of the Reconciliation Event Repository, and orchestrates all the arrows in that diagram.

   • In this release, trusted source reconciliation is supported for users only. It is not supported for roles, role membership, and role hierarchy reconciliation.

   • In this release, Oracle Identity Manager supports trusted source reconciliation and account reconciliation for organizations.

4. The processing involves data validation, matching of the entities and action (create, update, delete and so on). This is followed by post processing via kernel orchestrations. For information about the action module, see "Action Module". For information about the reconciliation profile, see "New Metadata Model-Profile" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

5. By default the reconciliation event processing happens in bulk, and therefore all the steps till post processing are performed by PL/SQL stored procedures. Event can be processed one at a time in the following scenarios (in this case all the steps till matching are done in PL/SQL and the action is performed in java layer):

   • When events are processed from the Reconciliation Management console

   • When failed events are retried by the retry scheduled task that runs periodically

   For reconciliation single event processing, actions and post processing take place through the kernel.

6. Reconciliation events are made available to the Reconciliation Management console by another API call in the reconciliation management service.

The functionality of various components of the reconciliation service are explained in the following sections:

• Reconciliation Profile

• Reconciliation Metadata

• Reconciliation Target

• Reconciliation Run

• Reconciliation APIs

• Reconciliation Schema

• Reconciliation Engine

• Reconciliation Best Practices

• Connector for Reconciliation

• Archival

• Backward Compatibility

• Reconciliation Manager

4.2.2.1 Reconciliation Profile

A reconciliation profile is the configuration defined to govern how reconciliation is run for a particular resource. A particular resource can have multiple reconciliation profiles, each of which defines matching rules, action rules, and field mappings, which can differ in each profile corresponding to the resource. For example, while one reconciliation run can perform reconciliation of new and modified accounts, another reconciliation run can reconcile deletion of accounts because you might want to run the deletions only once a day. In this example, you define two reconciliation runs and two profiles. Each profile is associated with respective reconciliation run and each profile having its own rules of reconciliation.

The profile is an XML-based configuration file stored in Oracle Identity Manager MetaData Store (MDS).

There is always a default profile associated with reconciliation configurations for any resource object. The default profile can be explicitly generated from Oracle Identity Manager Design Console in the developer's environment or implicitly generated during import from the Deployment Manager. For details on how to create and update profiles, see "Managing Reconciliation Events" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.2.2 Reconciliation Metadata

The reconciliation metadata consists of various configurations used in creating and processing the reconciliation events. The reconciliation metadata is stored in a logical container called a profile. For information about reconciliation profile, see "Reconciliation Profile".

Examples of the reconciliation metadata are:

• Mapping rules: Used to map the data received from the target system to the data managed about that target system in Oracle Identity Manager.

• Matching rules: Used during the processing of each reconciliation event to correlate the event data to a particular account, user, or role in Oracle Identity Manager.

• Action Rules: Used to specify the actions taken by Oracle Identity Manager based on the result of the processing of a reconciliation event.

• List of target attributes: Used to define the data attributes received from the target system via reconciliation. It is used in the mapping rules, and is configured by using Oracle Identity Manager Design Console.

The various configurations used in creating and processing the reconciliation events are managed by using Oracle Identity Manager Design Console, and for backward compatibility, is stored in the same Oracle Identity Manager tables as in Oracle Identity Manager release 9.1.0. In addition, the configurations are also stored in the reconciliation profile.

Note:

For reconciliation in Oracle Identity Manager, a metadata model is being used. See "Managing Reconciliation Events" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.2.3 Reconciliation Target

Reconciliation target refers to an instance of an application that acts as a source of changes for Oracle Identity Manager. An example of reconciliation target is an HR system, which acts as a source of identities for Oracle Identity Manager. A reconciliation target can be a source of users or accounts.

4.2.2.4 Reconciliation Run

Reconciliation run refers to the combination of a reconciliation connector and associated configurations which when run by the scheduled task, performs the reconciliation based on the rules defined in the associated configurations. The scheduler runs reconciliation periodically at fixed intervals. Reconciliation runs are scheduled within Oracle Identity Manager scheduler to run at a specified frequency. All events created during a reconciliation run are grouped together by a unique reconciliation run ID.

4.2.2.5 Reconciliation APIs

These are a set of published APIs to provide reconciliation data to Oracle Identity Manager in the form of reconciliation events. Connectors can use the APIs to push data to the reconciliation event repository. Scheduled tasks can be setup to run the APIs when reconciliation is to be run on a scheduled basis. The existing connectors do not need to be changed because the existing APIs are supported.

4.2.2.6 Reconciliation Schema

The data that comes from the target system for reconciliation is stored in the reconciliation schema. The data contains the changes to be reconciled with Oracle Identity Manager.

Reconciliation schema refers to the set of schema tables to store the reconciliation data. The reconciliation schema is redesigned for performance reasons and future extensibility. See "Improved Database Schema" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information about the reconciliation schema.

4.2.2.7 Reconciliation Engine

The reconciliation engine uses all configurable components and includes the data processor and rule evaluator that use these components to convert input data into a list of action items. It also includes the components that determine whether or not the actions can be automated based on the rule context. When an action is performed, either automatically or manually, the engine performs the appropriate updates and provisioning actions.

The main task of the reconciliation engine is to perform the comparison, determine the action to be taken, and apply the action in Oracle Identity Manager. It contains two modules, which are described in the following sections:

• Matching Module

• Action Module

4.2.2.7.1 Matching Module

The matching rule specified in the profile is used to identify whether the record being searched, exists in Oracle Identity Manager or not. Matching rules are rules to identify whether the data is for an identity that Oracle Identity Manager already has a record of, or to identify the owner of the account in Oracle Identity Manager. When no record is found for the data of an account, an owner match is then performed to identify the owner of the account by using the matching rules.

For user and role entities owner matching is performed. For account entities, when no record is found, an owner match is then performed to identify the owner of the account.

For role membership events, matching is performed to identify role and user. For role hierarchy events, matching is performed to identity the parent and child role.

Note:

While performing role hierarchy and role membership reconciliation, the matching criteria must contain both Namespace and Role Name in the matching criteria. The following is an example of a matching rule:

((UGP.ugp_rolename=x) and (UGP.ugp_namespace=y))

Here, x is the name of the horizontal table name column that is mapped to Role Name, and y is the name of the horizontal column that is mapped to Namespace.

At the end of the evaluation, the match table contains all the possible matches found within Oracle Identity Manager that meet the criteria for the event, and the state of the event is updated to one of the statuses listed in Table 4-3:

Table 4-3 Reconciliation Status Events

Status Events	Description
Data Received	Event data has been created in the database and is ready for further processing.
Event Received	A reconciliation event has been created and is ready for further processing. The finishReconciliationEvent API has not yet been called.
Data Validation Failed	The reconciliation event record is invalid. For example, a role event with an invalid role category will fail to validate. (This situation could indicate a race condition.) The RE_NOTE field should contain the details of the failure, which is also displayed in the user interface.
Data Validation Succeeded	The event data was successfully validated and the event can now safely be processed by the Engine.
Multiple Accounts Match Found	Given the current matching rules, multiple matching account records were found for the data.
No Account Match Found	Given the current matching rules, no matching account records were found for the data.
Single Account Match Found	Given the current matching rules, one matching account record was found for the data.
Multiple Org Matches Found	Given the current matching rules, multiple matching organization records were found for the data.
No Org Match Found	Given the current matching rules, no matching organization records were found for the data.
Single Org Match Found	Given the current matching rules, one matching organization record was found for the data.
Multiple Role Grants Match Found	Multiple matching records for user membership within a role were found.
No Role Grant Match Found	No matching records for user membership within a role were found.
Single Role Grant Match Found	One matching record for user membership within a role was found.
Multiple Roles Match Found	Given the current matching rules, multiple matching role records were found for the data.
No Role Match Found	Given the current matching rules, no matching role records were found for the data.
Single Role Match Found	Given the current matching rules, one matching role record was found for the data.
No Role Members Found	The Reconciliation Engine did not find role members matching the data, given the current matching rules.
No Role Parent Found	The Reconciliation Engine did not find a role matching the data, given the current matching rules.
Multiple Role Relationships Match Found	Given the current matching rules, reconciliation has found multiple role-to-role relationships that match data in the event.
No Role Relationship Match Found	Given the current matching rules, reconciliation did not find any role-to-role relationships that match data in the event.
Single Role Relationship Match Found	Given the current matching rules, reconciliation has found one role-to-role relationship that matches data in the event.
Multiple Users Match Found	Given the current matching rules, multiple matching user records were found for the data.
No User Match Found	Given the current matching rules, no matching user records were found for the data.
Single User Match Found	Given the current matching rules, one matching user record was found for the data.
Invalid Event Data Passed	The event contains invalid data. This status pertains to the e-mail attribute.
Being Re-evaluated	The reconciliation event is being reevaluated from the reconciliation management console.
Being Re-tried	The reconciliation event is being retried automatically. This status event has been deprecated.
Creation Failed	The user/account/role entity was not created successfully.
Creation Succeeded	The user/account/role entity was created successfully.
Delete Failed	The user/account/role entity was not successfully deleted.
Delete Succeeded	The user/account/role entity was deleted successfully.
Event Closed	The reconciliation event was closed from the reconciliation management console. The change is complete.
Update Failed	The user/account/role entity was not updated successfully.
Update Succeeded	The user/account/role entity was updated successfully.

4.2.2.7.2 Action Module

This module applies the action based on the event state, entity type, and the action rules, as listed in Table 4-4:

Table 4-4 Action Rules

Event State	Entity Type	Action	Description
No User Match Found	User	No Action	Does not perform any action
		Create User	Creates a user in Oracle Identity Manager
No Account Match Found	Account	No Action	Does not perform any action
User Matched	User or Account	No Action	Does not perform any action
	User	Establish Link	Modifies or deletes the matched user based on the change type
	Account	Establish Link	Owner identified - creates an account
Users Matched	User or Account	No Action	Does not perform any action
Account Matched	Account	No Action	Does not perform an action
		Establish Link	Modifies or revokes the account based on the change type
Accounts Matched		No Action	Does not perform any action
No Role Match Found	Role	No Action	Does not perform any action
Single Role Match Found	Role	No Action	Does not perform an action
		Establish Link	Modify or delete a role
	Role Membership	Create role membership	Grant a role member to Oracle Identity Manager
		Delete role membership	Delete a role member from Oracle Identity Manager
		No action	Does not perform an action
	Role Hierarchy	Create role hierarchy	Creates a role hierarchy in Oracle Identity Manager
		Delete role hierarchy	Delete a role hierarchy in Oracle Identity Manager
		No action	Does not perform an action
Multiple Roles Matched	Role, Role membership and Role Hierarchy	No action	Does not perform an action
No Role Grant Match Found	Role Membership	No Action	Does not perform an action
		Create Role Member	Creates a role member in Oracle Identity Manager
Single Role Grant Match Found	Role Membership	No action	Does not perform an action
		Establish Link	Delete role member
Multiple Role Grant Match Found	Role Membership	No action	Does not perform an action Note: This state does not occur because the role grant match is done by looking for the primary key, which is a combination of the usr key and the group key.
No Role Parent Match Found	Role Hierarchy	No Action	Does not perform an action
		Create role parent	Create a role parent in Oracle Identity Manager
Single Role Parent Match Found	Role Hierarchy	No Action	Does not perform an action
		Establish Link	Delete role parent
Multiple Role Parent Match Found	Role Hierarchy	No Action	Does not perform an action
Data Validation Failed	Role, Role Hierarchy, Role Member	Race condition	Does not perform an action. The event needs to be re-evaluated.
Parent role not found	Role Hierarchy	Race condition	Does not perform an action. The event needs to be re-evaluated.
Role member not found	Role membership	Race condition	Does not perform an action. The event needs to be re-evaluated.

4.2.2.8 Reconciliation Best Practices

This section describes how to improve performance by identifying indexes that are required for connector tables and reconciliation tables. It contains the following topics:

• Additional Indexes Requirement for Matching Module

• Collecting Database Schema Statistics for Reconciliation Performance

4.2.2.8.1 Additional Indexes Requirement for Matching Module

When Oracle Identity Manager is installed, the necessary indexes are created in the Oracle Identity Manager database schema. However, there can be additional indexes required because of dynamic nature of some of the features in Oracle Identity Manager. This is especially true for reconciliation.

Reconciliation uses matching algorithm to find if the user/account/role/organization for which the change is requested is already existing in Oracle Identity Manager or not. The matching algorithm compares the data in set of columns in Oracle Identity Manager with the data in target horizontal table columns. The columns that contains the matching rules are defined in the reconciliation profile. To improve the performance of the matching operation quickly, there must be correct indexes created on the matching rule columns.

To illustrate the recommended method of identifying the appropriate indexes, a sample Active Directory (AD) user profile present in the Meta Data Store (MDS) repository is taken as an example. In this example, trusted source as well as target resource reconciliation are covered.

Selecting Indexes for Trusted Source Reconciliation

To select indexes based on the matching rule criteria in trusted source and target resource reconciliation:

1. Open the AD user profile file in a text editor.

   Note:

   The AD user profile must be imported from the MDS by using the MDS utilities. See "MDS Utilities and User Modifiable Metadata Files" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about the MDS utilities.

2. Search for ownerMatchingRuleWhereClause for all entities, as shown in the following figure with code sample:

   
   

   Here, the ownerMatchingRuleWhereClause is the following:

   ownerMatchingRuleWhereClause = (((UPPER(USR.USR_LOGIN)=UPPER(RA_ADUSER7.RECON_USERID5A729570)) OR (UPPER(USR.USR_UDF_OBGUID)=UPPER(RA_ADUSER7.RECON_OBJECTGUID))))
   

3. After identifying the columns constituting the matching rule in the user entity, create the indexes accordingly.

Note:

• If any key field is defined in Oracle Identity Manager as case-insensitive, then a function-based index on that key field must be created. For example, if the connector code internally performs a search for the first name, assuming that FIRST_NAME is a key, then appropriate indexing must be done.

• If multiple or composite keys are used for looking up a user, then choose between individual or composite indexes.

Selecting Indexes for Target Resource Reconciliation

To select indexes based on the matching rule criteria in target resource reconciliation:

1. Open the AD user profile file in a text editor.

   Note:

   The AD user profile must be imported from the MDS by using the MDS utilities. See "MDS Utilities and User Modifiable Metadata Files" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about the MDS utilities.

2. Search for account search tag <matchingruleWhereClause>, as shown in the following figure:

   
   

   Here, the <matchingruleWhereClause> is the following:

   <matchingruleWhereClause>((UD_ADUSER.UD_ADUSER_OBJECTGUID=RA_ADUSER7.RECON_OBJECTGUID))</matchingruleWhereClause>
   

3. After identifying the columns constituting the matching rule in the user entity, create the indexes accordingly.

Selecting Indexes for Target Resource Reconciliation With Multi-Valued Data

To select indexes based on the matching rule criteria in target resource reconciliation with multi-valued data:

1. Open the AD user profile file in a text editor.

   Note:

   The AD user profile must be imported from the MDS by using the MDS utilities. See "MDS Utilities and User Modifiable Metadata Files" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information about the MDS utilities.

2. For entitlements, search for the <matchingruleWhereClause> tag under <childreconeventdata>.

   
   

   Here, the <matchingruleWhereClause> tag is the following:

   <matchingruleWhereClause>((UD_ADUSRC.UD_ADUSRC_GROUPNAME=RA_UD_ADUSRC.RECON_MEMBEROF))</matchingruleWhereClause>
   

3. After identifying the columns constituting the matching rule in the user entity, create the indexes accordingly.

Note:

Pointers for required indexes can also be taken by monitoring the real-time running of reconciliation process from the database side by using a performance-monitoring tool, such as Oracle Enterprise Manager Console, or through the Automatic Workload Repository (AWR) Reports available in Oracle Database 11g.

4.2.2.8.2 Collecting Database Schema Statistics for Reconciliation Performance

Database statistics is essential for the Oracle optimizer to select an optimal plan in running the SQL queries. Oracle recommends that the statistics are collected regularly for Oracle Identity Manager schema. Because Oracle Identity Manager 11g Release 1 (11.1.1) uses lot of database SQL features for reconciliation process, make sure that the schema statistics are updated before running the reconciliation.

Note:

• Other options with DBMS_STATS.GATHER_SCHEMA_STATS API can be used as required, such as DEGREE,ESTIMATE_PERCENT based on the environment, data profile, Oracle DB Edition and underlying hardware capabilities.

• See "Database Performance Monitoring" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information about collecting database schema statistics.

Because Oracle Identity Manager reconciliation process is a data-intensive process and quickly brings in large volume of data, database statistics must also be able to represent the underlying data correctly. To achieve this, refer to the following guidelines:

• Make sure that statistics is collected for reconciliation on a fresh setup or with a low volume with no or negligible existing data in the Oracle Identity Manager schema. Maximum row count in relevant Oracle Identity Manager tables must be between 100 and 1000 rows. Examples of tables are USR table for trusted source reconciliation and parent account table for target resource reconciliation.

• For the statistics to be a proper representative of data distribution after reconciliation has started and is expected to bring in a large volume of data, such as more than 20000 users or accounts, collect Oracle Identity Manager schema statistics in the following manner:

  1. Plan to gather statistics after the initial collection only after reconciliation has started successfully and has been running for a while. To verify this, check the counts of a few key tables from the Oracle Identity Manager schema, such as USR table for trusted source reconciliation and parent account (UD_*) tables for target resource reconciliation.

  2. After reconciliation has brought in almost 20000 to 25000 rows in the USR table or in the parent account tables, statistics can be collected.

     Note:

     • Statistics can be gathered concurrently with reconciliation running.

     • The row counts specified in the guidelines are examples and you can determine any other row count for collecting statistics.

• After the statistics is collected, the performance might not improve immediately. However, as older SQL Plans are cleared from the shared pool of the Oracle Database, new and more efficient plans are created and performance improves.

4.2.2.9 Connector for Reconciliation

The connector refers to the software that extracts the changes from the target system and creates events in the reconciliation schema by calling the reconciliation APIs. If the connector that you want to use is shipped with a predefined reconciliation module, then a scheduled task definition is available. You use this component to control the frequency at which the target system is polled for changes to track data and other connector-specific parameters.

The connector for reconciliation is deployed by using the Deployment Manager. When the connector is deployed, the corresponding reconciliation profile for that connector is created in the metadata store (MDS), and horizontal tables that store the event data are also created.

Note:

Do not manually update reconciliation profile or update any reconciliation configurations from the Deployment Manager or Oracle Identity Manager Design Console when a reconciliation run is still in progress. This is because, if a reconciliation field is deleted or updated when a reconciliation run is in progress, then the event data might not be valid any more.

For information about configuring connectors, see Oracle Identity Manager Connector documentation.

See Also:

• "Reconciliation Metadata" for information about MDS

• "Horizontal Tables" for information about the horizontal tables in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.2.10 Archival

The Reconciliation Archival utility allows you to move processed events from the active reconciliation tables to archive tables. The events to move can be selected based on a time range. Only linked and closed events, which means successfully processed or closed by an administrator, can be archived.

See Also:

"Using the Reconciliation Archival Utility" for information about how to use the Reconciliation Archival utility in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.2.2.11 Backward Compatibility

You do not need to change the existing reconciliation configurations or scheduled tasks to leverage the new reconciliation service.

The existing configurations for reconciliation setup in earlier Oracle Identity Manager releases continues to function after upgrading to 11g Release 1 (11.1.1). As part of the upgrade, corresponding reconciliation event tables are created for each of the existing object types being reconciled.

4.2.2.12 Reconciliation Manager

The Reconciliation Manager is a Web-based UI, which is a part of Oracle Identity Manager Administrative and User Console. The Reconciliation Manager lets you view and manage reconciliation events generated by Oracle Identity Manager reconciliation engine. These events are generated through scheduled reconciliation runs. The Reconciliation Manager provides search capabilities on reconciliation runs as well as events. Users can use the Reconciliation Manager to perform reconciliation manually on generated events.

See Also:

"Managing Reconciliation Events" for more information about the Reconciliation Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.3 Integration Between LDAP Identity Store and Oracle Identity Manager

Oracle Identity Manager users and roles are stored in Oracle Identity Manager database. However, when a user, role, or role membership change takes place in Oracle Identity Manager, this information is propagated to LDAP identity store. If user, role, or role membership change takes place in LDAP directly, then these changes are synchronized into Oracle Identity Manager. The synchronization involves:

• User creation, modification, deletion, change in enable or disable states, and password change are made in LDAP in addition to the internal Oracle Identity Manager tables.

• Role creation, modification, and deletion actions update the LDAP groups, including membership changes.

• Initial load of users, roles, and role memberships are synchronized.

• Direct changes to user profile in LDAP are reconciled to Oracle Identity Manager.

• Direct changes to roles and role memberships in LDAP are reconciled to Oracle Identity Manager.

When changes are made in the user and role data, the actual operation is performed with the help of the kernel handlers. These handlers go through an orchestration lifecycle of various stages, such as validation, preprocessing, action, and postprocessing. For more information about the various stages of kernel orchestration, see Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

Oracle Identity Manager kernel orchestration connects to the Entity Manager, which in turn connects to the LDAP provider. The LDAP provider connects to Oracle Virtual Directory (OVD). The OVD is an interface to various directory systems, such as Oracle Internet Directory, iPlanet, and Active Directory. The LDAP provider reaches the LDAP data by using OVD. Figure 4-8 shows the communication between Oracle Identity Manager and LDAP:

Figure 4-8 Oracle Identity Manager and LDAP

Description of "Figure 4-8 Oracle Identity Manager and LDAP"

The integration configuration and synchronization of data between Oracle Identity Manager and the LDAP identity store are described in the following sections:

• Configuring the Integration with LDAP

• Provisioning Data From Oracle Identity Manager to LDAP Identity Store

• Reconciliation From LDAP Identity Store to Oracle Identity Manager

4.3.1 Configuring the Integration with LDAP

Configuring the integration between Oracle Identity Manager and LDAP is performed while installing Oracle Identity Manager. You can choose to install Oracle Identity Manager with or without LDAP. If you install Oracle Identity Manager with LDAP, then you must install OVD and Oracle Internet Directory, create a container to store reserved users, create a new user in Oracle Identity Manager to perform Oracle Identity Manager operations, and configure OVD and Oracle Internet Directory for Oracle Identity Manager. For information about how to perform these configuration steps, see "Setting Up LDAP Synchronization" in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

After installing Oracle Identity Manager with LDAP enabled, you must open the following scheduled jobs and update their Last Change Number parameter with the last changelog number value of Oracle Internet Directory:

• LDAP User Create and Update Reconciliation

• LDAP User Delete Reconciliation

• LDAP Role Membership Reconciliation

• LDAP Role Hierarchy Reconciliation

• LDAP Role Create and Update Reconciliation

• LDAP Role Delete Reconciliation

In addition, you must enable these scheduled jobs after updating the Last Change Number parameter. To do so, see "Disabling and Enabling Jobs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

See Also:

"Managing Scheduled Tasks" for detailed information about scheduled jobs in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

4.3.2 Provisioning Data From Oracle Identity Manager to LDAP Identity Store

Oracle Identity Manager database stores the user and role information. When the user and role information is updated in Oracle Identity Manager, then the external repositories, such as the LDAP directory, must also be updated.

The LDAP changes are performed before Oracle Identity Manager changes. If Oracle Identity Manager changes fail, then the LDAP changes must be reverted to the original state. This is achieved by correcting an enable operation with a disable operation, a create operation with a delete operation, and a modification operation with another modification operation with the original values.

For instance, when a user is created, the validation processes are performed in the validation stage, such as password or any other policy validation. In the preprocessing stage, the user is created in LDAP first. Then, in the action stage, the user is to be created in Oracle Identity Manager. If there is an error in creating the user in Oracle Identity Manager, then the user must be deleted from LDAP because the corresponding user could not be created in Oracle Identity Manager. The operation to revert the change made is provided by the kernel handlers through the compensation method, which is predefined in Oracle Identity Manager.

Note:

Each handler has predefined execute and compensate methods. The execute method runs any operation, such as creating a user. The compensate method is called when an error occurs to revert the operation performed by the execute method.

To synchronize date from Oracle Identity Manager to LDAP, the location of the LDAP must be known to Oracle Identity Manager. The information about the LDAP location is stored in Oracle Identity Manager as the DirectoryServer IT resource. This is a default IT resource provided by Oracle Identity Manager. The various parameters of this IT resource, which you can specify while installing Oracle Identity Manager, allows the connection between Oracle Identity Manager and LDAP.

In order to identify the same entry in Oracle Identity Manager and LDAP, the Distinguished Name (DN) and GUID attributes are used. Each entry has the DN attribute in LDAP, which indicates the unique location of an entry in LDAP. The GUID attribute is an unique ID to identify the entry. The DN and GUID for users and roles are stored in columns in the users and role tables in Oracle Identity Manager database. For information about how to synchronize user-defined fields between Oracle Identity Manager and LDAP, refer "Synchronizing User-Defined Fields Between Oracle Identity Manager and LDAP" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

This section describes the following topics:

• Managing Users

• Managing Roles

4.3.2.1 Managing Users

The following user operations can be performed to synchronize data from Oracle Identity Manager to LDAP:

• Create user

• Update user

• Delete user

• Enable user

• Disable user

• Lock user

• Unlock user

• Add role member

• Delete role member

• Change password

4.3.2.2 Managing Roles

The following role operations can be performed to synchronize data from Oracle Identity Manager to LDAP:

• Create role

• Update role

• Delete role

• Add role to a member

• Add and Update role

• Remove role from a member

• Add role hierarchy

• Remove role hierarchy

4.3.3 Reconciliation From LDAP Identity Store to Oracle Identity Manager

When changes in the identities are made directly in the LDAP identity store, the changes must be replicated to Oracle Identity Manager through authoritative source reconciliation. The identities include users and roles.

Reconciling users from LDAP to Oracle Identity Manager works with the general configuration of reconciliation, which includes the scheduled tasks for reconciliation.

See Also:

• "Reconciliation Configuration" for detailed information about reconciliation

• "Managing Scheduled Tasks" for information about scheduler and scheduled tasks in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

Note:

Instead of using LDAP synchronization reconciliation jobs to reconcile users from LDAP to Oracle Identity Manager, if the Bulk Load utility is used, then subsequent operation on these users might fail if LDAP synchronization is enabled. To avoid this, all the users that are loaded in Oracle Identity Manager must be updated with correct GUID and DN values, and all these users in LDAP must be updated with an object class called orclIDXPerson.

For detailed information about the Bulk Load utility, see "Bulk Load Utility" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

The role reconciliation works only with the LDAP groups. Role reconciliation supports creation, updation, and deletion of roles. Role membership reconciliation supports creation and deletion of role memberships being driven from changes in an external LDAP directory.

See Also:

Chapter 12, "Managing Roles" for information about roles, role memberships, and role hierarchies

Without roles and users being present in Oracle Identity Manager, role membership reconciliation will fail. Therefore, configure the LDAP synchronization scheduled jobs to run in the following order:

1. Fusion Applications Role Category Seeding

   Note:

   Fusion Applications Role Category Seeding is a predefined scheduled task that is generated only when LDAP synchronization is enabled, along with other LDAP synchronization scheduled jobs. This job gets all distinct business categories in LDAP and creates them as OIM role categories.

   For a list of the predefined scheduled jobs, see "Predefined Scheduled Tasks" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

2. LDAP Role Create and Update Reconciliation

3. LDAP Role Hierarchy Reconciliation

4. LDAP User Create and Update Reconciliation

5. LDAP Role Membership Reconciliation

For each of these jobs, except Fusion Applications Role Category Seeding, there is a parallel job to do the full reconciliation. All these jobs, except Fusion Applications Role Category Seeding, perform the reconciliation based on change logs, whereas full reconciliation jobs use the search base to do the reconciliation.

4.3.3.1 Consolidated LDAP Sync Full Reconciliation

The LDAP Consolidated Full Reconciliation scheduled job runs the following jobs in order:

1. LDAP User Create and Update Full Reconciliation

2. LDAP Role Create and Update Full Reconciliation

3. LDAP Role Membership Full Reconciliation

4. LDAP Role Hierarchy Full Reconciliation

See Also:

"LDAP Scheduled Tasks" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about the LDAP Consolidated Full Reconciliation scheduled job

When you run the LDAP Consolidated Full Reconciliation scheduled job, the job status of the previous job and all event status for that particular job are checked because the next job must be run in a particular order. If any job fails to run, then the automatic run of the jobs stop, and error messages are logged in the diagnostic log.

Note:

The LDAP User Delete Full Reconciliation and LDAP Role Delete Full Reconciliation jobs are not part of LDAP Consolidated Full Reconciliation. These scheduled jobs are disabled by default. They can be enabled by selecting the radio buttons and can be run individually.

You can also run the individual jobs by selecting the radio buttons on the LDAP Sync Consolidated Full Reconciliation job details page. The job details contain all the common parameters for the four full reconciliation reconciliation jobs. In addition, you can specify the values for the following parameters of the LDAP Sync Consolidated Full Reconciliation scheduled job:

• Reconciliation Search Base: Search base for the full reconciliation of users or roles. This defines the location in the LDAP directory from which the LDAP search begins.

• Reconciliation Role Search Filter: Search filter for full reconciliation of roles. This filter allows certain role/group entries in the subtree of the LDAP directory and excludes others.

• Reconciliation User Search Filter: Search filter for full reconciliation of users. This filter allows certain user entries in the subtree of the LDAP directory and excludes others.

Based on the values entered for the Reconciliation Search Base and/or Reconciliation User Search Filter and Reconciliation Role Search Filter parameters, the user and role accounts are pulled into Oracle Identity Manager from LDAP when the LDAP Sync Consolidated Full Reconciliation job is run. As a result of this full reconciliation, the delete happens in the Oracle Identity Manager database for the deleted entries in LDAP from that particular node.

The Reconciliation Search Base and Reconciliation Search Filter parameters support the following:

• Reconciling the user or role account from LDAP to Oracle Identity Manager database:

  This provides the option to perform fine-grained reconciliation of a particular user or role. The value of the Reconciliation Search Base parameter is:

  "cn=cokeuser1,cn=users,cn=subrealm1,dc=us,dc=oracle,dc=com"
  

• All users and roles or groups under the node is reconciled:

  The value of Reconciliation Search Base is:

  "cn=tenant1,dc=us,dc=oracle,dc=com"
  

  Here, the user full reconciliation and role full reconciliation are triggered. Therefore, all the users and roles or groups under the tenant1 node are reconciled.

• All users under the node is reconciled:

  The value of Reconciliation Search Base is:

  "cn=users,cn=tenant1,dc=us,dc=oracle,dc=com"
  

  Here, all the users under the tenant1 node are reconciled.

• All roles or groups under the node is reconciled:

  The value of the Reconciliation Search Base parameter is:

  "cn=groups,cn=tenant1,dc=us,dc=oracle,dc=com"
  

  Here, all roles or groups under the tenant1 node are reconciled.

The Reconciliation Search Base and Reconciliation Search Filter parameters are not bound together for LDAPSync Full reconciliation. Reconciliation Search Filter can be empty. Search Base can be used for provisioning or pushing entries from Oracle Identity Manager to LDAP, while Reconciliation Search Base can be used to perform full reconciliation from LDAP to Oracle Identity Manager database. If a value is not provided for Reconciliation Search Base, then the value for Search Base from the 'Directory Resource' IT resource configuration is used for both provisioning and full reconciliation.Sample values for the Reconciliation Search Base parameter:

"cn=tenant1,dc=us,dc=oracle,dc=com"

Sample values for the Search Base parameter:

"dc=us,dc=oracle,dc=com"

Sample values for the Reconciliation User Search Filter and Reconciliation Role Search Filter parameters:

(objectclass=orclAPPIDPerson)
(title=foobar)

Messages Logged For the LDAP Sync Consolidated Full Reconciliation Scheduled Job

The following is a list of messages for the LDAP Sync Consolidated Full Reconciliation scheduled job that are logged in the Oracle Identity Manager diagnostic log files:

LDAP Sync Full Reconciliation Scheduler job {0} is currently Running.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has Stopped.
LDAP Sync Full Reconciliation Scheduler job {0} is currently being Interrupted while running.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has Failed.
Error occurred while running the LDAP Sync User Full Reconciliation scheduler job. Please refer to the OIM Server logs for more details.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has been Shutdown.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running.
SQLException has occurred.
All LDAPSync Full Reconciliation jobs ran successfully and Stopped.