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:
-
Concepts and Architecture of Connected Directory Integration
-
Oracle Directory Server Enterprise Edition (Sun Java System Directory Server) Integration Concepts
-
Limitations of Connected Directory Integration in Oracle Directory Integration Platform
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:
-
Oracle Identity Management Components for Integrating with Other Directories
-
Oracle Back-end Directory Schema Elements for Synchronizing with Connected Directories
-
Directory Information Tree in an Integration with a Connected Directory
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
For more information, see Using Oracle Directory Services Manager for Oracle Internet Directory.
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:
-
The section "Understanding Pass-Through Authentication" in the Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory.
-
The section "Pass-Through Authentication" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Server Enterprise Edition.
-
If Oracle Internet Directory is the Oracle back-end directory, see the chapter on security in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for a discussion about security.
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:
-
Oracle Back-end Directory Schema Elements for Microsoft Active Directory
-
Understanding Oracle Back-end Directory Schema Elements for IBM Tivoli Directory Server
-
Understanding Oracle Back-end Directory Schema Elements for Novell eDirectory
-
Understanding Oracle Back-end Directory Schema Elements for OpenLDAP
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:
-
About Suffixes in Oracle Unified Directory and Oracle Directory Server Enterprise Edition
-
Example: Integration with a Single Connected Directory Domain
See Also:
-
Understanding the Concepts and Architecture of Oracle Internet Directory in Oracle Fusion Middleware Administering Oracle Internet Directory for information on directory information trees.
-
Planning, Deploying and Managing Realms section in Oracle Fusion Middleware Administering Oracle Internet Directory for information on the deployment of identity management realms.
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

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
andgroups
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 theuser
container, thegroup
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
andgroups
containers respectively. If you have updated yourusersearchbase
andgroupsearchbase
in the realm, then set up appropriate ACLs on theusers
container andgroups
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 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:
-
The chapter on garbage collection in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for information about purging the change log.
-
“Replicating Directory Data" in the Oracle Fusion Middleware Administering Oracle Unified Directory.
-
“Directory Server Replication" chapter in Oracle Fusion Middleware Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 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:
-
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.
-
At the next scheduled interval, that entry creation event is read by the third-party directory connector in Oracle Directory Integration Platform.
-
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.
-
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:
-
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.
-
At the next scheduled interval, that entry modification event is read by the third-party directory connector in Oracle Directory Integration Platform.
-
Following the mapping information in the integration profile, the attribute in Oracle Directory is appropriately mapped to the corresponding attribute in the connected directory.
-
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
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:
-
The user or group entry is created in the third-party directory.
-
At the next scheduled interval, the entry creation event is read by the third-party directory connector in Oracle Directory Integration Platform.
-
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.
-
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:
-
The entry is modified in the connected directory.
-
At the next scheduled interval, that entry modification event is read by the third-party directory connector in Oracle Directory Integration Platform.
-
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.
-
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:
-
The chapter on administering the schema in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for instructions on customizing the schema in Oracle Internet Directory.
-
The chapter “Managing Directory Schema" in the Oracle Fusion Middleware Administering Oracle Unified Directory.
-
The chapter “Directory Server Schema" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Server Enterprise Edition.
-
Microsoft documentation available at
http://msdn.microsoft.com/
for instructions on customizing the schema in Microsoft Active Directory.
-
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:
-
The chapter in Oracle Fusion Middleware Administering Oracle Internet Directory about password policies for information about setting password policies
-
The chapter in Oracle Fusion Middleware Administering Oracle Internet Directory about directory storage of password verifiers for information about reversible encryption
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:
-
Advanced Administration: Directory Plug-ins in Oracle Fusion Middleware Administering Oracle Internet Directory about the directory plug-in framework
-
Configuring a Customized External Authentication Plug-in in Oracle Fusion Middleware Administering Oracle Internet Directory about customizing the external authentication plug-in
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.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:
-
Understanding How to Synchronize from Microsoft Active Directory to the Oracle Back-end Directory
-
Oracle Back-end Directory Schema Elements for Microsoft Active Directory
-
About Integration with Multiple Microsoft Active Directory Domain Controllers
-
Synchronizing with a Multiple-Domain Microsoft Active Directory Environment
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 |
Presents changes to the distinguished name. The |
Enabling the Connectors |
The connector is enabled by setting the property |
The connector is enabled by setting the property |
Template File |
The synchronization profile template file is |
The synchronization profile template file is |
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 |
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 |
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: |
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:
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:
|
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 |
---|---|
|
Stores Microsoft Active Directory's |
|
Stores Microsoft Active Directory's |
|
Stores the value of Microsoft Active Directory's |
|
Stores the Kerberos user principal name for Microsoft Active Directory users. |
|
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. |
|
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. |
|
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 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 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:
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:
-
"Understanding Synchronization from the Back-end Directory to a Connected Directory".
-
"Oracle Internet Directory Administration Tools" in the Oracle Fusion Middleware Reference for Oracle Identity Management for instructions about how to start an Oracle directory server with change logging enabled.
-
Oracle Directory Server Enterprise Edition documentation for instructions about how to configure change logging. If you plan to synchronize with either Sun Java System Directory Server versions 5.0 or later, or Oracle Directory Server Enterprise Edition, the retro change log plug-in must be enabled.
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 |
---|---|
|
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. |
|
Represents the entryUUID value for the respective entry in IBM Tivoli. This value is used as the synchronization key. |
|
Represents the Tivoli directory object. |
See Also:
-
"Understanding Synchronization from the Back-end Directory to a Connected Directory".
-
"Oracle Internet Directory Administration Tools" in the Oracle Fusion Middleware Reference for Oracle Identity Management for instructions about how to start an Oracle directory server with change logging enabled.
-
IBM Tivoli Directory Server documentation for instructions on how to configure change logging.
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:
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:
-
"Understanding Synchronization from the Back-end Directory to a Connected Directory"
-
"Customizing the Novell eDirectory or OpenLDAP Connector to Synchronize Deletions" for information about how to search specific subsets of the DIT when synchronizing deletions between the Oracle back-end directory and Novell eDirectory or OpenLDAP
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 |
---|---|
|
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. |
|
Required for reconciliation. Represents the GUID value for the respective entry in Novell eDirectory. This value is used as the synchronization key. |
|
Required. Represents the |
|
Required. Represents the |
|
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 |
---|---|
|
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. |
|
Required for reconciliation. Represents the entryUUID value for the respective entry in OpenLDAP. This value is used as the synchronization key. |
|
Required. Represents the |
|
Required. Represents the |
|
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.