Mapping CN to Full Name with the Notes Driver



The default rule included with the Notes driver (as of version 2.25 of the driver at least), maps eDirectory CN to Notes Full Name.

The problem is that Notes uses Full Name as a multi-valued attribute that includes many useful - and somewhat annoying - attributes, including every rename that has happened on the user. As an example, for Bob Smith, the Notes Full Name might contain:

Bob Smith
Bob J Smith

You probably do not want all this synced to eDirectory in the CN attribute, since eDirectory uses CN as a naming attribute. Cluttered naming attributes are not great things to have in your tree.

Also, you may prefer to map eDirectory UniqueID to the Notes Shortname attribute. Using UniqueID as the naming attribute would be helpful.


I happen to not like this default rule in the shipping driver. I had a chance at Brainshare to ask the developer why it is done this way, and found out that there really is no good default rule. They had to pick something to ship, so this default at least makes some sense as
it stands. The developer mentioned an offer that if anyone has a significantly better idea, post it to the support forum for IDM drivers and he is up for looking into incorporating it.

There are any number of ways around this problem. The choice of which way you implement depends on what your goals are. The approach would differ if you were treating Notes as the authoritative source or if you were treating the eDirectory Identity Vault as the authoritative source, even if only in this spoke. Perhaps HR is authoritative, but since
it populates the IDV, and then the Notes system connects to it, eDirectory is effectivly authoritative from this perspective.

One method I like, when Notes is considered authoritative, is as follows:

1. In the Schema Mapping rule, change the mapping of Notes Full Name to not point at eDirectory CN.

2. In the filter, set CN to not synchronize in either direction.

3. If you want to store all the values from the Notes Full Name in eDirectory, create an attribute as part of an auxiliary class, and use that to store it and set the Schema map to it.

4. Use the synthesis of Given name, a space, and Surname to generate the naming attribute in eDirectory. Or just to populate the eDirectory Full Name field.

5. In the various event filters, (Publisher and Subscriber) add rules that watch for Given or Surname changing on users. On a change, reset the value of eDirectory Full Name to the sythesis of the two attributes.

This really just illustrates the problem of mapping diverse systems together. Notes has a view on how objects should look, as does eDirectory, and Active Directory is a little different, and so on. Merging them all together in a meaningful way is part of the art of an
Identity solution.

The next obvious question might be why would you care if all that extra info is in the Identity Vault? One reason is that Notes implementations often use the Full Name field to store extra e-mail addresses the user may have after mergers of systems. If you wanted to use LDAP searches to find all valid e-mail addresses, for example from the Identity Vault, then you could also search the auxillary class you added.


How To-Best Practice
Comment List
Related Discussions