15 Considerations for Integrating with Third-Party Directories

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 co-exist in the same environment.

The co-existence of directories can require 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.

  To configure simple synchronization with Microsoft Active Directory, see Chapter 16, "Integration with the Microsoft Active Directory Environment".

  To configure simple synchronization with SunONE Directory Server, see Chapter 18, "Integration withSunONE (iPlanet) Directory Server".

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

  Because all Oracle Application Server components depend on the identity management realm, complete integration with the Oracle Application Server 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.

Choose Which Directory Is to Be the Central Enterprise Directory

The central enterprise directory is the source of truth for all user, group, and realm information in the enterprise. It can be either Oracle Internet Directory or a third-party directory.

This section contains these topics:

• Oracle Internet Directory as the Central Enterprise Directory

• Third-Party Directory as the Central Directory

Oracle Internet Directory as the Central Enterprise Directory

If Oracle Internet Directory is the central directory, then, once 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.

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

Figure 15-1 Interaction Between Components with Oracle Internet Directory as the Central Directory

Description of the illustration oidag105.gif

As Figure 15-1 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, Oracle Directory Manager, or the command-line tools.

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

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, Oracle Directory Manager, or the command-line tools.

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

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.

Third-Party Directory as the Central Directory

If a third-party directory is the central directory, then, once 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.

Figure 15-2 shows a typical deployment where a third-party directory is the central enterprise directory.

Figure 15-2 Interaction of Components with a Third-Party Directory as the Central Directory

Description of the illustration oidag106.gif

Process for Provisioning of a User or Group

As Figure 15-2 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 Directory Integration and Provisioning.

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.

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 Directory Integration and Provisioning,

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 15-2 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.

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, and contains these topics:

• Advantages and Disadvantages of Storing the Password in One Directory

• Advantages and Disadvantages of Storing the Password in Both Directories

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

• Create Identical DIT Structures on Both Directories

• Distinguished Name Mapping and Limitations

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:

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

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

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 has uid as its value. This means that the identity used for login is stored in the uid attribute of the user entry.

If the connected directory has a specific attribute for login, 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 login. For example, if you want to use employeeID for logins, then mapping rules can be set accordingly. Doing this does not affect your configuration.

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.

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.

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 the access of any malicious users.

• Synchronization—You can configure the Oracle directory integration and provisioning server to use SSL when connecting to Oracle Internet Directory and third-party directories. If you do this, then all information exchanged between the directory servers is secure.

• Password synchronization—Depending on the configuration, passwords can be synchronized. For instance, 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 Corporation recommends that you configure communication between the directories in SSL with server-only authentication. The sequence of steps to configure communication between connected directories in SSL is as follows:

  1. In the integration profile, to indicate that the mode of communication is SSL, configure the connectedDirectoryURL attribute in the form of host:port:1. Make sure the port number is the SSL port. The default SSL port number is 636.

  2. Generate a certificate from the connected directory. What is required is the trust point certificate from the server. You do not need to use any external certificate server to do this.

  3. Export the certificates to Base 64 encoded format.

  4. Import the certificates as trust points in the Oracle Wallet by using Oracle Wallet Manager.

  5. Specify the wallet location in the odi.properties file in $ORACLE_HOME/ldap/odi/conf.

  6. Store the wallet password by using the Directory Integration and Provisioning Assistant with the wp option.

  7. Start the Oracle directory integration and provisioning server in SSL mode.

Step-by-Step Guide to Configuring Synchronization with a Third-Party Directory

This section lists the steps in configuring a sample deployment scenario.

This section contains these topics:

Step 1: Identify the Default Identity Management Realm in Oracle Internet Directory

Step 2: Identify the User and Group Search Bases in Oracle Internet Directory

Step 3: Identify the Naming Context on the Remote Directory

Step 4: Decide Whether to Create a New Identity Management Realm

Step 5: Select the User Search Base and Group Search Base

Step 6: Select the Login Identifiers

Step 7: Modify the Mapping File to Reflect the Changes You Have Made

Step 8: Create or Modify the Synchronization Profile with the New Set of Mapping Rules

Step 9: Configure Access Control

Step 10: Bootstrap the Directory by Using the Directory Integration and Provisioning Assistant

Step 11: Update the Last Change Number for Synchronization

Step 12: Enable the Profile by Using Either the Oracle Directory Integration and Provisioning Server Administration Tool or the Directory Integration and Provisioning Assistant

Step 13 (Optional): Enable the External Authentication Plug-in for Password Synchronization

Step 14: Start the Oracle Directory Integration and Provisioning Server

Step 1: Identify the Default Identity Management Realm in Oracle Internet Directory

To identify the default identity management realm in Oracle Internet Directory:

ldapsearch –p port -h host -D distinguished_name -w password 
-b "cn=common, cn=products,cn=oraclecontext" -s base "objectclass=*"
orcldefaultsubscriber

In this sample deployment, the default identity management realm in Oracle Internet Directory is dc=us,dc=mycompany,dc=com.

Step 2: Identify the User and Group Search Bases in Oracle Internet Directory

To identify the user and group search contexts in Oracle Internet Directory:

ldapsearch –p port -h host -D distinguished_name -w passwd 
-b "cn=common, cn=products,cn=oraclecontext, Identity Management Realm" 
-s base "objectclass=*"

Note down the values for the orclcommonusersearchbase and orclcommongroupsearchbase attributes. These are the values which are shown in the Oracle Internet Directory Self-Service Console as User Search Context and Group Search Context.

In this sample deployment, the user and group search contexts in Oracle Internet Directory are:

orclcommonusersearchbase is : cn=users,  dc=us,dc=mycompany,dc=com
orclcommongroupsearchbase is : cn=groups,  dc=us,dc=mycompany,dc=com

Step 3: Identify the Naming Context on the Remote Directory

The default naming context is the root of the naming context under which the users are stored. Each directory has its own way of creating a default naming context.

If you are using Microsoft Active Directory, then you identify the default naming context by performing the following ldapsearch against that directory:

ldapsearch –p port -h host -D distinguished_name -w password -b "" –s base "objectclass=*" defaultnamingcontext

Typically the DNs of users in Microsoft Active Directory are of the form cn=user name, cn=users, defaultnamingcontext.

Note that the users also can bind with names such as, username@domain.

For example, if the domain name is newcompany.com, then the default naming context is dc=newcompany,dc=com. The typical login identifier of a user is user@newcompany.com.

If you are using SunONE Directory Server, then you identify the naming contexts in that directory by performing the following ldapsearch against it:

ldapsearch –p port -h host -D distinguished_name -w password -b "" –s base "objectclass=*" namingcontexts

Different sets of user entries reside in different subtrees. Choose the naming context that contains the objects to be synchronized.

Step 4: Decide Whether to Create a New Identity Management Realm

If the DITs on Oracle Internet Directory and the third-party directory are different, then it is better to create a new identify management realm and make it the default realm. Do this by using either the Oracle Internet Directory Self-Service Console or the Oracle Internet Directory Configuration Assistant. On the other hand, if the third-party directory is Microsoft Active Directory in which the default naming context is mycompany.com, then you may not have to create the new identity management realm.

Step 5: Select the User Search Base and Group Search Base

How you do this depends on whether you created a new identity management realm as discussed in the previous step.

If a new identity management realm has been created, then:

1. Select the user search base and the user creation context. Do this by using the Oracle Internet Directory Self-Service Console. Set the user search context to reflect the container under which users are stored in the third-party directory. This is described in the Oracle Identity Management Guide to Delegated Administration.

   Follow the same approach to set the user creation context.

2. Select the group search base and the group creation context. Do this by using the Oracle Internet Directory Self-Service Console. Set the group search context to reflect the container under which groups are stored in the third-party directory. This is described in the Oracle Identity Management Guide to Delegated Administration.

   Follow the same approach to set the group creation context.

If a new identity management realm has not been created, then, to enable user and group entries to be accessed by all Oracle components, you must modify the default parameters in the Oracle Internet Directory Self-Service Console. To do this:

1. In the User Search Context, enter the DN of the users container in the third-party directory, or enter the subtree of the containers specified in the search context. For example, enter either of the following:

   cn=users,dc=myCompany,dc=com

   dc=myCompany,dc=com.

2. In the Group Search Context, either enter the DN of the groups container in the third-party directory, or enter the subtree of the containers specified in the search context. For example, enter either of the following:

   cn=groups,dc=myCompany,dc=com

   dc=myCompany,dc=com

   
   

   See Also: The Oracle Identity Management Guide to Delegated Administration

   
   

Step 6: Select the Login Identifiers

The attribute used for login is orclcommonnicknameattribute. In the Oracle Internet Directory Self-Service Console, the field is named Attribute for Login Name. The default value is UID. Oracle Corporation recommends that you keep the default value. If this attribute is modified—for example, if it is changed to mail—then be sure that all entries under the container that you are working with have the mail attribute value populated. Otherwise, the user cannot login through Oracle Application Server Single Sign-On.

Step 7: Modify the Mapping File to Reflect the Changes You Have Made

The attributes you have just modified can require a change in the default mapping files. Look carefully at the various mapping rules and modify them according to the requirements. If the users and groups are under different containers, you may need to specify multiple set of domain rules in the same mapping file.

Default mapping rules for integration with SunONE Directory Server and Microsoft Active Directory are in the directory $ORACLE_HOME/ldap/odi/conf.

The important parameters to be modified are:

• Mapping rule for the loginid attribute

  • In the default profile for Microsoft Active Directory, the default mapping rule for the loginid attribute in the sample mapping file is:

    Userprincipalname: : :user: uid: : :inetorgperson
    
    

  • In the default profile for SunONE Directory Server, the UID is directly mapped to the UID attribute.

    This can be modified depending on which attribute is used for login. For example, to use employeenumber as the loginid, modify the mapping rule as follows:

    Employeenumber: : :user: uid: : :inetorgperson
    
    

• Mapping rule for the Kerberos login—To support Windows native authentication, Oracle Application Server Single Sign-On uses Kerberos login for the Windows environment. In such cases, a mapping rule is required for the Windows login. The attribute for the Kerberos login is orclcommonkrbprincipalattribute in the entry cn=common,cn=public,cn=oraclecontext,identity_management_realm. By default, it is set to krbPrincipalName.

  For integration with Microsoft Active Directory, the default mapping rule is:

  Userprincipalname: : :user: krbPrincipalName: : :orclUserV2. 
  
  

  This rule maps the user principal name in Microsoft Active Directory to the Kerberos principal name. To support another value for Kerberos login, modify this rule.

  
  

  See Also: Oracle Application Server Single Sign-On Administrator's Guide for information about support for Windows native authentication in Oracle Application Server Single Sign-On

  
  

Step 8: Create or Modify the Synchronization Profile with the New Set of Mapping Rules

To do this, use the Directory Integration and Provisioning Assistant.

dipassistant mp -profile profile_name odip.profile.mapfile=relative_path_name_of_mapping_file

Step 9: Configure Access Control

Configure access control to various containers in either of the following:

• The profile orclodipagentname=profile_name,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory'

• The group cn=odipgroup,cn=odi,cn=oracle internet directory

A sample ACI is available in $ORACLE_HOME/ldap/odi/samples/commonaci.ldif. This sample contains the following attributes, all of which have the same values:

• UserSearchBase

• GroupSearchBase

• UserCreateBase

• GroupCreateBase

You can use Oracle Directory Manager to set ACIs to these containers.

Step 10: Bootstrap the Directory by Using the Directory Integration and Provisioning Assistant

To bootstrap the directory, use the bootstrap command in the Directory Integration and Provisioning Assistant.

Step 11: Update the Last Change Number for Synchronization

To do this, enter:

dipassistant mp –profile profile_name -updlcn

The Directory Integration and Provisioning Assistant determines the connected directory by reading the directory integration profile.

Step 12: Enable the Profile by Using Either the Oracle Directory Integration and Provisioning Server Administration Tool or the Directory Integration and Provisioning Assistant

You can do this by using either the Oracle Directory Integration and Provisioning Server Administration tool or the Directory Integration and Provisioning Assistant.

Step 13 (Optional): Enable the External Authentication Plug-in for Password Synchronization

If you need to synchronize password changes from Oracle Internet Directory to the third-party directory, then enable the external authentication plug-in by doing the following:

• Enable the password policy in the identity management realm. You can do this by using either the Oracle Internet Directory Self-Service Console or Oracle Directory Manager.

• Enable reversible password encryption by setting the orclpwdencryptionenable attribute to TRUE.

When passwords are synchronized to directories that do not support the hashing technique used by Oracle Internet Directory, synchronization can be done only by using the SSL mode 2 (sslmode=2).

Step 14: Start the Oracle Directory Integration and Provisioning Server

Do this by following the instructions in "Starting the Oracle Directory Integration and Provisioning Server by Using the OID Control Utility".

Limitations of Third-Party Integration in Oracle Internet Directory 10g Release 2 (10.1.2)

Oracle Internet Directory 10g Release 2 (10.1.2) does not support the synchronization of the schema and ACLs. If you are changing the schema or ACLs, then you must apply the changes manually. Use the schemasync tool to synchronize the schema between Oracle Internet Directory and a third-party directory.