One of the tokens built into Novell Identity Manager, since at least 3.0x but maybe even earlier, is ParseDN. ParseDN is quite powerful and seems like it can do some magical things. You access it from Argument Builder and it can be used to take apart and reassemble a distinguished name.

This can be very helpful when you need for example to grab the middle part of distinguished name. For example, this could be when you have an Identity Vault at the center of your model, and connected as spokes you have a structure eDirectory tree and a structured Active Directory tree. You might want to mirror the structure between the trees, but since you are going through a flat eDirectory tree as the Identity Vault, the default rules for mirrored configuration will not help you.

Complicating things is the usual issue that although the structure in the two connected trees (eDirectory and Active Directory) are basically the same, the base DN, perhaps O=acme in eDirectory is not the same as perhaps dc=acme,dc=com in Active Directory. So really all you need to pass through to maintain the structure is the stuff in the middle.

One approach (no doubt there are better ones, but for the sake of the example this could be instructive) would be to store an attribute that holds the middle bits of the DN. Perhaps this could be a new attribute called acmeRelativeDN. At this point, let's pick some example names and objects so that we can visualize the problem.

In the structured eDirectory tree (for say File and Print, or perhaps LDAP authentication) you have a user
(In fully qualified LDAP DN format) CN=Bsmith,ou=Texas,OU=US,OU=Users,o=acme. In Identity Manager policies, this is actually used and stored as acme\Users\US\Texas\BSmith (sometimes you will see the tree name at the beginning, but you can usually ignore that).

In the structured Active Directory, you might have the same user with a different but similar DN. For example: CN=Bsmith,ou=Texas,OU=US,CN=Users,dc=acme,dc=com

We can see the parts we want, but how do we get them easily?

This is a problem I faced about a year ago, and I took the approach I am about to describe. I started by doing it differently:

- Storing the DN value in a string (which I guess is an implicit cast to type string)
- With a Replace all token, removing the acme\Users
- Using a regular expression to strip off from the last backslash at the end of the string.

That sort of worked, but it was much harder when working with the Active Directory DN, since it is in LDAP format, and not as simple to manipulate.

Using ParseDN

ParseDN is a better solution, since it has the ability to strip off nodes from the DN value.

The screen shot below shows the ParseDN token setup in Argument Builder, out of Designer for Identity Manager.



1. Link the ParseDN() token to some value, whether that is Destination DN or comes from a variable you defined elsewhere.

2. Tell ParseDN where to start chopping. The Start value means what node, where 0 is root most (closest to the top level container) and -1 is the leaf most value (usually the CN= part).

3. Tell it how much to chop. -1 is defined in the help in a way that still confuses me, and I have no simple way of explaining it. I work through it each time from the help, so I recomend the same to you.

In our example, I would say start at 0 and go for length 2, which would remove the root most two values, the acme\Users in our eDirectory example. Then I would try to take off the users object name from the list by running it again and saying start at -2, one back from the end and go the length of 1. This seems to be a limitation in my experience of ParseDN, in that once you take off something from the root most nodes, you cannot use it again on the DN.

So just reverse the order:

4. ParseDN off the leaf most node, with a start of -2 and a length of 1.

5. ParseDN it again, this time with a start of 0 and a length of 2.

That should leave you with an easy to handle string value of US\Texas which you can put into an attribute in the Identity Vault and use to place users in Active Directory.

Now for the second limitation of ParseDN. We have this acmeRelativeDN attribute in the ID Vault, and we have rules that a) watch for move events inbound from the structured eDirectory tree, and b) modify this attribute on a move.

How do we place in Active directory? Well ParseDN has a source and destination format pick list.



One of those options is LDAP. So that looks nice and easy - we just build up a string of com\acme\Users then append a text of \ then the value of attribute acmeRelativeDN then another \ and finally the naming attribute of the user in Active Directory. Then we call ParseDN with a source of slash, and a destination of LDAP - and all is well.

Alas, this is not to be. ParseDN cannot build an LDAP FQDN; instead, it will output "com,acme,users,us,texas.Bob Smith" as the result. Basically, all it can do is replace the separators with commas.

The reason makes sense when you think about it. How would ParseDN determine what the class of the target container is? For exampl, how would you know if it was a CN=, an OU=, a DC= or whatever? Well, I suppose it could use some pretty sophisticated querying to the destination data source and try and figure it out. Someone has suggested this as an enhancement request, but this feature does not yet exist.

In our example, the best way is to customize the string for our environment and rebuild the string by hand. We know that the end of the string will be cn=Users,dc=acme,dc=com and that we will be only two layers deep. Then we would somehow split up the value of the acmeRelativeDN and write it out as ou=Texas,ou=US. Then at the very beginning we would stick in the cn=Bob Smith.

It is important to know what the token can and cannot do. Otherwise, you could end up churning your wheels in the mud for a while until you realize it is never going to do what you want, and you'd have to move on to a different approach.