Novell Home

Programmatically Placing Users in a Hierarchical Structure * Update

Novell Cool Solutions: Feature
By William C Schneider

Digg This - Slashdot This

Posted: 6 Apr 2004
 

Problem:

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?

Solution:

  1. Write business rules that determine the placement for frequently occurring multiple affiliations.
  2. Apply a rule to catch unresolved multiple affiliations.
  3. Place the single affiliated users in the proper location.
To enable shared administration of accounts, users with multiple affiliations will be placed into an ou=SHARED in the Active Directory. If we are unable to determine further placement rules under SHARED, we will place them into ou=UNKNOWN, and the administrators will manually determine placement. It would be difficult to write business rules for all possible combinations, but wherever there are similar affiliations there will be an ou=<SHAREDAFFILIATION>,ou=SHARED.

Example:

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.
dn: cn=rwilliams,ou=People,o=DigitalAirlines
ou: Engineering
ou: Executive Board

User 3 - A Peoplesoft Project Manager who is also a VP in Human Resources and is on several finance committees.
dn: cn=jseinfeld,ou=People,o=DigitalAirlines
ou: Human Resources
ou: Finance
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.
  1. Make sure the definable multiple affiliation rules are processed first, placing as many of the corresponding users as possible.
  2. Remove all of the dual affiliated users that could not be placed and place them in unknown.
  3. 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

© 2014 Novell