Write for OTN
Earn money and promote your technical skills by writing a technical article for Oracle Technology Network.
Learn more
Stay Connected
OTN Architect Community
OTN ArchBeat Blog Facebook Twitter YouTube Podcast Icon

Enterprise Grade Deployment Considerations for Oracle Identity Manager AD Connector

by Firdaus Fraz

Best practices for setting up an enterprise deployment environment for the Oracle Identity Manger Active Directory connector

October 2013

Downloads
download-icon13-1Oracle 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.

AD Deployment Topology
 

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.

OIM-AD Integration
 

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:

  • Microsoft's .NET software framework runs on Microsoft Windows. It includes a class library, which provides common functionality to applications running in the .NET framework, and a Common Language Runtime (CLR) where the programs developed for .NET framework are executed.
  • The Common Object Model (COM) architecture builds extensible, component-based software.
  • ADSI (Active Directory Service Interface) is a built-in component of Microsoft Windows. Because ADSI exposes the objects stored in the directory as COM objects, the objects can be accessed, manipulated by using the methods available on one or more COM interfaces.
  • ADSI is shipped with various providers to access various types of directories. One them, the Lightweight Directory Access Protocol (LDAP) provider, can be used for accessing any directory that supports LDAP v3.

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.

OIM AD Connector Bundle
 

Connector Instance Pooling and Failover (of Connectivity to AD Domain Controller)
 

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:

  • For every operation request from OIM on an AD object within an AD domain, one Connector Instance will be picked from the connector pool. The "CheckAlive" method is invoked to verify the validity of the target system connection before the connector operation is invoked. Once the operation is complete, the Connector Instance is returned to the pool.
  • When the connection pool is exhausted, new Connector Instances will be created, following the same logic of connecting to the primary Domain Controller (DC) and then to secondary DCs if connection to the primary fails.

AD Connection Failover Mechanisms
 

Configuring Secondary DC Hostnames:

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).

Configuring AD Serverless Bind:

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.

Hardening
 

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

 

Performance
 

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:

  • If you are using a 9x version of connector, consider moving to the 11g version. The ICF-based AD connector has improved performance.
  • Make sure that you have only the necessary attributes defined in reconciliation and provisioning configurations for the AD connector in OIM, and no extra attributes.
  • Use OIM reconciliation batching.

Load Balancing & Failover [OIM —> Connector Server]
 

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.

An Enterprise Grade AD Deployment
 

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.

fraz-oim-ad-fig01.png
Figure 1: AD forest with single domain tree

Figure 2 depicts a peer domain topology:

fraz-oim-ad-fig02.png
Figure 2: AD forest with peer domains

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:

  • Set SearchChildDomain to value "yes" in the AD configuration lookup definition Lookup.Configuration.ActiveDirectory.
  • Provide the global catalog server host name as the value of SyncGlobalCatalog IT resource parameter.

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.

fraz-oim-ad-fig03.png
Figure 3: Production deployment of 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:

  1. From OIM to the load balancer
  2. Load balancer to connector server
  3. Connector server to AD connector bundle (deployed in the connector server; there can be multiple versions of connector bundles deployed in the same connector server)
  4. AD connector bundle to AD objects

OIM AD connector could be configured to perform reconciliation against the global catalog server or from the specific domain.

Single Application Instance Model for peer domain topology
 

In some business cases, a single Application Instance model could be preferred. If so, consider the approach below:

  • Have OIM connect to one of the AD peer domains. The AD administrator user must be set up with appropriate privileges to be able to perform user creation/modification in other peer domains in the AD forest.
  • Reconciliation will be a little tricky, as the IT Resource has connectivity details for a single domain (which is NOT the parent domain).
  • While there is no straightforward configuration to achieve reconciliation from all domains with a single Application Instance model, it can be achieved with some additional configurations:
    • Each of the peer domains could have new schedule tasks having the logic of updating the IT Resource parameters (the domain details, and primary/secondary DC host details) to point to the appropriate domain, and then triggering the out-of-the-box OIM AD connector schedule task.

(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.)

About the Author

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.
Blog LinkedIn