If you have worked much with Identity Manager then you probably are used to the idea of an authentication tree and an Identity Vault.

To me this was a bit of a leap, since I am a bit of a "one tree to rule them all" purist. Over time I am slowly being dragged into the "as many trees as you need" world. I still think that through the proper use of replicas, filtered replicas, and LDAP Mapping rules it should be possible to do much of what is needed in a single tree, but I have given in to the world view of multiple trees. I still think some people take this way too far. (For example, Novell internally at one point had way too many eDirectory trees syncing together. But they had good historical reasons for it, just needlessly complex in my mind. Not that I am saying I could do it better!)

The basic model is that you use your Identity Vault as the hub of your Identity Management world, and you build an eDirectory to eDirectory driver as a spoke off the hub, with the minimal set of attributes needed. In this model the central Identity Vault is very rich in attributes, perhaps more than should ever be exposed, and you'd probably never want to expose it to users directly.

The authentication tree has access allowed to it by users, and may contain only usernames and passwords - perhaps some subset of group memberships, perhaps more.

Watch out for NMAS encrypted attributes like Secret Store and Forgotten Password hints, since once they are encrypted in a single tree, they cannot be synchronized to anything else. (Keep pushing for this feature please, if you get a chance! It would be very useful to be able to synchronize the Forgotten Password hints to a second tree.)

The structure of the authentication tree is another point of debate. Should it be flat, or should it be structured? That is, should there be a Active.Users.Acme container that all users go into, flat - or - should there be a Regions level, then Country, then Sites, so that perhaps it would be as structured as Ottawa.CA.NA.Active.Users.acme

Generally this will depend on your needs and goals. Often they change midstream, and now finally on to the real topic of this article!

When developing this connector, you may find that you are playing around and tweaking the placement and movement rules quite a bit. First, your test environment should mirror production at some point, to be truly a proper test, since users do the darndest things! Nothing reveals problems like a bulk migrate of all the users to find the strange exceptions, to which you say, "But no User was supposed to look like that!" When you migrate the users in, to test the placement rules, you may find the need to clean up the test tree.

In ConsoleOne it is not possible to delete a container that has children. You have to first delete the children before deleting the parent container. You could LDIF out all the DN's and then script them into Delete operations. I have seen tools written to bulk delete users, using NCP or what not, but they are often Windows-based. I am running SLED and would like to stay in Linux as long as possible.

I just noticed the other day that the free Ldap browser from http://www-unix.mcs.anl.gov/~gawor/ldap/ has a really neat function. If you select a parent container and choose to delete, you will get prompted for confirmation. On the confirmation page there is a check box to Delete children as well. Lovely!

This is a huge timesaver, and it makes designing and testing deeply structured Authentication trees much more efficient!