Oracle® Identity Management Integration Guide 10g (10.1.4.0.1) Part Number B15995-01 |
|
|
View PDF |
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:
Concepts and Architecture of Third-Party Directory Integration
Limitations of Third-Party Integration in Oracle Internet Directory 10g (10.1.4.0.1)
See Also: The following chapters for specific implementation details on synchronizing with third-party directories: |
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:
Supported Third-Party Directories and ServersSupported Third-Party Directories and Servers
Oracle Identity Management Components for Integrating with a Third-Party Directory
Oracle Internet Directory Schema Elements for Synchronizing with Third-Party Directories
Directory Information Tree in an Integration with a Third-Party Directory
Oracle Internet Directory 10g (10.1.4.0.1) is certified for integration with the following third-party directories and servers:
Microsoft Active Directory 2000/2003
Microsoft Exchange 2000/2003
Sun Java System Directory 5.2. Sun Java System Directory has formerly been known as Sun ONE Directory Server, iPlanet Directory Server, and Netscape Directory Server, respectively. Oracle Internet Directory 10g (10.1.4.0.1) is certified for integration with all versions starting with Netscape Directory Server 4.13.
Novell eDirectory 8.6.2 and 8.7
OpenLDAP-2.2
This section describes the following components that are used to integrate Oracle Identity Management with a third-party directory:
See Also: Chapter 3, "Oracle Directory Integration Platform Administration Tools" 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 Internet Directory Administrator's Guide for a discussion of security in Oracle Internet Directory |
Oracle Directory Integration Platform
Oracle Directory Integration Platform is installed as part of the Oracle Application Server infrastructure. 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.
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.
Oracle Access Manager
In addition to Oracle Delegated Administration Services, you can also use Oracle Access Manager to perform directory operations. Oracle Access Manager (formerly known as Oblix NetPoint and Oblix COREid) provides a full range of identity administration and security functions that include Web single sign-on, user self-service and self-registration, sophisticated workflow functionality, user provisioning, reporting and auditing, policy management, dynamic group management, and delegated administration.
Oracle Application Server Single Sign-On
OracleAS Single Sign-On 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 automatically logs in the user to the Oracle environment using the user's Kerberos credentials.
See Also: Oracle Application Server Single Sign-On Administrator's Guide for information about OracleAS Single Sign-On |
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.
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 Oracle Identity Management User Reference and in the following sections:
This section contains these topics:
See Also: The chapter on directory concepts and architecture in Oracle Internet Directory Administrator's Guide for a fuller discussion of directory information trees |
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
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 Application Server.
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.
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 17-1 illustrates the default identity management realm.
As Figure 17-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 Internet Directory Administrator's Guide for a description of the default realm installed with Oracle Internet Directory |
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 |
Figure 17-2 shows an example of one-to-one mapping between Oracle Internet Directory and a third-party directory.
Figure 17-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 17-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. |
This section describes how to plan your integration environment. It contains these topics:
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 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.
This section explains how to choose which directory is to be the central enterprise directory. It contains these topics:
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 17-1 describes the typical requirements in this deployment.
Table 17-1 Typical Requirements with Oracle Internet Directory as the Central Enterprise Directory
Requirement | Description |
---|---|
Initial startup |
The Directory Integration Assistant ( |
Synchronization |
User and group information is managed in Oracle Internet Directory. Changes to that information are synchronized with the third-party directory by the Oracle directory integration server when an import 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 server. 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 server 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 Internet Directory Administrator's Guide for information about purging the change log |
Figure 17-3 shows a typical deployment in which Oracle Internet Directory is the central enterprise directory.
Figure 17-3 Interaction Among Components with Oracle Internet Directory as the Central Enterprise Directory
As Figure 17-3 shows, when Oracle Internet Directory is the central enterprise directory, typical provisioning of a user or group follows this process:
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.
At the next scheduled interval, that entry creation event is read by the third-party directory connector in Oracle Directory Integration Platform.
Following the mapping information in the integration profile, the user or group attributes in Oracle Internet Directory are appropriately mapped to the corresponding user or group attributes as required by the schema in the third-party directory.
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:
The entry is modified by using the Oracle Internet Directory Self-Service Console, Oracle Directory Manager, or the command-line tools.
At the next scheduled interval, that entry modification event is read by the third-party directory connector in Oracle Directory Integration Platform.
Following the mapping information in the integration profile, the attribute in Oracle Internet Directory is appropriately mapped to the corresponding attribute in the connected directory.
The user entry is modified in the third-party 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 17-2 describes the typical requirements in this deployment.
Table 17-2 Typical Requirements with a Third-Party Directory as the Central Enterprise Directory
Requirement | Description |
---|---|
Initial startup |
The Directory Integration Assistant ( 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 server 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 server 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 server 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 server. Before the provisioning can take place, a one-way synchronization between the third-party directory and Oracle Internet Directory must be established.
Figure 17-4 shows a typical deployment where a third-party directory is the central enterprise directory.
Figure 17-4 Interaction of Components with a Third-Party Directory as the Central Enterprise Directory
As Figure 17-4 shows, when a third-party directory is the central enterprise directory, typical provisioning of a user or group follows this process:
The user or group entry is created in the third-party directory.
At the next scheduled interval, the entry creation event is read by the third-party directory connector in Oracle Directory Integration Platform.
Following the mapping information in the integration profile, the user or group attributes in the third-party directory are mapped to the corresponding attributes in Oracle Internet Directory.
The user or group entry is created in Oracle Internet Directory.
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:
The entry is modified in the third-party directory.
At the next scheduled interval, that entry modification event is read by the third-party directory connector in Oracle Directory Integration Platform.
Following the mapping information in the integration profile, the attribute in the third-party directory is appropriately mapped to the corresponding attribute in Oracle Internet Directory.
The user or group entry is modified in Oracle Internet Directory.
As Figure 17-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.
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:
|
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:
Advantages and Disadvantages of Storing the Password in One Directory
Advantages and Disadvantages of Storing Passwords in Both Directories
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. |
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 10g (10.1.4.0.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 Sun Java System Directory and Oracle Internet Directory are integrated. Both of these directories support common hashing algorithms. If the passwords are hashed and stored in Sun Java System Directory by using a hashing technique supported by Oracle Internet Directory, then synchronizing Sun Java System Directory 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:
|
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:
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 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 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.
Suppose that, in a mapping file, the entries in the Sun Java System Directory 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 Sun Java System Directory 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 Sun Java System Directory 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.
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:
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.
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: Theorclcommonnicknameattribute 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 Identity Management Guide to Delegated Administration for instructions about setting the attribute for login name |
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 Identity Management Guide to Delegated Administration for instructions about setting the user search context |
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 Identity Management Guide to Delegated Administration for instructions about setting the group search context |
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 server 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 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 recommends that you configure communication between the directories in SSL server authentication mode.
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 |
This section contains additional considerations for integrating Oracle Internet Directory with Microsoft Active Directory. It contains these topics:
Synchronizing from Microsoft Active Directory to Oracle Internet Directory
Oracle Internet Directory Schema Elements for Microsoft Active Directory
Integration with Multiple Microsoft Active Directory Domain Controllers
Synchronizing with a Multiple-Domain Microsoft Active Directory Environment
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 17-3 compares the two approaches.
Table 17-3 Comparing the DirSync Approach to the USN-Changed Approach
Considerations | DirSync Approach | USN-Changed Approach |
---|---|---|
Change key |
Presents changes to the |
Presents changes to the distinguished name. The |
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 |
Required user privileges |
Requires the user to have the Replicate Changes privilege on the naming context of interest. This enables reading all objects and attributes in Microsoft Active Directory regardless of the access protections on them. See Also: The Microsoft Knowledge Base Article 303972 available at |
Requires the Microsoft Active Directory user to have the privilege to read all required attributes to be synchronized to Oracle Internet Directory. See Also: Microsoft networking and directory documentation available in the Microsoft library at the following URL: |
Support of multiple domains |
Requires separate connections to different domain controllers to read changes made to the entries in different domains. |
Can obtain changes made to the multiple domains by connecting to the Global Catalog server. See Also: "Synchronizing with a Multiple-Domain Microsoft Active Directory Environment" |
Synchronization from a replicated directory when switching to a different Microsoft Active Directory domain controller |
Synchronization can continue. The synchronization key is the same when connecting to a replicated environment. |
Requires:
See Also: "Switching to a Different Microsoft Active Directory Domain Controller in the Same Domain" |
Synchronization scope |
Reads all changes in the directory, filters out changes to the required entries, and propagates to 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:
|
This section describes how Windows Native Authentication can be used with the Oracle Directory Integration Platform. It contains these topics:
Authenticating Users Against Multiple Microsoft Active Directory Domains
Overriding an Application Authentication Mechanism with 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, users log in to OracleAS Single Sign-On 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 10g (10.1.4.0.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. Authentication to an external directory is performed by using an external authentication plug-in. |
The following steps, shown in Figure 17-5, describe what happens when a user tries to access a single-sign-on-protected application:
The user logs in to a Kerberos realm, or domain, on a Windows computer.
The user attempts to access a single-sign-on partner application using Internet Explorer.
The application routes the user to the single sign-on server for authentication. As part of this routing, the following occurs:
The browser obtains a Kerberos session ticket from the Key Distribution Center (KDC).
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.
The application provides content to the user.
Figure 17-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.
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".
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 Application Server Single Sign-On Administrator's Guide.
Table 17-4 lists the schema elements in Oracle Internet Directory for users that are imported from Microsoft Active Directory.
Table 17-4 Oracle Internet Directory Schema Elements for Microsoft Active Directory
Schema Element | Description |
---|---|
|
Stores Microsoft Active Directory's |
|
Stores Microsoft Active Directory's |
|
Stores the value of Microsoft Active Directory's |
|
Stores the Kerberos user principal name for Microsoft Active Directory users. |
|
Contains Microsoft Active Directory group attributes, which are used to synchronize Microsoft Active Directory group objects with Oracle Internet Directory group objects in an Oracle Directory Integration environment. |
|
Contains Microsoft Active Directory user attributes, which are used to synchronize Microsoft Active Directory user objects with Oracle Internet Directory user objects in an Oracle Directory Integration and Provisioning environment. |
|
Represents the DN for the respective entry in Microsoft Active Directory. This value is required to perform external authentication if different domains are mapped between both directories. |
See Also: Oracle Identity Management User Reference for detailed information about the Oracle Internet Directory schema elements for Microsoft Active Directory |
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 17-6 shows how a forest in Microsoft Active Directory is reflected in Oracle Internet Directory.
Figure 17-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, then the Directory Integration Assistant (dipassistant
) 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.
This section describes considerations for synchronizing with a multiple-domain Microsoft Active Directory environment. It contains these topics:
Configuration Required for Importing from Microsoft Active Directory to Oracle Internet Directory
Configuration Required for Exporting from Oracle Internet Directory to Microsoft Active Directory
Example: Integration with Multiple Third-Party Directory Domains
Normally, importing requires configuring one import profile for each Microsoft Active Directory domain regardless of whether you are using the DirSynch 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 athttp://support.microsoft.com/ for information about Global Catalog attributes in the Microsoft Active Directory schema |
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.
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 17-7 shows how multiple domains in a third-party directory are mapped to a DIT in Oracle Internet Directory.
Figure 17-7 Example of a Mapping Between Oracle Internet Directory and Multiple Domains in Microsoft Active Directory
In Figure 17-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
.
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.
This section contains additional considerations for integrating Oracle Internet Directory with Sun Java System Directory. It contains these topics:
Synchronizing from Sun Java System Directory to Oracle Directory Integration Platform
Oracle Internet Directory Schema Elements for Sun Java System Directory
Sun Java System Directory maintains a change log in which it stores incremental changes made to directory objects. Synchronization from Sun Java System Directory to Oracle Internet Directory makes use of this change log.
See Also:
|
Oracle Internet Directory includes the orclSourceObjectDN
element for users that are imported from Sun Java System Directory. The the orclSourceObjectDN
element represents the DN for the respective entry in Sun Java System Directory. This value is required to perform external authentication if different domains are mapped between both directories.
This section contains additional considerations for integrating Oracle Internet Directory with Novell eDirectory or OpenLDAP. It contains these topics:
Synchronizing from Novell eDirectory or OpenLDAP to Oracle Internet Directory
Oracle Internet Directory Schema Elements for Novell eDirectory
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:
|
Table 17-5 lists the schema elements in Oracle Internet Directory for users that are imported from Novell eDirectory.
Table 17-5 Oracle Internet Directory Schema Elements for Novell eDirectory
Schema Element | Description |
---|---|
|
Represents the DN for the respective entry in Novell eDirectory. This value is required to perform external authentication if different domains are mapped between both directories. |
|
Represents the GUID value for the respective entry in Novell eDirectory. This value is used as the synchronization key. |
|
Represents the |
|
Represents the |
|
Represents the NDS object in Novell eDirectory. |
See Also: Oracle Identity Management User Reference for detailed information about the Oracle Internet Directory schema elements for Novell eDirectory |
Table 17-6 lists the schema elements in Oracle Internet Directory for users that are imported from OpenLDAP.
Table 17-6 Oracle Internet Directory Schema Elements for OpenLDAP
Schema Element | Description |
---|---|
|
Represents the DN for the respective entry in OpenLDAP. This value is required to perform external authentication if different domains are mapped between both directories. |
|
Represents the entryUUID value for the respective entry in OpenLDAP. This value is used as the synchronization key. |
|
Represents the |
|
Represents the |
|
Represents the OpenLDAP object. |
See Also: Oracle Identity Management User Reference for detailed information about the Oracle Internet Directory schema elements for OpenLDAP |
Oracle Internet Directory 10g (10.1.4.0.1) 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.
See Also: Theschemasync section in the Oracle Directory Integration Platform tools chapter of the Oracle Identity Management User Reference |