The Lotus Notes driver for Identity Manager is a tricky driver, and Groups in Lotus Notes are more complex than in eDirectory. (This article refers to IDM 3.01, with the 2.23 or 2.25 Notes driver.)
The Members list in Notes can contain string values. Often this is seen as members in a Mail list (GroupType=1), who are e-mail addresses and not in the Lotus Notes system – much like in a distribution list. If you want to synchronize this to eDirectory, you are going to have a problem on the Publisher channel.
The schema mapping rule maps Notes’ Members to eDirectory’s Member attributes. eDirectory Member has a Syntax requirement of DN (Distinguished Name). DN’s are basically stored as an eDirectory object ID, and every time a tool or protocol displays the DN value, it translates from the object ID to the name of the object. Thus if you move the object, it’s no big deal. The name change (in the full name including the context) automatically happens, because the Object ID stays the same, and all the tools and interfaces translate to the names we are used to seeing. (This may be an over-simplification, but it helps explain the issue).
So how would you store a non-DN value in a DN syntax field? The answer is that you cannot, without a different strategy. An e-mail address in a field that everything expects to have an object ID stored would make no sense and probably crash all sorts of things …
One way to handle it, for Group creates or imports, is to get the values of the members list from Notes, before the Schema mapping rule runs. This is pretty much in the Publisher Input Transform rule timeframe.
However, there is one further complication. The object does not exist at this point in the destination directory (eDirectory in this case), because it’s too early in the rules. Thus if you try to write to the destination object DN, it won’t work. The values will get rejected by the driver, as they should.
If you try to read from Notes after the Schema mapping rule runs, it will reject all non-DN syntax rules automatically (as designed!), or else you could cause all sorts of damage to the directory with bad syntax.
In IDM 3.01 local variables can be a nodeset, which is what you want to use to handle the set of values for Members. Alas, in 3.01 the variable is only around for the duration of the rule. In IDM 3.5 (in closed beta, but the docs are somewhat published) there is a scope called “driver,” which would simplify this greatly. You would assign the nodeset of members to the local variable, scoped to the driver, and then later on add them to a second attribute (syntax of Case Ignore String) so you could write them out.
Because the local variable will not last, here’s the method I use:
1. Designate a group object as a placeholder. (Personally, I use a GCV that defines what object it is using, so all my rules reference the GCV instead of the absolute object DN).
2. In the Input Transform rule, get the Members list (which works fine) and write it out to the placeholder object elsewhere in your tree.
3. When you are ready (I chose the Command Transform ruleset), read it back and write the values to the attributes of the object you are working on. By this time, the destination object should exist so you can write to the destination DN.
4. If you need to expose the values in LDAP, you can use the Attribute mapping to change Group’s Member attrib to appear to be your string value with all the Members in it.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.