by Firdaus Fraz
Best practices for setting up an enterprise deployment environment for the Oracle Identity Manger Active Directory connector
Oracle Identity Manager
Many Oracle Identity Manager (OIM) customers deploy the Active Directory (AD) connector, and may face functionality and performance issues in the production environment. This article provides best practice recommendations for setting up an enterprise deployment environment for the OIM AD connector.
This article assumes a basic understanding of AD deployment topology, including such concepts as domain, tree, forest, etc., explained in detail here: http://technet.microsoft.com/en-us/library/bb727030.aspx.
An enterprise might have a single forest, and one or more domains within the forest. The domains in the forest could be organized as a hierarchical structure, and be part of a tree. They could also be set up as peer domains, with one domain as the root domain. In more complex scenarios, depending on requirements, there could be multiple domain trees in the same forest.
All domains in a forest are connected by a two-way, transitive trust. If there are multiple trees in the forest, they are all connected via a forest root domain and share a trust relationship.
Some organizations choose to have more than one forest, depending on resource access requirements or a requirement for the separate management of schema by different divisions within the organization.
This article considers AD topology with a single forest, within which is a single tree and peer domain topology.
It is also important to understand the architecture and integration technology used by OIM to integrate with AD for user account creation, group assignments and all other types of operations supported by the OIM AD connector.
For the details of connector architecture, refer to the OIM AD connector guide: http://docs.oracle.com/cd/E22999_01/doc.111/e20347/intro.htm#CEGFFIJH
Awareness of the following technology concepts will help you better understand the connector architecture:
The OIM Active Directory connector bundle is built using ADSI APIs and uses the ADSI LDAP provider to access and perform operations on AD objects. Since the OIM AD connector is based on ADSI and .NET, it needs to run on the Microsoft .NET framework environment. Because the Microsoft .NET framework requires code to be run as an application, the OIM AD connector is by default shipped with an OOTB .NET connector server, a.NET framework application. The OIM AD connector bundle is deployed on the .NET connector server. The .NET connector server must be installed on a Windows machine, which can be any machine in one of the domains in the organization AD forest.
OIM talks to the .NET connector server over the network. The .NET connector server works as a proxy to provide any authenticated application access to the current version of the connector deployed within the .NET connector server.
The connector bundle uses ADSI to access Microsoft AD objects and to perform read/write operations on AD.
Via this architecture, OIM provides ability for remote execution of a connector.
The new OIM connectors use the Identity Connector Framework (ICF) for connector development. ICF decouples any dependency of OIM with the target application it is connecting to. The connector bundle contains the target system operations specific logic. All the OIM dependant code/ICF framework code is part of the ICF Integration Layer, which is part of OIM.
The ICF Integration Layer provides connection pooling functionality. OIM out-of-the-box and custom connectors can make use of this feature by implementing the interface PoolableConnector during connector development.
If the connector has been developed implementing the interface Connector instead of PoolableConnector, then for each provisioning/reconciliation operation, the ICF Integration Layer creates a new Connector Instance, creates a new connection with the target and completes the operation, then removes the connection with the target system and disposes the Connector Instance.
The latest AD connector implements the PoolableConnector ICF Service Provider Interface.
The ICF Integration Layer maintains the Connector Instance pool for each of the domains (AD domains managed by OIM in a deployment, assuming that there is separate OIM connector configuration for each domain). Basically, the Connector Instance pool is per Connector Configuration (IT Resource, connector configuration lookup) for each connector deployed in OIM. For example, if OIM is managing an AD forest with 5 domains, and we are managing the 5 AD domains using 5 Application Instances in OIM, then we would have a separate IT resource in OIM for connectivity information to each of the domains. In this case, since we have different IT resources for each domain, one connector pool is created for each IT resource (i.e., each AD domain).
When the first connector operation is invoked, the initial connector instance pool is created.
The PoolableConnector (and Connector) interface has init, dispose, and checkAlive methods that create, dispose, and verify the validity of the target system connection. The init method would be invoked when the Connector Instance is created, and would have the target system connectivity implementation. The "dispose" method would be invoked at the time of disposal of the Connector Instance. The AD connectivity failover can be achieved either by configuring secondary (backup) domain controller hostnames or by using AD serverless bind. As explained below, the configuration can be achieved through OIM IT resource for the AD Application Instance:
You can configure backup DC hostnames (multiple hostnames can be provided in a semicolon-separated list) in the OIM "IT Resource" form (parameter name is BDCHostNames) for the AD application instance.
By default, connection to the primary DC would be established (IT Resource parameter name LDAPHostname). If connection to the primary DC fails, a connection will be created to a secondary (backup) DC; this happens in the order in which the secondary DC list has been provided in IT Resource as semicolon-separated values, until a successful connection is established).
In the OIM IT Resource for the AD application instance, if one does not specify either the hostname on an AD installation Windows machine (IT Resource parameter name LDAPHostname) or the backup DC hostnames (IT Resource parameter name BDCHostNames), the AD connector uses serverless binding with AD. Serverless binding to AD is achieved through the ADSI code, which tries to connect to the AD domain without targeting the connection to any specific DC. This way, the connection is automatically established with any available DC in the domain.
For configuring serverless binding during reconciliation from AD, do NOT configure the following IT Resource parameters: SyncDomainController and SyncGlobalCatalog.
SyncDomainController: Used if reconciliation is to be performed against a specific domain controller.
SyncGlobalCatalog: Used if reconciliation is to be performed against a Global Catalog Server.
Note: The latest available OIM AD connector (as of Aug 2013) has been referred to for the configuration parameter names.
By using the internal mechanism of ADSI and the .NET Framework, the default communication between the .NET Connector Server and Microsoft AD is "secure." However, if you are using Microsoft AD LDS as the target system, you must configure SSL between OIM and the target system.
Please refer to the connector guide for steps to configure SSL between OIM and the connector server, and SSL between the connector server and Microsoft AD LDS: http://docs.oracle.com/cd/E22999_01/doc.111/e20347/deploy.htm#autoId28
Please refer to the OIM Performance Tuning Guide for OIM (Performance Tuning Guidelines and Diagnostics Collection for Oracle Identity Manager (OIM) (Doc ID 1539554.1)), and the Connector Performance Tuning Guidelines available on the Oracle Support portal.
You must also consider the following:
As discussed above, the connector servers can be on any Windows machine in any of the AD domains in the forest that we are managing through OIM. A single connector server can serve the entire AD forest.
Two or more connector servers behind a load balancer can achieve load balancing and failover. Load balancing could be achieved using a round-robin algorithm or any other algorithm supported by the load balancer.
Now we shall discuss the OIM AD integration for AD domain topologies-with a single domain tree as well as with peer domain. Figure 1 shows an AD forest with a single domain tree. The domains here have a parent-child relationship.
Figure 2 depicts a peer domain topology:
For the domain tree topology, a single Application Instance configuration in OIM could manage all the domains in the tree. Provisioning to all child domains could be done by connecting to the parent domain.
The OIM AD connector must be configured to perform reconciliation against the global catalog server:
With the configuration above, OIM will reconcile AD forest data from the global catalog. The benefit of using the global catalog server is that the "USNChanged" attribute in each DC is specific to that DC; thus, by connecting to the global catalog, OIM can get the latest changes irrespective of the DC that contains the latest change for any attribute. OIM will connect to the global catalog for reconciling the latest changes in attributes, and through the global catalog it will read the relevant data from individual DCs.
For the peer domain topology, we could have a separate AI configuration for each of the domains. The architecture diagram below shows a sample architecture of production deployment of an OIM AD connector.
In the architecture above, a centralized connector server serves all the domains in the AD forest. Two or more connector servers can be used behind a load balancer to provide load balancing and failover of the connector server component. As discussed earlier, the connector server is the .NET application where the OIM AD connector bundle has been deployed. The technical and functional flow of this architecture is described below:
In OIM we will have connectivity details for each domain captured in a separate IT Resource (one for each domain). The IT Resource for a domain will also have secondary DC host names defined (comma-separated), to provide failover. If connection cannot be established to a domain's primary DC, the connector server will automatically take care of connecting to secondary DCs, if the configuration has been done in IT Resource for the same.
Apart from IT Resources for each domain, OIM will have one IT Resource for connecting to the load balancer. The load balancer will take care of routing the request to one of the connector servers behind it in a round-robin fashion (or any other algorithm supported by the load balancer).
For provisioning into AD from OIM, the communication flow will be:
OIM AD connector could be configured to perform reconciliation against the global catalog server or from the specific domain.
In some business cases, a single Application Instance model could be preferred. If so, consider the approach below:
(Note: The exact approach would depend on the business use-case, and may or may not be achievable. The approach detailed above is intended only to give an idea of possible options. Details to follow further testing.)
Firdaus Fraz is Principal Solutions Architect with the Oracle Fusion Middleware Identity Management A-Team. In this role she works with IDM customers and partners world wide to provide guidance on implementation best practices, architecture, use-case design, and troubleshooting.