Oracle® Identity Management Integration Guide
10g Release 2 (10.1.2)
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 an identical DIT structures in both directories in order to use the default installation of Oracle Internet Directory. Alternatively, you can perform domain-level mapping.
This section contains these topics:
Oracle Corporation recommends that you configure identical DITs on both directories. This enables all the user and group objects to be synchronized as they are, and spares you the cumbersome task of mapping entries with distinguished names in one directory to URLs in the other. It also spares you the performance problems that such mapping 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 and provisioning profile to reflect the domain level rules.
To enable users to access Oracle applications through Oracle Application Server Single Sign-On, Oracle Corporation recommends that you identify the DIT as a separate identity management realm with its own authentication and authorization domain.
See Also:The chapter on deploying identity management realms in Oracle Internet Directory Administrator's Guide
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 appropriate DN mapping. However, group entry synchronization may 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.
Suppose that, in a mapping file, the entries in the SunONE 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 SunONE Directory Server is
uid, but on Oracle Internet Directory it is
The mapping file has rules like 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 SunONE Directory Server to Oracle Internet Directory, the
uid attribute must be present. This is because
uid must always be available for constructing the DN of the entry in Oracle Internet Directory.
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 instance, suppose that the user DN values are mapped as follows:
This implies that all the user entries under ou=people,o=iplanet.org are moved to
Group memberships need to be mapped as follows:
uniquemember: : : groupofuniquenames: uniquemember: :groupofuniquenames: dnconvert(uniquemember)
For example, if the value of
cn=testuser1,ou=people,o=iplanet.org, then it becomes
Moreover, if the value of
cn=testuser1,dc=subdomain,ou=people,o=iplanet.org, then it becomes
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 on how to specify a mapping rule