16 Third-Party Directory Integration Concepts and Considerations

This chapter discusses the basic concepts of integrating Oracle Identity Management with a third-party directory along with various decisions to be made as part of the integration process.

Note:

This chapter assumes that you are familiar with:

This chapter contains these topics:

See Also:

The following chapters for specific implementation details on synchronizing with third-party directories:

16.1 Concepts and Architecture of Third-Party Directory Integration

Oracle provides centralized security administration for all Oracle components by integrating them with Oracle Identity Management. If your environment uses both Oracle Identity Management and third-party 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 Oracle Internet Directory to synchronize with a connected directory.

This section discusses the Oracle components and architecture involved in integrating Oracle Identity Management with connected third-party directories. It contains these topics:

Note:

Refer to the Oracle Identity Management Certification Information for information about third-party directories and servers certified for integration with Oracle Internet Directory 11g Release 1 (11.1.1).

You can access the Oracle Identity Management Certification Information from the Oracle Technology Network web site at:

http://www.oracle.com/technology/index.html

16.1.1 Oracle Identity Management Components for Integrating with a Third-Party Directory

This section describes the following components that are used to integrate Oracle Identity Management with a third-party directory:

See Also:

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

Oracle Internet Directory

Oracle Internet Directory is the repository in which Oracle components and third-party applications store and access user identities and credentials. It uses the Oracle directory server to authenticate users by comparing the credentials entered by users with the credentials stored in Oracle Internet Directory. When credentials are stored in a third-party directory and not in Oracle Internet Directory, users can still be authenticated. In this case, Oracle Internet Directory uses an external authentication plug-in that authenticates users against the third-party directory server.

See Also:

The chapter on security in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for a discussion of security in Oracle Internet Directory

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 Oracle Internet Directory or on a different host.

Oracle Directory Integration Platform enables:

  • Synchronization between Oracle Internet Directory and other directories and user repositories

  • Automatic provisioning services for Oracle components

Oracle Directory Integration Platform includes connectors to synchronize Oracle Internet 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 third-party 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

Oracle Delegated Administration Services

Oracle Delegated Administration Services is a set of pre-defined, Web-based units for performing directory operations on behalf of a user. It frees directory administrators from the more routine directory management tasks by enabling them to delegate specific functions to other administrators and to end users. It provides most of the functionality that directory-enabled applications require, such as creating a user entry, creating a group entry, searching for entries, and changing user passwords. To administer application data in the directory, you use the Oracle Internet Directory Self-Service Console, a tool based on Oracle Delegated Administration Services. This tool comes ready to use with Oracle Internet Directory. Or, you can use Oracle Delegated Administration Services to develop your own tools for administering application data.

See Also:

Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management

Oracle Application Server Single Sign-On

OracleAS Single Sign-On Server enables users to access Oracle Web-based components by logging in only once.

Oracle components delegate the login function to the OracleAS Single Sign-On Server. When a user first logs in to an Oracle component, the component directs the login to the OracleAS Single Sign-On Server. The OracleAS Single Sign-On Server compares the credentials entered by the user to those stored in Oracle Internet Directory. After verifying the credentials, the OracleAS Single Sign-On Server grants the user access to all components the user is authorized to use throughout the current session.

Oracle Application Server Single Sign-On enables native authentication in a Microsoft Windows environment. Once logged in to the Windows environment, the user automatically has access to Oracle components. OracleAS Single Sign-On Server automatically logs in the user to the Oracle environment using the user's Kerberos credentials.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Single Sign-On for information about OracleAS Single Sign-On Server

External Authentication Plug-ins

External authentication plug-ins, such as the Microsoft Active Directory external authentication plug-in, are part of the Oracle directory server, and enable users to log in to the Oracle environment by using their Microsoft Windows credentials. 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 third-party directory. If the verification is successful, then the Oracle directory server notifies OracleAS Single Sign-On Server.

16.1.2 Oracle Internet Directory Schema Elements for Synchronizing with Third-Party Directories

To identify objects that are synchronized with those in a third-party directory, Oracle Internet Directory contains schema elements that correspond to attributes that are specific to third-party directories, such as Microsoft Active Directory. These schema elements are described in the following sections:

16.1.3 Directory Information Tree in an Integration with a Third-Party Directory

This section contains these topics:

See Also:

The chapter on directory concepts and architecture in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for a fuller discussion of directory information trees

16.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. It 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 Internet 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 16-1 illustrates the default identity management realm.

Figure 16-1 The Default Identity Management Realm

This illustration is described in the text.

As Figure 16-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

16.1.3.2 Planning the Deployment

When planning the DIT, 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 "Choose the Structure of the Directory Information Tree" for more information about planning the directory information tree

16.1.3.3 Example: Integration with a Single Third-Party Directory Domain

Figure 16-2 shows an example of one-to-one mapping between Oracle Internet Directory and a third-party directory.

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

This illustration is described in the text.
Description of "Figure 16-2 Default DIT Structures in Oracle Internet Directory and a Third-Party Directory When Both Directory Hosts Are Under the Domain us.MyCompany.com"

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

  • Both Oracle Internet Directory and the third-party directory hosts have the same topology.

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

  • The same DIT structure is maintained in both the third-party 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 , only the users subtree must be synchronized from the third-party directory to Oracle Internet Directory using one-to-one domain mappings.

Note:

In , 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 third-party directory.

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

16.2 Planning Your Integration Environment

This section describes how to plan your integration environment. It contains these topics:

16.2.1 Preliminary Considerations for Integrating with a Third-Party Directory

If you are deploying Oracle Internet 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 Oracle Internet Directory to support Enterprise User Security. Use this approach if your environment supports enterprise users by using a database server.

  • 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 third-party 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.

16.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. It contains these topics:

16.2.2.1 Oracle Internet Directory as the Central Enterprise Directory

If Oracle Internet Directory is the central directory, then, once the user, group, and realm objects are created, Oracle Internet Directory becomes the source of provisioning information for all Oracle components and third-party directories. The user and group objects for the entire enterprise are then provisioned in various Oracle components and third-party directories from Oracle Internet Directory.

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

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

Requirement Description

Initial startup

The syncProfileBootstrap command populates the third-party directory with users and groups stored in Oracle Internet Directory.

Synchronization

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

Synchronization from the third-party directory into Oracle Internet Directory can be achieved by configuring an import profile.

Passwords and password verifiers

Passwords are managed in Oracle Internet Directory by using Oracle tools such as the Oracle Internet Directory Self-Service Console. Password changes are synchronized with the third-party directory by the Oracle Directory Integration Platform. However, before this server can synchronize the password changes, the password synchronization must be configured in the mapping rules.

Because the password is securely managed, the communication for synchronizing passwords to the third-party directory must be over SSL. Run the Oracle Directory Integration Platform in the server authentication mode with the proper certificate from the third-party directory. Be sure that the third-party directory is also enabled for SSL.

If the Oracle environment requires a password verifier, then the password verifier is automatically generated when a new user entry is created or when a password is modified.

Oracle Application Server Single Sign-On

Users log in to the Oracle environment by using the OracleAS Single Sign-On Server.

When called upon by the OracleAS Single Sign-On Server to authenticate a user, the Oracle directory server uses credentials available locally. No external authentication is involved.

Users must log in only once to access various components in the Oracle environment.

New users or groups in Oracle Internet Directory can be automatically provisioned by the Oracle Directory Integration Platform. This automatic provisioning requires that:

  • The Oracle directory server is running with the change log enabled

  • The change log is not purged

If these two conditions are not met, then you must dump the entries in Oracle Internet Directory to an LDIF file and upload the data to the third-party 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

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

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

This illustration is described in the text.

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

  1. The user or group entry is created in Oracle Internet Directory by using the Oracle Internet Directory Self-Service Console or command-line tools.

  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 third-party directory.

  4. The user and group entry is created in the third-party directory.

A user entry is modified in Oracle Internet Directory, when:

  • A new attribute gets added to the entry.

  • The value of an existing attribute is modified.

  • An existing attribute is deleted.

When Oracle Internet 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 Internet Directory Self-Service Console 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 Internet Directory is appropriately mapped to the corresponding attribute in the connected directory.

  4. The user entry is modified in the third-party directory.

16.2.2.2 Third-Party Directory as the Central Enterprise Directory

If a third-party directory is the central enterprise directory, then, once the user, group, and realm objects are created, the third-party directory becomes the source of provisioning information for all Oracle components and other directories. In this case, Oracle Internet Directory is deployed to support Oracle components. To provide this support, Oracle Internet Directory stores a footprint that enables it to identify entries in the third-party directory.

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

Table 16-2 Typical Requirements with a Third-Party Directory as the Central Enterprise Directory

Requirement Description

Initial startup

The syncProfileBootstrap command populates Oracle Internet Directory with users and groups stored in the third-party directory.

You can choose to manage user information, including password credentials, in the third-party 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 third-party directory to Oracle Internet Directory.

Synchronization

The central directory for user and group information is a third-party directory. Changes to user and group information in the third-party directory are synchronized with Oracle Internet Directory by the Oracle Directory Integration Platform when an import profile has been configured.

Synchronization from Oracle Internet Directory to the third-party directory is achieved by configuring an export profile.

Passwords and password verifiers

Passwords are managed in the third-party directory. The Oracle Directory Integration Platform does not synchronize password changes into Oracle Internet Directory.

Oracle Application Server Single Sign-On

Users log in to the Oracle environment only once by using the OracleAS Single Sign-On Server.

Users with credentials only in the third-party directory are authenticated by the Oracle directory server invoking the external authentication plug-in.

Users with credentials in Oracle Internet Directory are authenticated locally by the Oracle directory server.

Third-party directory external authentication plug-in

When user credentials are managed in the third-party directory, this plug-in is required. To authenticate a user, the OracleAS Single Sign-On Server calls upon the Oracle directory server. The plug-in then performs the authentication of the user against the user credentials stored in the third-party directory.

New users or groups created in the third-party directory are automatically synchronized into Oracle Internet Directory by the Oracle Directory Integration Platform. Before the provisioning can take place, a one-way synchronization between the third-party directory and Oracle Internet Directory must be established.

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

Figure 16-4 Interaction of Components with a Third-Party Directory as the Central Enterprise Directory

This illustration is described in the text.
16.2.2.2.1 Process for Provisioning of a User or Group

As Figure 16-4 shows, when a third-party directory is the central enterprise directory, typical provisioning of a user or group follows this process:

  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 Oracle Internet Directory.

  4. The user or group entry is created in Oracle Internet Directory.

16.2.2.2.2 Process for Modifying a User or Group Entry

An entry is modified in the third-party directory when:

  • A new attribute gets added to the entry.

  • The value of an existing attribute is modified.

  • An existing attribute is deleted.

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

  1. The entry is modified in the third-party 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 third-party directory is appropriately mapped to the corresponding attribute in Oracle Internet Directory.

  4. The user or group entry is modified in Oracle Internet Directory.

As Figure 16-4 shows, when a third-party directory is the central enterprise directory, modification of passwords happens asynchronously in the directory that serves as the password repository. This happens by using plug-ins.

16.2.3 Customizing the LDAP Schema

Customizing the LDAP schema is required if:

  • A directory deployment contains schema extensions such as custom object classes and attributes

  • 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:

16.2.4 Choose 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:

16.2.4.1 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 third-party directory fails, then even though user footprints are available in Oracle Internet Directory, users cannot access Oracle components.

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 using an external authentication plug-in.

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.

16.2.4.2 Advantages and Disadvantages of Storing Passwords in Both Directories

If you decide to store passwords in both Oracle Internet Directory and a third-party directory, then passwords need to be synchronized, ideally in real-time.

In Oracle Internet Directory 11g Release 1 (11.1.1), passwords are not synchronized 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.

In deployments with Oracle Internet Directory as the central directory, password values are synchronized regularly from Oracle Internet Directory to the connected directory. This requires you to enable both the password policy of the realm and reversible encryption.

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. For security reasons, password synchronization is possible with Oracle Internet Directory only in SSL server authentication mode.

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 Internet Directory. You must configure it.

In deployments where Oracle Internet 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 chapter for information about plug-ins:

16.2.5 Choose the Structure of the Directory Information Tree

At installation, each directory server 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. When integrating with a third-party directory, you must create identical DIT structures in both directories to use the default installation of Oracle Internet Directory. Alternatively, you can perform domain-level mapping.

This section contains these topics:

16.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

16.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 Internet Directory and the connected directory. For example, suppose that all entries under the container dc=mydir,dc=com must be synchronized under dc=myoid,dc=com in Oracle Internet 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.

16.2.5.2.1 Example: User Entry Mapping

Suppose that, in a mapping file, the entries in the Oracle Directory Server Enterprise Edition (previously Sun Java System Directory Server) have the format uid=name,ou=people,o=iplanet.org. Suppose further that the entries in Oracle Internet Directory 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.

16.2.5.2.2 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

16.2.6 Select the 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 Oracle Internet Directory as the value of the attribute orclcommonnicknameattribute, under the container cn=common,cn=products,cn=oracleContext,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 Internet Directory. This needs to be one of the mapping rules in the mapping file for the connector associated with synchronizing with the third-party 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.

Note:

The orclcommonnicknameattribute attribute is used extensively by Oracle Application Server Single Sign-On, so be sure to plan carefully how you intend to map the attribute to a third-party directory attribute. After you modify this attribute, you must refresh Oracle Application Server Single Sign-On for the change to take effect.

See Also:

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

16.2.7 Select 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, either set the user search context value to cover the entire user population, or 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

16.2.8 Select the Group Search Base

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

16.2.9 Decide How 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 Internet Directory and third-party directories. If you do this, then all information exchanged among the directory servers is secure.

  • 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.

16.2.10 Administering Your Deployment with Oracle Access Manager

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

See Also:

Oracle Access Manager Identity and Common Administration Guide for information about how to administer users in Oracle Access Manager

16.3 Microsoft Active Directory Integration Concepts

This section contains additional considerations for integrating Oracle Internet Directory with Microsoft Active Directory. It contains these topics:

See Also:

Chapter 18, " Integrating with Microsoft Active Directory"

16.3.1 Synchronizing from Microsoft Active Directory to Oracle Internet Directory

To synchronize changes from Microsoft Active Directory to Oracle Internet 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 16-3 compares the two approaches.

Table 16-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.

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 Oracle Internet 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 http://support.microsoft.com/ 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 Oracle Internet 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 Oracle Internet 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:

"Synchronizing from Oracle Internet Directory to a Connected Directory"

16.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 Oracle Internet 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, Oracle Internet 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.

16.3.3 Windows Native Authentication

This section describes how Windows Native Authentication can be used with the Oracle Directory Integration Platform. It contains these topics:

16.3.3.1 Understanding Windows Native Authentication

Windows Native Authentication is an authentication scheme for users of Microsoft Internet Explorer on Microsoft Windows. When this feature is enabled in OracleAS Single Sign-On Server, users log in to OracleAS Single Sign-On Server partner applications automatically. To do this, they use Kerberos credentials obtained when the user logged in to a Windows domain.

Using the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol, Internet Explorer version 5.0 and later can automatically pass the user's Kerberos credentials to a requesting Kerberos-enabled Web server. The Web server can then decode the credentials and authenticate the user.

You cannot use Microsoft integrated security or any other type of security mechanism when integrating Oracle Application Server Single Sign-On with Windows Native Authentication. Although the SPNEGO protocol supports both Kerberos version 5 and NT Lan Manager (NTLM) authentication schemes, Oracle Application Server 11g Release 1 (11.1.1) supports only Kerberos V5 with SPNEGO.

Note:

Although this chapter refers only to Windows 2000, Windows Native Authentication is also supported on the Windows XP platform.

If the browser is not Internet Explorer 5.0 or higher, then Oracle Identity Management authenticates the user by using OracleAS Single Sign-On Server. Authentication to an external directory is performed by using an external authentication plug-in.

The following steps, shown in Figure 16-5, describe what happens when a user tries to access a single-sign-on-protected application:

  1. The user logs in to a Kerberos realm, or domain, on a Windows computer.

  2. The user attempts to access a single-sign-on partner application using Internet Explorer.

  3. The application routes the user to the single sign-on server for authentication. As part of this routing, the following occurs:

    1. The browser obtains a Kerberos session ticket from the Key Distribution Center (KDC).

    2. The OracleAS Single Sign-On Server verifies the Kerberos session ticket and, if the user is authorized, then the user is allowed to access the requested URL.

  4. The application provides content to the user.

Figure 16-5 Flow for Windows Native Authentication

This illustration is described in the text.
Description of "Figure 16-5 Flow for Windows Native Authentication"

When the user logs out of the Windows session, this application and any single sign-on applications accessed are logged out at the same time.

To use Windows Native Authentication in deployments where Microsoft Active Directory is the central directory, a user must exist in Microsoft Active Directory. If Windows Native Authentication is enabled, then, for local Oracle Internet Directory users to invoke the single sign-on server, you must populate the attributes orclsamaccountname and krbprincipalname for each user entry.

16.3.3.2 Authenticating Users Against Multiple Microsoft Active Directory Domains

To authenticate users against multiple Microsoft Active Directory domains that are part of a single forest, create a global catalog and have Oracle Application Server Single Sign-On connect to the global catalog for authentication. However, if the domains are not part of the same forest, then you must create domain trusts between the domains. For detailed configuration procedures, refer to "Configuring Windows Native Authentication".

16.3.3.3 Overriding an Application Authentication Mechanism with Windows Native Authentication

Windows Native Authentication does not automatically override an application's existing authentication mechanism. To use Windows Native Authentication and Oracle Application Server Single Sign-On with an application that contains an internal authentication mechanism, you must perform one of the following tasks:

  • Remove the application's internal authentication mechanism.

  • Configure the application as an Oracle Application Server Single Sign-On external application. This requires storing a valid application user name and password in the application configuration, making the authentication process transparent to the user after he or she logs in with Oracle Application Server Single Sign-On. For more information, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Single Sign-On.

16.3.4 Oracle Internet Directory Schema Elements for Microsoft Active Directory

Table 16-4 lists the schema elements in Oracle Internet Directory for users that are imported from Microsoft Active Directory.

Table 16-4 Oracle Internet 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 Oracle Internet Directory from Microsoft Active Directory.

orclObjectSID

Stores Microsoft Active Directory's OBJECTSID attribute value for users and groups migrated to Oracle Internet Directory from Microsoft Active Directory.

orclSAMAccountName

Stores the value of Microsoft Active Directory's SAMAccountName attribute. In Oracle Internet 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 Oracle Internet Directory with this attribute, it can only contain a simple text string or synchronization from Oracle Internet 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 Oracle Internet 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 Oracle Internet 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 User Reference for Oracle Identity Management for detailed information about the Oracle Internet Directory schema elements for Microsoft Active Directory

16.3.5 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 16-6 shows how a forest in Microsoft Active Directory is reflected in Oracle Internet Directory.

Figure 16-6 Mapping Between Oracle Internet Directory and a Forest in Microsoft Active Directory

This illustration is described in the text.
Description of "Figure 16-6 Mapping Between Oracle Internet 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 Oracle Internet Directory.

Considerations for Deployments where Oracle Internet 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 provisions users and groups in the respective Microsoft Active Directory domains. Before provisioning can take place, you must configure a one-way synchronization from Oracle Internet 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 Oracle Internet 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 Oracle Internet Directory. Before the provisioning can take place, a one-way synchronization between Oracle Internet Directory and a domain controller on each Microsoft Active Directory domain must be established.

16.3.6 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:

16.3.6.1 Configuration Required for Importing from Microsoft Active Directory to Oracle Internet 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 Oracle Internet 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

16.3.6.2 Configuration Required for Importing from Microsoft Active Directory Lightweight Directory Service to Oracle Internet 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 Oracle Internet Directory. To import entries from Microsoft AD LDS to Oracle Internet Directory, you must configure an import profile connecting to Microsoft AD LDS with the respective port details.

16.3.6.3 Configuration Required for Exporting from Oracle Internet 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.

16.3.6.4 Example: Integration with Multiple Third-Party Directory Domains

A deployment of a third-party directory with multiple domains can have either a single DIT or a combination of two or more DITs. Figure 16-7 shows how multiple domains in a third-party directory are mapped to a DIT in Oracle Internet Directory.

Figure 16-7 Example of a Mapping Between Oracle Internet Directory and Multiple Domains in Microsoft Active Directory

This illustration is described in the text.
Description of "Figure 16-7 Example of a Mapping Between Oracle Internet Directory and Multiple Domains in Microsoft Active Directory"

In Figure 16-7, the third-party 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 Oracle Internet Directory. The second child domain b.us.MyCompany.com maps to dc=b,dc=us,dc=MyCompany,dc=com in Oracle Internet Directory. The common domain component in the third-party directory environment us.MyCompany.com maps to the default identity management realm in Oracle Internet Directory, in this case dc=us,MyCompany,dc=com.

16.3.7 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 Oracle Internet Directory.

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

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

See Also:

Chapter 20, "Integrating with Oracle Directory Server Enterprise Edition (Sun Java System Directory Server)"

16.4.1 Synchronizing from Oracle Directory Server Enterprise Edition (Sun Java System Directory Server) 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:

  • "Synchronizing from Oracle Internet Directory to a Connected Directory".

  • The Oracle Internet Directory server administration tools chapter of the Oracle Identity Management User Reference for instructions on how to start an Oracle Internet Directory server with change logging enabled.

  • Oracle Directory Server Enterprise Edition (previously Sun Java System Directory Server) documentation for instructions on 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.

16.4.2 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 (previously Sun Java System Directory Server). 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.

16.5 IBM Tivoli Directory Server Integration Concepts

This section contains additional considerations for integrating Oracle Internet Directory with IBM Tivoli Directory Server. It contains these topics:

16.5.1 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 Oracle Internet Directory makes use of this change log.

Note:

Tombstone is supported in IBM Tivoli Directory Server version 6.2.

16.5.2 Oracle Internet Directory Schema Elements for IBM Tivoli Directory Server

Table 16-5 lists the schema elements in Oracle Internet Directory for users that are imported from IBM Tivoli Directory Server:

Table 16-5 Oracle Internet 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:

16.6 Novell eDirectory and OpenLDAP Integration Concepts

This section contains additional considerations for integrating Oracle Internet Directory with Novell eDirectory or OpenLDAP. It contains these topics:

See Also:

Chapter 22, "Integrating with Novell eDirectory or OpenLDAP"

16.6.1 Synchronizing from Novell eDirectory or OpenLDAP to Oracle Internet Directory

To synchronize changes from Novell eDirectory or OpenLDAP to Oracle Internet 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 Oracle Internet 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 Oracle Internet 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 Oracle Internet 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:

16.6.2 Oracle Internet Directory Schema Elements for Novell eDirectory

Table 16-6 lists the schema elements in Oracle Internet Directory for users that are imported from Novell eDirectory.

Table 16-6 Oracle Internet 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:

Oracle Fusion Middleware User Reference for Oracle Identity Management for detailed information about the Oracle Internet Directory schema elements for Novell eDirectory

16.6.3 Oracle Internet Directory Schema Elements for OpenLDAP

Table 16-7 lists the schema elements in Oracle Internet Directory for users that are imported from OpenLDAP.

Table 16-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:

Oracle Fusion Middleware User Reference for Oracle Identity Management for detailed information about the Oracle Internet Directory schema elements for OpenLDAP

16.7 Limitations of Third-Party Integration in Oracle Directory Integration Platform 11g Release 1 (11.1.1)

Oracle Directory Integration Platform 11g Release 1 (11.1.1) 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:

The Oracle Fusion Middleware User Reference for Oracle Identity Management for more information about the schemasync tool.