|
Oracle® Identity Management Integration Guide
10g Release 2 (10.1.2) B14085-02 |
|
 Previous |
 Next |
|
Oracle® Identity Management Integration Guide
10g Release 2 (10.1.2) B14085-02 |
|
|
Previous |
Next |
Oracle provides centralized security administration for all Oracle components by integrating them with Oracle Identity Management. Similarly, Microsoft provides centralized security administration in Microsoft Windows by integrating all Microsoft applications with Microsoft Active Directory.
If your environment uses both Oracle Identity Management and Microsoft Active Directory, then, to synchronize data in one with data in the other, you need to integrate the two systems. You do this by using Active Directory Connector.
This section discusses the Oracle components and architecture involved in integrating Oracle Identity Management with Active Directory. It contains these topics:
How Oracle Directory Integration and Provisioning Maintains Synchronization
Oracle Internet Directory Schema Elements for Integration with Microsoft Active Directory
Directory Information Tree in an Integration with Microsoft Active Directory
This section describes the following components that are used to integrate with Microsoft Active Directory:
|
See Also: Chapter 3, "Oracle Directory Integration and Provisioning Administration Tools" for a description of the tools used to integrate Oracle Internet Directory with Microsoft Active 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:
|
Oracle Directory Integration and Provisioning
Oracle Directory Integration and Provisioning 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 and Provisioning enables:
Synchronization between Oracle Internet Directory and other directories and user repositories
Automatic provisioning services for Oracle components
Oracle Directory Integration and Provisioning includes connectors to synchronize Oracle Internet Directory with other LDAP directories or data stores. One of its connectors, Active Directory Connector, is designed to synchronize Oracle Internet Directory with Microsoft Active Directory.
Active Directory Connector enables you to:
Configure either one-way or two-way synchronization with Microsoft Active 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
Synchronize with multiple Microsoft Active Directory domains. You can synchronize changes with an individual domain or an entire Active Directory environment by using the Microsoft Global Catalog.
|
See Also:
|
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:
|
Active Directory External Authentication Plug-in
This plug-in, which is part of the Oracle directory server, enables Microsoft Windows users to log in to the Oracle environment by using their Microsoft Windows credentials. When this plug-in is in place, it is invoked by the Oracle directory server. This plug-in verifies the user's credentials in Microsoft Active Directory. If the verification is successful, then the Oracle directory server notifies OracleAS Single Sign-On.
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.
Although the SPNEGO protocol supports both Kerberos version 5 and NT Lan Manager (NTLM) authentication schemes, Oracle Application Server 10g Release 2 (10.1.2) 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, then Oracle Identity Management authenticates the user by using OracleAS Single Sign-On. Authentication to Active Directory is performed by using the Active Directory external authentication plug-in. |
The following steps, shown in Figure 18-1, 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 18-1 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 keep Oracle Internet Directory and Microsoft Active Directory synchronized, Oracle Directory Integration and Provisioning brings in incremental changes made available by Microsoft Active Directory change tracking mechanisms. Oracle Directory Integration and Provisioning supports two of these 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 Active Directory Connector.
Each approach has advantages and disadvantages. Table 18-1 compares the two approaches.
Table 18-1 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:
|
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: "Considerations for 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:
|
To identify objects that are synchronized with those in Microsoft Active Directory, Oracle Internet Directory contains schema elements that correspond to Active Directory-specific attributes. These schema elements are described in the Oracle Identity Management User Reference.
This section contains the following topics:
Example: Integration with a Single Microsoft Active Directory Domain Controller
Example: Integration with Multiple Microsoft Active Directory Domain Controllers
|
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 18-2 illustrates the default identity management realm.
As Figure 18-2 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 and Provisioning 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 and provisioning server 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 18-3 shows an example of one-to-one mapping between the two directories.
Figure 18-3 Default DIT Structures in Oracle Internet Directory and Active Directory When Both Directory Hosts Are Under the Domain us.MyCompany.com
In the one-to-one mapping illustrated in Figure 18-3:
Both Active Directory and Oracle Internet Directory hosts have the same topology.
Users are synchronized only from Active Directory to Oracle Internet Directory. All users to be synchronized are stored in one container in Active Directory, in this case users.us.MyCompany.com.
The same DIT structure is maintained in both Active 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 Active Directory to Oracle Internet Directory using one-to-one domain mappings.
|
Note: In the example 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 Microsoft Active Directory.In addition, although the synchronization in the example is one-way, from Microsoft Active Directory to Oracle Internet Directory, the synchronization can, alternatively, be bi-directional. |
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.
One-to-One Mapping of Multiple Microsoft Active Directory Domains
Figure 18-4 shows how multiple domains in Microsoft Active Directory are mapped to a DIT in Oracle Internet Directory.
Figure 18-4 Example of a Mapping Between Oracle Internet Directory and Multiple Domains in Microsoft Active Directory
In Figure 18-4, the Microsoft Active Directory environment has a parent and two children. Each domain has a domain controller associated with it. The Active Directory domain controller supporting the node us.mycompany.com is the Global Catalog server.
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 Active Directory environment us.MyCompany.com maps to the default identity management realm in Oracle Internet Directory, in this case dc=us,MyCompany,dc=com.
Mapping of a Microsoft Active Directory Forest
Figure 18-5 shows how a forest in Microsoft Active Directory is reflected in Oracle Internet Directory.
Figure 18-5 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.
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 Active Directory, users in one domain are authenticated by a domain controller in another domain. The trust relationship can be transitive or nontransitive.
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 nontransitive 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 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 nontransitive trust between two domains in a Microsoft Active Directory environment.
In a nontransitive 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.
