1. Administering Oracle Directory Integration Platform
  2. Integrating with Third-Party Directories
  3. Connected Directory Integration Concepts and Considerations

19 Connected Directory Integration Concepts and Considerations

This chapter discusses the basic concepts of integrating Oracle Directory Integration Platform with a connected directory along with various decisions to be made as part of the integration process.

This chapter contains the following topics:

See Also:

The following chapters for specific implementation details on synchronizing with connected directories:

19.1 Concepts and Architecture of Connected Directory Integration

Oracle provides centralized security administration for all Oracle components by integrating them with Oracle Identity Management. If your environment uses one of Oracle Directory, such as Oracle Unified Directory, Oracle Internet Directory, or Oracle Directory Server Enterprise Edition and another directory, such as Microsoft Active Directory, you can use a connector to integrate the two systems and synchronize their data. A connector is a prepackaged connectivity solution that allows the Oracle Directory to synchronize with a connected directory.

This section discusses the Oracle components and architecture involved in integrating Oracle Directory Integration Platform with connected directories. It included the following topics:

Note:

  • Refer to the Oracle Fusion Middleware Supported System Configurations certification matrix for information about the directories and servers certified for integration with each of the Oracle back-end directories (Oracle Internet Directory, Oracle Unified Directory, and Oracle Directory Server Enterprise Edition).

  • You can also configure a pluggable database as the connected directory.

19.1.1 Oracle Identity Management Components for Integrating with Other Directories

Oracle Identity Management includes Oracle Back-end Directory, Oracle Directory Integration Platform, Oracle Directory Services Manager, and Delegated Authentication that are used to integrate with another directory

Topics:

See Also:

Administering Oracle Directory Integration Platform for a description of the tools used to integrate Oracle Internet Directory with a third-party directory

19.1.1.1 Understanding Oracle Back-end Directory

The Oracle back-end directory is the repository in which Oracle components and third-party applications store and access user identities and credentials. It uses an Oracle directory server to authenticate users by verifying the credentials entered by users with the credentials stored in the Oracle back-end directory. Credentials can be either synchronized from the connected directory to a Oracle back-end directory or stored in the connected directory. In this case, the Oracle back-end directory will delegate the authentication to the connected directory.

19.1.1.2 Understanding Oracle Directory Integration Platform

Oracle Directory Integration Platform is installed as part of Oracle Identity Management. You can configure it to run on the same host as the Oracle back-end directory or on a different host.

Oracle Directory Integration Platform enables:

  • Synchronization between the Oracle back-end directory and other connected directories and user repositories.

  • Automatic provisioning services for Oracle components if Oracle Internet Directory or Oracle Unified Directory is the Oracle back-end directory.

Oracle Directory Integration Platform includes connectors to synchronize the Oracle back-end directory with other LDAP directories or data stores. The Oracle Directory Integration Platform integration connectors allow you to:

  • Configure either one-way or two-way synchronization with a connected directory.

    Note:

    Oracle Directory Integration Platform supports password synchronization to connected directories from an Oracle back-end directory.

  • Designate a specific subset of attributes for synchronization. You do this by configuring the appropriate mapping rules, which you can then change at run time.

See Also:

"Attribute-Level Mapping" for a discussion about configuring attribute mapping rules

19.1.1.3 Understanding Oracle Directory Services Manager
19.1.1.4 Understanding Delegated Authentication

External authentication plug-ins, such as the Microsoft Active Directory external authentication plug-in, are available for the ­back-end directory and enable users to log in to the Oracle environment by using their Microsoft Windows credentials.

Oracle Unified Directory and Oracle Directory Server Enterprise Edition back-end directories use pass-through authentication for passing authentication through to a connected directory like Microsoft Active Directory for users coming from Oracle Unified Directory or Oracle Directory Server Enterprise Edition.

When an external authentication plug-in is in place, it is invoked by the Oracle directory server. This plug-in verifies the user's credentials in a connected directory.

For more information, see:

19.1.2 Oracle Back-end Directory Schema Elements for Synchronizing with Connected Directories

The Oracle back-end directory contains schema elements that correspond to attributes that are specific to connected directories, such as Microsoft Active Directory. The schema elements identify back-end directory objects that Oracle Directory Integration Platform synchronizes with the connected directory.

These schema elements are described in the following sections:

19.1.3 Directory Information Tree in an Integration with a Connected Directory

The directory information tree (DIT) provides a way to refer to the data stored in your directory. The types of information stored, the physical nature of your enterprise, the applications that use your directory, and the types of replication you use shape the design of the directory tree.

This section contains these topics:

See Also:

19.1.3.1 About Realms in Oracle Internet Directory

In Oracle Internet Directory, an identity management realm defines an enterprise scope over which certain identity management policies are defined and enforced by the deployment.

An identity management realm comprises:

  • A well-scoped collection of enterprise identities—for example, all employees in the US domain.

  • A collection of identity management policies associated with these identities. An example of an identity management policy would be to require that all user passwords have at least one alphanumeric character.

  • A collection of groups, that is, aggregations of identities that simplify setting the identity management policies

Multiple Realms

You can define multiple identity management realms within the same Oracle Identity Management infrastructure. This enables you to isolate user populations and enforce a different identity management policy,—for example, password policy, naming policy, self-modification policy—in each realm. This is useful in a hosted deployment of Oracle Fusion Middleware.

Each identity management realm is uniquely named to distinguish it from other realms. It also has a realm-specific administrator with complete administrative control over the realm.

The Default Realm

For all Oracle components to function, an identity management realm is required. One particular realm, created during installation of Oracle Directory, is called the default identity management realm. It is where Oracle components expect to find users, groups, and associated policies whenever the name of a realm is not specified. This default realm facilitates proper organization of information and enforces proper access controls in the directory.

There can be only one default identity management realm in the directory. If a deployment requires multiple identity management realms, then one of them must be chosen as the default.

Figure 19-1 illustrates the default identity management realm.

Figure 19-1 The Default Identity Management Realm

This illustration is described in the text.

As Figure 19-1 shows, the default identity management realm is part of a global DIT. The node that follows the root DSE is dc=com, followed by dc=MyCompany, then dc=us. These four nodes represent the overall DIT structure. The node dc=us is the root of the default identity management realm. It has two subtrees for containing user and group information: cn=Users and cn=Groups. For illustration purposes, the cn=Users node contains two leaves: uid=user1 and uid=user2. Similarly, the cn=Groups node contains cn=group1 and cn=group2.

Access Control Policies in the Realm

You must configure appropriate ACLs in Oracle Internet Directory to enable Oracle Directory Integration Platform to:

  • Enable the import profile to add, modify and delete objects in the users and groups containers. By default, import profiles are part of the Realm Administrators group, which can perform all operations on any entry under the realm DN. If you have customized ACLs in the realm, then be sure that the import profiles have the appropriate privileges to perform these operations on the subtree to be synchronized or on either the user container, the group container, or both depending on where the synchronization takes place.

  • Enable Oracle components to manage the users and groups in the realm. By default, Oracle components can manage users and groups in the users and groups containers respectively. If you have updated your usersearchbase and groupsearchbase in the realm, then set up appropriate ACLs on the users container and groups container.

See Also:

The chapter on deployment of Oracle Identity Management realms in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for a description of the default realm installed with Oracle Internet Directory.

19.1.3.2 About Suffixes in Oracle Unified Directory and Oracle Directory Server Enterprise Edition

You must create the required suffixes in Oracle Unified Directory and Oracle Directory Server Enterprise Edition, if they do not exist.

For Oracle Directory Server Enterprise Edition you must manually create the suffixes as described in Creating Oracle Directory Server Enterprise Edition Suffixes.

For Oracle Unified Directory, if the suffixes are not created during installation, then you must create the suffixes as described in Creating Oracle Unified Directory Suffixes.

Ensure that you add the required Access Control Instructions (ACIs), as described in:

19.1.3.3 Understanding How to Plan the Deployment

When planning the deployment, the most important decisions to make before synchronization are:

  • Which directory is to be the central one

  • What objects to synchronize, for example:

    • The portion of the DIT that you want to synchronize. You can synchronize the entire DIT or just a portion of it.

    • For each entry, the specific contents that you want to synchronize. You can synchronize the entire content of the entry or just a portion of it.

  • Where to synchronize. You have two options:

    • You can synchronize so that the relative position of each entry in the DIT is the same in the source and destination directories. This configuration, called one-to-one distinguished name mapping, is the most commonly used configuration. Because the source DN is the same as the destination DN, this configuration provides better performance than when the two DNs are different.

    • You can synchronize so that the relative position in the DIT of each entry in the destination directory is different from that in the source directory. In this configuration, the Oracle Directory Integration Platform must change the DN values of all entries being mapped, including their references in group entries. This requires more intensive computation.

      If you synchronize in this way, you need to use the dnconvert mapping rule as described in "Supported Attribute Mapping Rules and Examples".

See Also:

The section "About Choosing the Structure of the Directory Information Tree" for more information about planning the directory information tree

19.1.3.4 Example: Integration with a Single Connected Directory Domain

Figure 19-2 shows an example of one-to-one mapping between Oracle Internet Directory (You can also use Oracle Unified Directory or Oracle Directory Server Enterprise Edition) and a connected directory.

Figure 19-2 Default DIT Structures in Oracle Internet Directory and a Connected Directory When Both Directory Hosts Are Under the Domain us.MyCompany.com

Description of Figure 19-2 follows
Description of "Figure 19-2 Default DIT Structures in Oracle Internet Directory and a Connected Directory When Both Directory Hosts Are Under the Domain us.MyCompany.com"

In the one-to-one mapping illustrated in Figure 19-2:

  • Both Oracle Internet Directory and the connected directory hosts have the same topology.

  • Users are synchronized only from the connected directory to Oracle Internet Directory. All users to be synchronized are stored in one container in the connected directory, in this case users.us.MyCompany.com.

  • The same DIT structure is maintained in both the connected directory and Oracle Internet Directory. All users appear in the same users subtree identified by the value cn=users,dc=us,dc=MyCompany,dc=com.

In the example shown in Figure 19-2, only the users subtree must be synchronized from the connected directory to Oracle Internet Directory using one-to-one domain mappings.

Note:

In Figure 19-2, the two directories have the same topology, but be aware that this is for illustration purposes only. The two directories do not need to be in the same domain. Oracle Internet Directory can be anywhere in the network, provided it can connect to the connected directory.

In addition, although the synchronization in the example is one-way, from the connected directory to Oracle Internet Directory, the synchronization can, alternatively, be bi-directional.

19.2 Planning Your Integration Environment

This section describes how to plan your integration environment for Oracle Directory Integration Platform with a connected directory.

Topics:

19.2.1 Preliminary Considerations for Integrating with a Connected Directory

If you are deploying an Oracle back-end directory in an enterprise that already has an LDAP directory server, then you must configure both directories to coexist in the same environment.

The coexistence of directories requires either of two different types of deployments:

  • Simple synchronization with the Oracle back-end directory. Use this approach if your environment supports enterprise users by using a database server. If Oracle Internet Directory or Oracle Unified Directory is your Oracle back-end directory, this approach will support Enterprise User Security.

    Note:

    Your Oracle back-end directory must be Oracle Internet Directory or Oracle Unified Directory to support Enterprise User Security. Oracle Directory Server Enterprise Edition back-end directory does not support integration with other Fusion Middleware components, including Enterprise User Security.

  • Complete integration with the Oracle Fusion Middleware infrastructure. This enables all enterprise users to use the various components in the Oracle Fusion Middleware suite. Use this approach if your environment uses a connected directory as the enterprise directory and deploys an Oracle Fusion Middleware suite of applications.

    Because all Oracle Fusion Middleware components depend on the identity management realm, complete integration with the Oracle Fusion Middleware infrastructure requires you to make some decisions about the container for that realm. Once you have made these decisions, you can configure bootstrapping and synchronization between the directories.

19.2.2 Choose the Directory for the Central Enterprise Directory

This section explains how to choose which directory is to be the central enterprise directory or metadirectory.

Topics:

19.2.2.1 Overview of Scenario 1: Oracle Directory as the Central Enterprise Directory

If Oracle directory like Oracle Unified Directory, Oracle Internet Directory, and Oracle Directory Server Enterprise Edition is the central directory, then once the user, group, and realm objects are created, Oracle directory becomes the source of information for all Oracle components and connected directories. The user and group objects for the entire enterprise are then provisioned in various Oracle components and synchronized to the connected directories from the Oracle directory.

Table 19-1 describes the typical requirements in this deployment.

Table 19-1 Typical Requirements with Oracle Directory as the Central Enterprise Directory

Requirement Description

Initial startup

The syncProfileBootstrap command populates the connected directory with users and groups stored in Oracle directory.

Synchronization

User and group information is managed in Oracle directory. Changes to that information are synchronized with the connected directory by Oracle Directory Integration Platform when an export profile has been configured.

Synchronization from the connected directory into Oracle directory can be achieved by configuring an import profile.

Passwords synchronization

Passwords are managed in Oracle Directory by using Oracle tools. Password changes are synchronized with the connected directory by the Oracle Directory Integration Platform. However, before this server can synchronize the password changes, the password synchronization must be configured as described in Password Synchronization.

Oracle recommends you to use SSL communication for password synchronization.

New users or groups in Oracle Directory can be automatically synchronized by the Oracle Directory Integration Platform. This automatic synchronization requires that the Oracle directory server is running with the change log enabled and the change log is not purged.

If these two conditions are not met, then you must dump the entries in Oracle Directory to an LDIF file and upload the data to the connected directory.

See Also:

Figure 19-3 shows a typical deployment in which Oracle Directory is the central enterprise directory.

Figure 19-3 Interaction Among Components with Oracle Directory as the Central Enterprise Directory

Description of Figure 19-3 follows
Description of "Figure 19-3 Interaction Among Components with Oracle Directory as the Central Enterprise Directory"

As Figure 19-3 shows, when Oracle Directory is the central enterprise directory, typical synchronization of a user or group follows this process:

  1. The user or group entry is created in Oracle Directory by using the graphical tools or command-line tools. For more information, see Administering Oracle Directory Integration Platform.

  2. At the next scheduled interval, that entry creation event is read by the third-party directory connector in Oracle Directory Integration Platform.

  3. Following the mapping information in the integration profile, the user or group attributes in Oracle Internet Directory are appropriately mapped to the corresponding user or group attributes as required by the schema in the connected directory.

  4. The user and group entry is created in the connected directory.

A user entry is modified in Oracle Directory, when a new attribute gets added to the entry, the value of an existing attribute is modified, or an existing attribute is deleted.

When Oracle Directory is the central enterprise directory, the sequence of events during modification of a user or group entry is as follows:

  1. The entry is modified by using the Oracle Directory Services Manager (For Oracle Unified Directory and Oracle Internet Directory), Directory Service Control Center (For Oracle Directory Server Enterprise Edition) or Oracle Enterprise Manager Fusion Middleware Control.

  2. At the next scheduled interval, that entry modification event is read by the third-party directory connector in Oracle Directory Integration Platform.

  3. Following the mapping information in the integration profile, the attribute in Oracle Directory is appropriately mapped to the corresponding attribute in the connected directory.

  4. The user entry is modified in the connected directory.

19.2.2.2 Overview of Scenario 2: A Directory Other than the Oracle Directory is the Central Enterprise Directory

In this scenario the connected directory (Either a third-party directory or another Oracle directory) is the central enterprise directory, and Oracle Directory is the Oracle back-end directory. In this scenario, once the user, group, and realm objects are created, the central enterprise directory becomes the source of synchronizing information for all Oracle components and other directories. Oracle Directory is deployed as the Oracle back-end directory to support Oracle components. To provide this support, Oracle Directory stores a footprint that enables it to identify entries in the connected directory.

Topics:

19.2.2.2.1 Understanding the Requirements in This deployment

Table 19-2 describes the typical requirements in this deployment.

Table 19-2 Typical Requirements if a Connected Directory is the Central Enterprise Directory

Requirement Description

Initial startup

The syncProfileBootstrap command populates Oracle back-end directory with users and groups stored in the central enterprise directory.

You can choose to manage user information, including password credentials, in the central enterprise directory only. In such deployments, to enable single sign-on in the Oracle environment, the Oracle Directory Integration Platform can synchronize only those user entry attributes required by Oracle components.

Passwords are not migrated from the central enterprise directory to Oracle Internet Directory.

Synchronization

The central enterprise directory for user and group information is the connected directory (Oracle Internet Directory, Oracle Unified Directory, Oracle Directory Server Enterprise Edition, or a third-party directory). Changes to user and group information in the central enterprise directory are synchronized with Oracle back-end directory by the Oracle Directory Integration Platform when an import profile has been configured.

Synchronization from Oracle back-end directory to the central enterprise directory is achieved by configuring an export profile.

Passwords synchronization

Passwords are managed in the central enterprise directory. For more information, see Password Synchronization.

Third-party delegate authentication plug-in

When user credentials are managed in the connected directory, the Oracle back-end directory can delegate the authentication. To authenticate a user, a specific plug-in performs the authentication of the user against the user credentials stored in the connected directory. For more information, see Understanding Delegated Authentication.

New users or groups created in the directory that is designated as the central enterprise directory are automatically synchronized into Oracle Directory by the Oracle Directory Integration Platform. Before this can happen, a one-way synchronization between the central enterprise directory and Oracle back-end directory must be established.

Figure 19-4 shows a typical deployment where a third-party directory is the central enterprise directory.

Figure 19-4 Interaction of Components with a Third-Party Directory as the Central Enterprise Directory in a Delegated Authentication Deployment


Description of Figure 19-4 follows
Description of "Figure 19-4 Interaction of Components with a Third-Party Directory as the Central Enterprise Directory in a Delegated Authentication Deployment"

19.2.2.2.2 What are the Process for Synchronizing of a User or Group?

Figure 19-4 shows the typical process for synchronizing a user or group when a third-party directory is the central enterprise directory.

This process is described as follows:

  1. The user or group entry is created in the third-party directory.

  2. At the next scheduled interval, the entry creation event is read by the third-party directory connector in Oracle Directory Integration Platform.

  3. Following the mapping information in the integration profile, the user or group attributes in the third-party directory are mapped to the corresponding attributes in the third-party directory.

  4. The user or group entry is created in the Oracle back-end directory.

19.2.2.2.3 What are the Process for Modifying a User or Group Entry?

An entry is modified in the connected directory when a new attribute gets added to the entry, the value of an existing attribute is modified, or an existing attribute is deleted.

When a connected directory is the central enterprise directory, modification of a user or group entry follows this process:

  1. The entry is modified in the connected directory.

  2. At the next scheduled interval, that entry modification event is read by the third-party directory connector in Oracle Directory Integration Platform.

  3. Following the mapping information in the integration profile, the attribute in the connected directory is appropriately mapped to the corresponding attribute in the back-end directory.

  4. The user or group entry is modified in the Oracle back-end directory.

Depending on the password synchronization method selected, when a third-party directory is the central enterprise directory, modification of passwords can happen asynchronously in the directory that serves as the password repository, as shown in Figure 19-4. This happens by using plug-ins.

19.2.3 Understanding How to Customize the LDAP Schema

You can customize the LDAP schema in the destination directory if a directory deployment contains schema extensions such as custom object classes and attributes or the custom attributes must be synchronized from one directory server to the other.

To customize the LDAP schema, you must:

  • Identify the schema extensions on the source directory

  • Create those extensions on the target directory before starting the data migration and the synchronization

    Note:

    In addition to creating schema extensions, you must also add the attribute to be synchronized with the corresponding object classes to the mapping rules.

    See Also:

19.2.4 About Choosing Where to Store Passwords

Regardless of which directory is the central enterprise directory, the password can be stored in one or both directories. There are advantages and disadvantages to each option.

This section compares the two options in these topics:

19.2.4.1 Understanding the Advantages and Disadvantages of Storing the Password in One Directory

Storing the password in one directory can make the password more secure because it reduces the number of points of entry. Further, it eliminates synchronization issues when the password is modified.

On the other hand, storing the password in one directory provides a single point of failure for the entire network. If the directory in which the passwords are stored fails, then the bind operation for users connecting to other directory also fails and the user is not authenticated.

Although storing passwords in the central directory eliminates possible synchronization issues, it requires you to enable applications to authenticate users to that directory. This involves using the appropriate plug-ins. For example, if you are using Microsoft Active Directory as both the central enterprise directory and the central password store, then you must enable applications to authenticate users to Microsoft Active Directory. You do this by configuring the delegated authentication on the back-end directory.

Note:

Oracle components use password verifiers to authenticate users, and, when passwords are stored in a third-party directory, those verifiers are not stored in Oracle Internet Directory. If a password is modified by using an Oracle component, then the verifiers are both generated and stored in Oracle Internet Directory.

19.2.4.2 Understanding the Advantages and Disadvantages of Storing Passwords in Both Directories

If you decide to store passwords in both Oracle back-end directory and a connected directory, then passwords need to be synchronized, ideally in real-time.

Oracle Directory Integration Platform 11g Release 1 (11.1.1) and above does not synchronize passwords in real time, but according to a schedule. This can mean an observable delay between the time the password is changed in the central enterprise directory and the time that the change is recorded in the other directory.

See Also:

In general, password values are hashed. If both directories use the same hashing algorithm, then the hashed values can be synchronized as they are. For example, suppose that you have an environment in which Oracle Directory Server Enterprise Edition (previously Sun Java System Directory Server) and Oracle Internet Directory are integrated. Both of these directories support common hashing algorithms. If the passwords are hashed and stored in Oracle Directory Server Enterprise Edition by using a hashing technique supported by Oracle Internet Directory, then synchronizing Oracle Directory Server Enterprise Edition passwords to Oracle Internet Directory is the same as with any other attribute. If both directories do not support the same hashing algorithm, then passwords must be synchronized in clear text format only.

Note:

Oracle recommends using the SSL connection to synchronize the password for the back-end directory and the connected directory. For more information, see Password Synchronization.

If Oracle Internet Directory is the central directory, and if the hashing algorithm it supports is not supported by the other directory, then synchronization is still possible through SSL server authentication mode when reversible password encryption is enabled.

If Microsoft Active Directory is the central directory, then, when a password is modified in Microsoft Active Directory, a plug-in intercepts the password changes and sends them to Oracle Internet Directory. When Oracle Internet Directory is the central directory and the central password store, Oracle Directory Integration Platform reads the password changes as a privileged user and sends them to the corresponding directory.

Note:

In deployments where both directories do not use the same hashing algorithm, password synchronization is not available in an out-of-the-box installation of Oracle Directory. You must configure it.

In deployments where Oracle back-end directory is not the central directory, the password policy is enforced by the third-party directory. When there is an authentication request to the third-party directory, the latter replies that the authentication either succeeded or failed. However, any detailed password policy errors from the third-party directory are not delivered to Oracle Internet Directory and then to the client applications.

See Also:

The following for information about plug-ins:

19.2.5 About Choosing the Structure of the Directory Information Tree

At installation, each directory server might or might not creates a default domain and a default directory information tree (DIT) structure. The Oracle Internet Directory infrastructure installation creates a default realm with designated containers for storing enterprise users and groups. Oracle Unified Directory and Oracle Directory Server Enterprise Edition do not create the default DIT. When integrating with a connected directory, you can create identical DIT structures in both directories to simplify the configuration. Alternatively, you can perform domain-level mapping.

Topics:

19.2.5.1 Create Identical DIT Structures on Both Directories

Oracle recommends that you configure identical DITs on both directories. This enables all the user and group objects to be synchronized as they are, and eliminates the task of mapping entries with distinguished names in one directory to URLs in the other. It also eliminates the performance problems that those mappings can cause.

To create identical DITs, first decide which directory is the central enterprise directory, and then change the DIT of the other one to match. Be sure to update the directory integration profile to reflect the domain-level rules.

To enable users to access Oracle applications through Oracle Application Server Single Sign-On, Oracle recommends that you identify the DIT as a separate identity management realm with its own authentication and authorization domain.

See Also:

The chapter about deploying identity management realms in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

19.2.5.2 Distinguished Name Mapping and Limitations

If it is not feasible to have identical DITs on both directories, then you need to map the domains between Oracle back-end directory and the connected directory. For example, suppose that all entries under the container dc=mydir,dc=com must be synchronized under dc=myOracleDir,dc=com in Oracle back-end directory. To achieve this, you specify it in the domain-level mapping rules.

If the objective is to synchronize all users and groups, then all user entries can be synchronized with the appropriate DN mapping. However, group entry synchronization can be both time consuming and carry some additional limitations. This section provides examples of both user and group synchronization when there is a DN mapping.

Example: User Entry Mapping

Suppose that the connected directory is Oracle Directory Server Enterprise Edition (previously Sun Java System Directory Server) and that its entries have the format uid=name,ou=people,o=iplanet.org. Suppose further that the back-end directory is Oracle Internet Directory whose entries have the format cn=name,cn=users,dc=iplanet,dc=com. Note that the naming attribute on Oracle Directory Server Enterprise Edition is uid, but on Oracle Internet Directory it is cn.

The mapping file has rules similar to these:

DomainRules
ou=people,o=iplanet.org: cn=users,dc=iplanet,dc=com: cn=%, cn=users,dc=iplanet,dc=com
AttributeRules
Uid:1: :person:cn: :inetorgperson:

The value of 1 in the second column of the last line indicates that, for every change to be propagated from Oracle Directory Server Enterprise Edition to Oracle Internet Directory, the uid attribute must be present. This is because the uid must be available for constructing the DN of the entry in Oracle Internet Directory.

Example: Group Entry Mapping

When there is a DN mapping, synchronizing group entries is somewhat complex. The group memberships, which are DNs, must have valid DN values after synchronization. This means that whatever DN mapping was done for user DNs must be applied to group membership values.

For example, suppose that the user DN values are mapped as follows:

ou=people,o=iplanet.org: cn=users,dc=iplanet,dc=com:

This implies that all the user entries under ou=people,o=iplanet.org are moved to cn=users,dc=iplanet,dc=com.

Group memberships need to be mapped as follows:

uniquemember: : : groupofuniquenames: uniquemember: :groupofuniquenames:dnconvert(uniquemember)

For example, if the value of uniquemember is cn=testuser1,ou=people,o=iplanet.org, then it becomes cn=testuser1,cn=users,dc=iplanet,dc=com.

Moreover, if the value of uniquemember is cn=testuser1,dc=subdomain,ou=people,o=iplanet.org, then it becomes cn=testuser1,dc=subdomain,cn=users,dc=iplanet,dc=com.

This is a feasible solution as long as the naming attribute or RDN attribute remains the same on both the directories. However, if the naming attribute is different on different directories—as, for example, ou=people,o=iplanet.org:cn=users,dc=iplanet,dc=com:cn=%,cn=users,dc=iplanet,dc=com—then deriving the actual DNs for group memberships is not achievable through the given set of mapping rules. In this case, DN mapping for the uniquemember or other DN type attributes is not currently feasible.

If you want to synchronize group memberships, remember to keep the naming attribute in the source and destination directories the same.

See Also:

"Configuring Mapping Rules" for instructions about how to specify a mapping rule

19.2.6 Attribute for the Login Name

The attribute for the login name contains the identity of the end user when logging into any Oracle component. It is stored in the Oracle back-end directory as the value of the attribute orclcommonnicknameattribute.

If the Oracle back-end directory is Oracle Internet Directory, the attribute orclcommonnicknameattribute is located under the container cn=common,cn=products,cn=oracleContext,identity_management_realm.

If the Oracle back-end directory is Oracle Unified Directory or Oracle Directory Server Enterprise Edition, the attribute orclcommonnicknameattribute is located under the container cn=common,<suffix>,identity_management_realm.

By default, orclcommonnicknameattribute attribute has uid as its value. This means that the identity used to log in is stored in the uid attribute of the user entry.

If the connected directory has a specific attribute for logging in, then that attribute needs to be mapped to the right orclcommonnicknameattribute in Oracle Directory. This needs to be one of the mapping rules in the mapping file for the connector associated with synchronizing with the connected directory.

For example, suppose that you are synchronizing Oracle Internet Directory with Microsoft Active Directory, and that, in the latter, the login identifier is contained in the userPrincipalName attribute of the user entry. You would synchronize the value of the userPrincipalName attribute to Oracle Internet Directory, storing it in the uid attribute, which is the value of the orclcommonnicknameattribute attribute. This mapping needs to be reflected in the mapping rules in the directory integration profile.

You can also use any other attribute for the login identifier. For example, if you want to use employeeID for logins, then mapping rules can be set accordingly. Doing this does not affect your configuration.

See Also:

Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management for instructions about setting the attribute for login name

19.2.7 Selecting the User Search Base

The user search context is represented by a multivalued attribute that lists all the containers under which users exist. Depending on your deployment, do one of the following:

  • Either set the user search context value to cover the entire user population.

  • Add the container to the user search context attribute by using the Oracle Internet Directory Self-Service Console.

See Also:

Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management for instructions about setting the user search context

19.2.8 What Group Search Base to Select?

The group search context is represented by a multivalued attribute that lists all the containers under which groups exist. Depending on your deployment, either set the group search context value to cover all group entries, or add the container to the group search context attribute by using the Oracle Internet Directory Self-Service Console.

See Also:

Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management for instructions about setting the group search context

19.2.9 Guidelines to Address Security Concerns

There are three main security concerns you need to consider:

  • Access policies—The user and group search bases should be appropriately protected from access by any malicious users.

  • Synchronization—You can configure the Oracle Directory Integration Platform to use SSL when connecting to Oracle back-end directory and connected directories. If you do this, then all information exchanged among the directory servers is secure.

    Note:

    To synchronize password with Microsoft Active Directory, you must use SSL communication.

  • Password synchronization—Depending on the configuration, passwords can be synchronized. For example, when Oracle Internet Directory is the central enterprise directory, password changes can be communicated to the connected directory. If passwords are to be synchronized, then Oracle recommends that you configure communication between the directories in SSL server authentication mode.

19.2.10 About How to Administer Your Deployment with Oracle Access Manager

To use Oracle Access Manager to administer an Oracle Internet Directory deployment that synchronizes with a connected directory, you must ensure that synchronized users are visible with Oracle Access Manager.

19.3 Microsoft Active Directory Integration Concepts

This section contains additional considerations for integrating the Oracle back-end directory with Microsoft Active Directory. It contains these topics:

See Also:

Integrating with Microsoft Active Directory

19.3.1 Understanding How to Synchronize from Microsoft Active Directory to the Oracle Back-end Directory

To synchronize changes from Microsoft Active Directory to the Oracle back-end directory, Oracle Directory Integration Platform imports incremental changes made available by Microsoft Active Directory change tracking mechanisms. Oracle Directory Integration Platform supports the following two Microsoft Active Directory change tracking mechanisms:

  • The DirSync approach, which uses an LDAP control that is supported by Microsoft Active Directory

  • The USN-Changed approach, which uses an attribute of the entry

In each approach, the directory from which changes are derived is queried at scheduled intervals by Microsoft Active Directory Connector. Each approach has advantages and disadvantages. Table 19-3 compares the two approaches.

Table 19-3 Comparing the DirSync Approach to the USN-Changed Approach

Considerations DirSync Approach USN-Changed Approach

Change key

Presents changes to the ObjectGUID, the unique identifier of the entry

Presents changes to the distinguished name. The ObjectGUID is used to keep track of modifications of the DN.

Enabling the Connectors

The connector is enabled by setting the property Reader to oracle.ldap.odip.gsi.ActiveReader during profile creation.

The connector is enabled by setting the property Reader to oracle.ldap.odip.gsi.ActiveChgReader. during profile creation.

Template File

The synchronization profile template file is adimport.properties (ORACLE_HOME/ldap/odi/conf).

The synchronization profile template file is activechgimp.properties (ORACLE_HOME/ldap/odi/conf).

Error handling

If synchronization stops as a result of an error condition, then, during the next cycle, all changes that are already applied are read and skipped.

Does not require synchronization to be atomic. If synchronization stops, then the next synchronization cycle starts from the entry where the synchronization was interrupted.

Information in the search results

Changes consist of only the changed attributes and the new values. This can be quicker than the USN-Changed approach.

All attributes of the changed entry are retrieved. The retrieved values are compared to the old values stored in the Oracle back-end directory and updated. This can be more time consuming than the DirSync approach.

Changes to multivalued attributes

Reflects incremental changes made to multivalued attributes as a complete replacement of the attribute value.

Reflects incremental changes made to multivalued attributes as a complete replacement of the attribute value.

How synchronization point is tracked

When queried for changes in the directory, presents incremental changes based on a cookie value that identifies the state of the directory.

The changes are queried in the directory based on the USNChanged attribute, which is a long integer, that is, 8 bytes. You can modify the value to adjust where to start the synchronization.

Required user privileges

Requires the user to have the Replicate Changes privilege on the naming context of interest. This enables reading all objects and attributes in Microsoft Active Directory regardless of the access protections on them.

See Also: The Microsoft Knowledge Base Article 303972 available at https://support.microsoft.com/en-us for instructions on how to assign privileges to Microsoft Active Directory users when using the DirSync approach. Apply to this context the instructions used for Microsoft Active Directory management agent in this article.

Requires the Microsoft Active Directory user to have the privilege to read all required attributes to be synchronized to the Oracle back-end directory.

See Also: Microsoft networking and directory documentation available in the Microsoft library at the following URL: http://msdn.microsoft.com/ for instructions about how to assign privileges to Microsoft Active Directory users when using the USN-Changed approach.

Support of multiple domains

Requires separate connections to different domain controllers to read changes made to the entries in different domains.

Can obtain changes made to the multiple domains by connecting to the Global Catalog server.

See Also: "Synchronizing with a Multiple-Domain Microsoft Active Directory Environment".

Synchronization from a replicated directory when switching to a different Microsoft Active Directory domain controller

Synchronization can continue. The synchronization key is the same when connecting to a replicated environment.

Requires:

  • Full synchronizing to a known point

  • Updating the USNChanged value

  • Starting synchronization with the failover directory

See Also: "Switching to a Different Microsoft Active Directory Domain Controller in the Same Domain"

Synchronization scope

Reads all changes in the directory, filters out changes to the required entries, and propagates to the Oracle back-end directory.

Enables synchronization of changes in any specific subtree

Usability in an environment with multiple Microsoft Active Directory servers behind a load balancer

-

Either connect to a specific Microsoft Active Directory domain controller, or connect to a Global Catalog. Connect to Global Catalog if:

  • You are interested in import operations only

  • The Global Catalog contains all entries and attributes to be synchronized

  • Performance of the Global Catalog is acceptable

See Also:

"Understanding Synchronization from the Back-end Directory to a Connected Directory"

19.3.2 Requirement for Using WebDAV Protocol

If you are using the WebDAV protocol, you must configure your applications for SSL. Basic authentication is necessary because the only way for the Oracle back-end directory to authenticate the end user is to pass the plain text password to Active Directory for verification. When basic authentication is not present, digest authentication is used. But with digest authentication, the Oracle back-end directory does not have the plain text password to pass to Active Directory for verification, and therefore, end users cannot be authenticated. Basic authentication is not supported over HTTP without secure sockets layer (SSL), because the communications channel between the end user and the server would not be encrypted and the end user password would be transmitted similarly unencrypted.

19.3.3 Oracle Back-end Directory Schema Elements for Microsoft Active Directory

Table 19-4 lists the schema elements in the Oracle back-end directory for users that are imported from Microsoft Active Directory.

Table 19-4 Oracle Back-end Directory Schema Elements for Microsoft Active Directory

Schema Element Description

orclObjectGUID

Stores Microsoft Active Directory's OBJECTGUID attribute value for users and groups migrated to the Oracle back-end directory from Microsoft Active Directory.

orclObjectSID

Stores Microsoft Active Directory's OBJECTSID attribute value for users and groups migrated to the Oracle back-end directory from Microsoft Active Directory.

orclSAMAccountName

Stores the value of Microsoft Active Directory's SAMAccountName attribute. In the Oracle back-end directory, this attribute is defined as a directory string type. However, in Microsoft Active Directory this attribute cannot accept any special or non-printable characters. If any entry is added in the Oracle back-end directory with this attribute, it can only contain a simple text string or synchronization from the Oracle back-end directory to Microsoft Active Directory will fail.

orclUserPrincipalName

Stores the Kerberos user principal name for Microsoft Active Directory users.

orclADGroup

Contains Microsoft Active Directory group attributes, which are used to synchronize Microsoft Active Directory group objects with the Oracle back-end directory group objects in an Oracle Directory Integration environment.

orclADUser

Contains Microsoft Active Directory user attributes, which are used to synchronize Microsoft Active Directory user objects with the Oracle back-end directory user objects in an Oracle Directory Integration and Provisioning environment.

orclSourceObjectDN

Represents the DN for the respective entry in Microsoft Active Directory. This value is required to perform external authentication if different domains are mapped between both directories.

See Also:

Oracle Fusion Middleware Reference for Oracle Identity Management for detailed information about the Oracle Internet Directory schema elements for Microsoft Active Directory.

19.3.4 About Integration with Multiple Microsoft Active Directory Domain Controllers

A deployment of Microsoft Active Directory with multiple domains can have either a single DIT or a combination of two or more DITs. In Microsoft Active Directory, a group of DITs is called a forest. Figure 19-5 shows how a forest in Microsoft Active Directory is reflected in the Oracle back-end directory.

Figure 19-5 Mapping Between the Oracle Back-end Directory and a Forest in Microsoft Active Directory

Description of Figure 19-5 follows
Description of "Figure 19-5 Mapping Between the Oracle Back-end Directory and a Forest in Microsoft Active Directory"

In this directory, two domain trees constitute a forest. These trees are in a trust relationship, that is, users in one domain are authenticated by the domain controller in the other domain. This forest in Microsoft Active Directory maps to an identically structured subtree in the Oracle back-end directory.

Considerations for Deployments where the Oracle Back-end Directory is the Central Directory

If there are multiple Microsoft Active Directory domains, the syncProfileBootstrap command must be run as many times as there are Microsoft Active Directory domains. Each time you do this, you choose the specific data set required by the target Microsoft Active Directory domain.

The Oracle Directory Integration Platform synchronizes users and groups in the respective Microsoft Active Directory domains. Before synchronization can take place, you must configure a one-way synchronization profile from the Oracle back-end directory to the Microsoft Active Directory domain.

Considerations for Deployments where Microsoft Active Directory as the Central Directory

If there are multiple Microsoft Active Directory servers, then you must bootstrap the data from each Microsoft Active Directory domain. If you use the Global Catalog for one-way synchronization from Microsoft Active Directory to the Oracle back-end directory, then you need to bootstrap only once from the Global Catalog server.

The Oracle Directory Integration Platform synchronizes users and groups from the respective Microsoft Active Directory domains into the Oracle back-end directory. Before the synchronization can take place, a one-way synchronization profile between the Oracle back-end directory and a domain controller on each Microsoft Active Directory domain must be established.

19.3.5 Synchronizing with a Multiple-Domain Microsoft Active Directory Environment

This section describes considerations for synchronizing with a multiple-domain Microsoft Active Directory environment. It contains these topics:

19.3.5.1 About Configuration Required for Importing from Microsoft Active Directory to the Oracle Back-end Directory

Normally, importing requires configuring one import profile for each Microsoft Active Directory domain regardless of whether you are using the DirSync approach or the USN-Changed approach. However, if you are using the USN-Changed approach, you can use the Global Catalog to import from an entire Microsoft Active Directory forest. You only need to configure a single import profile to use Global Catalog, but keep in mind the following considerations:

  • Because Global Catalog is read-only, you can use it only for importing data into the Oracle back-end directory

  • Global Catalog does not contain all the attributes, although the available attributes can be configured in Microsoft Active Directory

  • Because Global Catalog is a point of authentication, you may incur additional overhead if synchronization is started from this point

See Also:

The Microsoft Knowledge Base Article 256938 available from Microsoft Help and Support at http://support.microsoft.com/ for information about Global Catalog attributes in the Microsoft Active Directory schema

19.3.5.2 About Configuration Required for Importing from Microsoft Active Directory Lightweight Directory Service to the Oracle Back-end Directory

Unlike Microsoft Active Directory, only the USN changed approach is used for synchronizing from Microsoft Active Directory Lightweight Directory Service (AD LDS), which was previously known as Active Directory Application Mode or ADAM, to the Oracle back-end directory. To import entries from Microsoft AD LDS to the Oracle back-end directory, you must configure an import profile connecting to Microsoft AD LDS with the respective port details.

19.3.5.3 About Configuration Required for Exporting from the Oracle Back-end Directory to Microsoft Active Directory

To integrate with multiple-domain Microsoft Active Directory environments, the Oracle Directory Integration Platform obtains configuration information from each Microsoft Active Directory domain. You must configure as many export profiles as there are Microsoft Active Directory domains.

19.3.5.4 Example: Integration with Multiple Connected Directory Domains

A deployment of a connected directory with multiple domains can have either a single DIT or a combination of two or more DITs. Figure 19-6 shows how multiple domains in a connected directory are mapped to a DIT in the Oracle back-end directory.

Figure 19-6 Example of a Mapping Between the Oracle Back-end Directory and Multiple Domains in Microsoft Active Directory

Description of Figure 19-6 follows
Description of "Figure 19-6 Example of a Mapping Between the Oracle Back-end Directory and Multiple Domains in Microsoft Active Directory"

In Figure 19-6, the connected directory environment has a parent and two children.

The first child domain a.us.MyCompany.com maps to dc=a,dc=us,dc=MyCompany,dc=com in the Oracle back-end directory. The second child domain b.us.MyCompany.com maps to dc=b,dc=us,dc=MyCompany,dc=com in the Oracle back-end directory. The common domain component in the connected directory environment us.MyCompany.com maps to the default identity management realm in the Oracle back-end directory, in this case dc=us,MyCompany,dc=com.

19.3.6 Understanding Foreign Security Principals

A Microsoft Active Directory user or computer account represents a physical entity such as a computer or person. User accounts and computer accounts, as well as groups, are called security principals. Security principals are directory objects that are automatically assigned security identifiers. Objects with security identifiers can log on to the network and access domain resources. A user or computer account is used to:

  • Authenticate the identity of the user or computer

  • Authorize or deny access to domain resources

  • Administer other security principals

  • Audit actions performed using the user or computer account

For example, the user and computer accounts that are members of the Enterprise Administrators group are automatically granted permission to log on at all of the domain controllers in the forest.

User and computer accounts are added, disabled, reset, and deleted by using Microsoft Active Directory Users and Computers.

In a trust relationship in Microsoft Active Directory, users in one domain are authenticated by a domain controller in another domain. The trust relationship can be transitive or non transitive.

  • In a transitive trust relationship, the trust relationship extended to one domain is automatically extended to all other domains that trust that domain. For example, suppose you have three domains: A, B, and C in which both B and C are in a direct trust relationship with A. In this scenario, both B and C also trust each other. This is because, although they are not in a direct trust relationship with each other, they are in a direct trust relationship with A.

  • In a non transitive trust relationship, the trust is bound by the two domains in the trust relationship; it does not flow to any other domains in the forest.

When a trust is established between a Windows 2000 domain in a particular forest and a Windows 2000 domain outside of that forest, security principals from the external domain can be granted access to resources in the forest. A security principal from an external domain is called a foreign security principal and is represented in Microsoft Active Directory as a "foreign security principal" object. These foreign security principals can become members of domain local groups, which can have members from domains outside of the forest.

Foreign security principals are used when there is a non transitive trust between two domains in a Microsoft Active Directory environment.

In a non-transitive trust relationship in a Microsoft Active Directory environment, when one domain recognizes a foreign security principal from the other domain, it represents that entity similar to a DN entry. In that entry, the RDN component is set to the SID of the original entry in the trusted domain. In the case of groups, the DNs of the foreign security principals are represented as member values, not as the DNs of the original entries in the trusted domain. This can create a problem when foreign security principals are synchronized with the Oracle back-end directory.

19.4 Oracle Directory Server Enterprise Edition (Sun Java System Directory Server) Integration Concepts

This section contains additional considerations for integrating Oracle Internet Directory (Back-end directory) with Oracle Directory Server Enterprise Edition (previously Sun Java System Directory Server). It contains these topics:

See Also:

Integrating with Oracle Directory Server Enterprise Edition (Connected Directory)

19.4.1 Understanding Synchronization from Oracle Directory Server Enterprise Edition to Oracle Directory Integration Platform

Oracle Directory Server Enterprise Edition (previously Sun Java System Directory Server) maintains a change log in which it stores incremental changes made to directory objects. Synchronization from Oracle Directory Server Enterprise Edition to Oracle Internet Directory makes use of this change log.

See Also:

19.4.2 Understanding Oracle Internet Directory Schema Elements for Oracle Directory Server Enterprise Edition (Sun Java System Directory Server)

Oracle Internet Directory includes the orclSourceObjectDN attribute for users that are imported from Oracle Directory Server Enterprise Edition. The orclSourceObjectDN element represents the DN for the respective entry in Oracle Directory Server Enterprise Edition. This value is required to perform external authentication if different domains are mapped between both directories.

19.5 IBM Tivoli Directory Server Integration Concepts

This section contains additional considerations for integrating the Oracle back-end directory with IBM Tivoli Directory Server. It contains these topics:

19.5.1 About Changes to Directory Objects in IBM Tivoli Directory Server

IBM Tivoli Directory Server maintains a change log where it stores incremental changes made to directory objects. Synchronization from IBM Tivoli Directory Server to the Oracle back-end directory makes use of this change log.

Note:

Tombstone is supported in IBM Tivoli Directory Server version 6.2.

19.5.2 Understanding Oracle Back-end Directory Schema Elements for IBM Tivoli Directory Server

Table 19-5 lists the schema elements in the Oracle back-end directory for users that are imported from IBM Tivoli Directory Server:

Table 19-5 Oracle Back-end Directory Schema Elements for IBM Tivoli Directory Server

Schema Element Description

orclSourceObjectDN

Represents the DN for the respective entry in Tivoli. This value is required to perform external authentication if different domains are mapped between both directories.

orclTDSEntryUUID

Represents the entryUUID value for the respective entry in IBM Tivoli. This value is used as the synchronization key.

orclTDSObject

Represents the Tivoli directory object.

See Also:

19.6 Novell eDirectory and OpenLDAP Integration Concepts

This section contains additional considerations for integrating the Oracle back-end directory with Novell eDirectory or OpenLDAP.

Topics:

See Also:

Integrating with Novell eDirectory or OpenLDAP

19.6.1 About Synchronization from Novell eDirectory or OpenLDAP to the Oracle Back-end Directory

To synchronize changes from Novell eDirectory or OpenLDAP to the Oracle back-end directory, the Oracle Directory Integration Platform evaluates the modification timestamp of each Novell eDirectory or OpenLDAP entry. Entries with timestamps that are more recent than the execution time of the last synchronization are updated in the Oracle back-end directory.

For entries that have been deleted in Novell eDirectory or OpenLDAP, the Oracle Directory Integration Platform identifies the deleted entries by performing a linear comparison between the entries in the Oracle back-end directory and Novell eDirectory or OpenLDAP. In other words, entries in both directories are compared at specified intervals. Entries that are not available in both the Oracle back-end directory and Novell eDirectory or OpenLDAP are deleted. To avoid decreased performance on the server as directory entries are compared, you can customize the comparison to search specific subsets of the DIT.

See Also:

19.6.2 Understanding Oracle Back-end Directory Schema Elements for Novell eDirectory

Know more about the schema elements in the Oracle back-end directory that are imported from Novell eDirectory.

Table 19-6 lists the schema elements in the Oracle back-end directory for users that are imported from Novell eDirectory.

Table 19-6 Oracle Back-end Directory Schema Elements for Novell eDirectory

Schema Element Description

orclSourceObjectDN

Represents the DN for the respective entry in Novell eDirectory. This value is required to perform external authentication if different domains are mapped between both directories.

orclndsobjectguid

Required for reconciliation. Represents the GUID value for the respective entry in Novell eDirectory. This value is used as the synchronization key.

orclsourcemodifytimestamp

Required. Represents the modifytimestamp attribute of the respective entry in Novell eDirectory. This value is used in getting the entries that needs to be synchronized.

orclsourceCreateTimestamp

Required. Represents the createtimestamp attribute of the respective entry in Novell eDirectory. This value is used in synchronization of deleted entries.

orclndsobject

Represents the NDS object in Novell eDirectory.

See Also:

LDAP Schema Overview in Oracle Fusion Middleware Reference for Oracle Identity Management for detailed information about the Oracle back-end directory schema elements for Novell eDirectory.

19.6.3 Understanding Oracle Back-end Directory Schema Elements for OpenLDAP

Know more about the schema elements in the Oracle back-end directory that are imported from OpenLDAP.

Table 19-7 lists the schema elements in the Oracle back-end directory for users that are imported from OpenLDAP.

Table 19-7 Oracle Internet Directory Schema Elements for OpenLDAP

Schema Element Description

orclSourceObjectDN

Represents the DN for the respective entry in OpenLDAP. This value is required to perform external authentication if different domains are mapped between both directories.

orclOpenLdapEntryUUID

Required for reconciliation. Represents the entryUUID value for the respective entry in OpenLDAP. This value is used as the synchronization key.

orclsourcemodifytimestamp

Required. Represents the modifytimestamp attribute of the respective entry in OpenLDAP. This value is used in getting the entries that needs to be synchronized.

orclsourceCreateTimestamp

Required. Represents the createtimestamp attribute of the respective entry in OpenLDAP. This value is used in synchronization of deleted entries.

orclopenldapobject

Represents the OpenLDAP object.

See Also:

LDAP Schema Overview in Oracle Fusion Middleware Reference for Oracle Identity Management for detailed information about the Oracle back-end directory schema elements for OpenLDAP.

19.7 Limitations of Connected Directory Integration in Oracle Directory Integration Platform

Oracle Directory Integration Platform does not support the synchronization of the schema and ACLs. You can use the schemasync tool to identify differences in schema, specifically attributes and object classes, between Oracle Internet Directory and connected directories. After identifying the differences, you can use the schemasync tool to synchronize the schema.

See Also:

Schema Elements Synchronization Utility in Oracle Fusion Middleware Reference for Oracle Identity Management for more information about the schemasync tool.