Synchronizing Objects into the Right Containers
Novell Cool Solutions: Feature
By William C Schneider
Digg This -
Posted: 17 May 2006
Here's the scenario: You have a hierarchical eDirectory and a hierarchical Active Directory (or other LDAP directory) and they are not a mirror of each other. However, there is a cooresponding container in each of the directories. You want to synchronize objects between these two directories and have new objects land in the appropriate container. You could synchronize the OU objects, but if they are named differently it could become very difficult to associate them between the two systems.
This solution will "associate" the OUs so that users are consistent. It also enables you to consolidate from a distributed eDirectory to a flatter structured Active Directory.
For purposes of this solution we want to 'associate' the eDirectory container:
with the Active Directory container:
Users who are created in eDirectory should also be created in this AD destination container.
(Note that I use the word "associate" in a different way from an Identity Manager Association when referring to the containers.)
One option is to write a rule for each container. However, if you have a large number of containers this does not scale very well. Instead, let's take advantage of the existing structure.
In eDirectory, on the OU object for our container mentioned above, we populated the Location attribute (LDAP attribute: L) with:
You'll note that this is the destination OU DN, minus the domain portion. (I'll explain why later.)
The use of the location attribute is arbitrary - you can use any string attribute you would like, or create your own custom attribute to contain this information. We were not using the location attribute, so this made sense for us. You can associate multiple eDirectory containers to the same Active Directory container simply by specifying the same value for the Location attribute. This allows you to move to a flatter AD structure as well.
Next, add the following rule as your subscriber placement policy:
<?xml version="1.0" encoding="UTF-8"?><policy> <rule> <description>Parse User Source DN for Placement</description> <comment name="author" xml:space="preserve">W.Schneider</comment> <comment name="version" xml:space="preserve">1.0</comment> <comment name="lastchanged" xml:space="preserve">5-9-2006</comment> <conditions> <and> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-set-op-dest-dn> <arg-dn> <token-text xml:space="preserve">CN=</token-text> <token-src-name/> <token-text xml:space="preserve">,</token-text> <token-src-attr class-name="Organizational Unit" name="L"> <arg-dn> <token-src-dn length="-2"/> </arg-dn> </token-src-attr> <token-text xml:space="preserve">,dc=yourdomain,dc=edu </token-text> </arg-dn> </do-set-op-dest-dn> </actions> </rule> </policy>
Let's look at the policy in this graphical view and see what it is doing.
Figure 1 - Subscriber placement policy
You can add any additional criteria here, but for this example we are testing to make sure this is a user object. Because this is in the placement policy, the fact that the operation is an add operation is implicit.
We choose the "Set operation destination DN" and we define that DN using the expression builder:
Figure 2 - Destination dn
This is constructed so as to reduce the input time for the user. We start by adding the text "CN=" followed by the Source Name() noun, which is usually equal to either CN or UID. This is then followed by a comma to produce:
Now for the magic part! Let's look carefully at the next token "Source Attribute." In this token we query for the location attribute (L) of the Organizational Unit object class. We select DN for the object, which allows us to specify the user's container. Let's look at this next token in more detail:
Figure 3 - Source dn
We use the Source DN token and set the start to 0, the root most segment, and the length to -2. This trims the user's name from the DN so we are left with the user's container. The user's container will be queried by the prior token for the location attribute.
The constructed DN thus far is now:
We finish by appending another comma, followed by the remainder of the domain, to complete the destination DN:
I mentioned we would explain this later. Instead of using a text token, you could instead specify a global variable that contains your domain name. In doing this, when you move between production and development you can change this one setting to update the driver.
Below is a trace that shows this process taking place in the placement policy: