Multiple OUs Scoping for Identity Manager Drivers

mbluteau

By: mbluteau

February 22, 2006 8:01 am

Reads:303

Comments:0

Score:Unrated

Introduction

This AppNote describes one way to address a very common challenge that Identity Manager experts encounter in real-life customer environments:

*The need to work with multiple Organizational Units in directories such as Novell eDirectory, Microsoft Active Directory, Oracle Internet Directory, or any other LDAP-like directory.

Very often, the OUs to be included in the scope of the driver for matching rules, placement rules, etc, are numerous, and they do not branch off one parent OU. This is very common in Active Directory, where typically many OUs branch off directly under the domain (e.g. ou=ou1,dc=domain,dc=com, ou=ou2,dc=domain,dc=com). Also, including the whole tree in the scope of the driver is usually ineffective, since some OUs may need to be excluded (for example, those who include applicative accounts or groups, or administrative accounts).

One way to setup the scope for a driver to include multiple OUs is simply to sequentially list them in the matching rule, placement rule, etc. While this is easy and straightforward, this is rather ineffective when the number of OUs is large, or when new OUs need to be added or removed for the scope of the driver. It is very likely that updating the list of OUs in multiple places in the driver may result in typos, or simply that one will forget to update all the different places that need to be updated.

An Automated Solution

After thinking about a better, more automated approach, and testing out a few ideas, I came up with an approach that is rather simple and effective. It’s flexible enough to be shared among different drivers in one or more eDirectory tree(s).

But first, allow me to introduce you to a simple driver I am using to test such ideas and the related logic. It’s a loopback driver I call the “sandbox driver.” Here is the Identity Manager driver export in XML, for your convenience.

One of the advantages of using a loopback driver is that no connected system is required, and logic developed in Policy Builder or even XSLT can be tested quickly.

Figure 1: iManager 2.5 view of a simple loopback driver

In the loopback driver we leverage in this article, everything happens on the Subscriber Channel, in the Event Transformation Policies. Whatever actions are triggered following some events in eDirectory must write back to the Source, which is eDirectory itself. We can think about this driver as if it were an agent monitoring eDirectory and updating it whenever some conditions are encountered. This is a very versatile driver that I leverage in most projects I am involved with.

The main idea we will leverage to manage a scope including multiple Organizational Units is to use a special object class called managedOUs. Several drivers can point to the same instance of this object class (same object), or each driver can have its own. These objects can be synchronized between eDirectory trees (e.g., Workforce tree versus Corporate tree, etc.).

Figure 2: managedOUs object class, which contains CN and managedOUs

The managedOUs effective object class is derived from Top. It can be contained by domain, Organization, and Organizational Unit, and it has CN for mandatory/naming attribute and managedOUs for optional attribute. managedOUs is a multi-valued, case- sensitive string attribute that contains the list of OUs that are part of the scope.

Figure 3: The managedOUs Case Exact String, multi-valued attribute, that contains the list of OUs that are part of the scope

Figure 4: Custom plug-in created with Plug-in Studio for creating managedOUs objects

Figure 5: Custom plug-in created with Plug-in Studio for managing managedOUs objects

Figure 6: Using the Plug-in Studio plug-in to add or remove Organizational Units for the scope

Now we need to create some logic in the loopback driver to monitor user objects and verify that they belong to an Organizational Unit that is part of the scope. We could modify the logic to work also for Groups or other objects, or we could leverage the logic in matching rules or placement rules, etc. The example I provide is simple but contains the essential items. I trigger the action, which is a modify for the Description attribute when Title is modified (the condition for triggering the action) for a user inside the scope.

Figure 7: Filter for the loopback driver

Note that the GUID is mandatory in order to manage a class like User, and we want the driver to be notified whenever the Title attribute is modified.

The first Policy will detect that Title is being modified and use the value of Title for the OU. We will copy the value for Title in a variable called fictitiousOU, and then retrieve the list of managed OUs for the driver from the object ca\novl\managedOUList1. Then we will copy it into a nodeset (multi-valued) variable called ManagedOUs.

Figure 8: ManagedOUs

Alternatively, we could retrieve the real OU that is a parent of the User object through the Argument Builder, leveraging Source DN.

Figure 9: Retrieving the real OU

Then we use XPATH to test if the fictitious or real OU is in the scope for the driver. If the OU is part of the list (multi-valued variable ManagedOUs), then we set the value of a local variable called OUinScope to Yes.

Figure 10: Testing the scope for the driver with XPATH

The advantage of using a local variable like OUinScope, versus testing for the condition and performing the action in one step, is that many actions can re-use the variable.

Next, we perform different actions depending if the OU is within or outside the scope. We set Description to a different value for each condition.

Figure 11: Setting Description values

Then we can use iManager or other tools like LDAP Browser/Editor (see http://www-unix.mcs.anl.gov/~gawor/ldap/download.html) in order to test the logic.

Figure 12: LBE view for an OU that is included in the Scope

Figure 13: LBE view for an OU that is NOT included in the Scope

The key idea here is to leverage the capability of Identity Manager to copy multi-valued attribute values into a nodeset local variable, and then to perform an XPATH comparison to check if a given value is part of the list of values. Leveraging local variables and XPATH allows for flexible logic – it improves driver logic and reduces the maintenance in dynamic production environments.

I hope that this article will be helpful to you. Please, do not hesitate to send feedback or questions my way.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading ... Loading ...

Tags: ,
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Comment