Programmatically Placing Users in a Hierarchical Structure * Update
Novell Cool Solutions: Feature
By William C Schneider
Digg This -
Posted: 6 Apr 2004
You want to place users in a hierarchical structure based on a multi-valued attribute. How do you determine where they should be placed? How do you handle people that belong in two locations but only create one account and still enable shared administration?
- Write business rules that determine the placement for frequently occurring multiple affiliations.
- Apply a rule to catch unresolved multiple affiliations.
- Place the single affiliated users in the proper location.
For purposes of this example we will assume the following:
- The source directory is a flat structured eDirectory or 'Identity Vault.'
- The destination directory is a hierarchical Active Directory.
- We are using the multi-valued attribute of 'OU' of the eDirectory user class.
The 'OU' attribute of the user must be on the filter for the user object class. We can synchronize the attribute to Active Directory or simply use the notify option.
Suppose we have three users with the following subset of attributes (not all attributes listed here):
User 1 - An accountant, with no other responsibilities.
dn: cn=hford,ou=People,o=DigitalAirlines ou: Accounting
User 2 - An engineer who also sits on the executive board of the corporation.
ou: Executive Board
User 3 - A Peoplesoft Project Manager who is also a VP in Human Resources and is on several finance committees.
ou: Human Resources
ou: Information Technology
We will first discuss the placement rules and then address some steps that may aid in debugging the process. The first placement rules to define are the frequently occurring dual affiliation rules for which we can determine a destination.
Placement: Multiple Affiliation Executive Board and Engineering
Conditions if class name equal "User" And if source attribute 'OU' equal "Engineering" Or if source attribute 'OU' equal "Engnr" And if source attribute 'OU' equal "Executive Board" Or if source attribute 'OU' equal "ExecBrd" Actions set operation destination DN(dn("CN=" + Source Name() + ",ou=ENG-EXEC,ou=SHARED," + "ou=accounts,dc=digital,dc=com"))
The above example also illustrates how to test for different versions of the same business affiliation. This sometimes occurs when combining data feeds from two separate systems. A good example would be a merger of two companies that referred to Engineering different in each of their Peoplesoft implementations.
The next step is to define a 'catch-all' for the multiple affiliated users for whom we do not have business rules to define. We do this by looking at the number of values that are present in the 'OU' attribute with an XPATH statement. This rule would apply to the jseinfeld user in our example.
Placement: Multiple Affiliation Unknown Placement
Conditions if XPATH expression true "count(*[@attr-name = 'OU']//value) > 1" And if class name equal "User" And if operation equal "add" Or if operation equal "modify" Actions set operation destination DN(dn("CN=" + Source Name() + ",ou=UNKNOWN," + "ou=accounts,dc=digital,dc=com"))
Finally, we define all of the single affiliation rules.
Placement: Accounting Conditions if source attribute 'OU' equal "Accounting" And if class name equal "User" Actions set operation destination DN(dn("CN=" + Source Name() + ",ou=ACCT," + "ou=accounts,dc=digital,dc=com")) Placement: Engineering Conditions if source attribute 'OU' equal "Engineering" And if class name equal "User" Actions set operation destination DN(dn("CN=" + Source Name() + ",ou=ENG," + "ou=accounts,dc=digital,dc=com"))The order of the rules becomes very important.
- Make sure the definable multiple affiliation rules are processed first, placing as many of the corresponding users as possible.
- Remove all of the dual affiliated users that could not be placed and place them in unknown.
- Place the single affiliated users.
Be sure to place a Break() after each rule as the final action. This will allow only the first rule to be applied that fits. If you do not have a break after each action set, the dual affiliated users will have the last single affiliation rule applied instead.
In debugging this process, we also found the following code useful. We set the department attribute in the Active Directory to the count of the number of values in the OU attribute in the eDirectory. We have not yet found a good business use for this data, but the code may prove to be handy for other operations in addition to debugging this process. To populate this value, we placed the following in the Output Transform:
Output: OU Value Count Conditions if operation equal "add" Or if operation equal "modify" Actions set local variable("myouset",nodeset(Source Attribute("OU",class name="User"))) set destination attribute value("department",class name="user",XPATH("count($myouset)"))
In the Output Transform, the eDirectory attributes are no longer available for the previous XPATH expression in the placement rule. Instead we load the OU attribute into a local variable and then count the values on that variable. We arbitrarily chose department, as it was readily available in the Active Directory GUI for viewing during the debugging process.
If you have questions for Will about this solution, you can contact him at william.c.schneiderTAKETHISOUT@uth.tmc.edu
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com