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.
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.
Support
Documentation
Learning Services
Partner Programs