This was going to be part of my post, Documentum and LDAP, Time to Grow Up, but I decided to pull it out as a short post in the Tips section.  Partly because I haven’t posted a Tip in a while, and partly because I think this deserves a little more attention.

The issue? A Federation and multiple LDAP definitions. The solution, simple, but poorly documented.

The Heart of the Matter

One client had an issue regarding using LDAP users in multiple repositories that were Federated.  When there was only one LDAP directory definition, everything worked and users could connect to all repositories.  When you added a second LDAP definition, the users from the new domain couldn’t authenticate in the member repositories.

Why one and not the other? Well, in D6.5 (maybe D6), they removed from DA the primary directory server from the server configuration.  It just lists the “Enabled” LDAP definitions.  All fine and good, but the field ldap_config_id still exists as a populated single-value attribute behind the scenes and is the one that the member repositories can use WITHOUT a definition. When you disable the old primary, the secondary LDAP definition is promoted and then those users are the ones that can authenticate into all Federation repositories.

Turns out you have to create the LDAP definitions in the member repositories, which is simple enough once you know.  The strongest quote indicating as such comes from the EMC Documentum Content Server Version 6.5 Distributed Configuration Guide,

An LDAP directory server is a third‑party product that provides a single place for maintenance of some or all users and groups in your enterprise. User and group entries are created in the directory server and those entries are propagated to all repositories set up to use the directory server. The property information that is propagated is defined when you set up the repository to use the LDAP directory server. The information is not limited to the global properties of the users and groups.

I added the emphasis.  The thing is, that isn’t even an implication. It says that the users will be propagated to the repositories setup to use LDAP.  The LDAP users went to all member repositories, LDAP definition or not.  The ability to authenticate is where it all fell down.

Support gave this statement in their personal defense and after quoting from the above paragraph, said, Although the building blocks do not state step by step, the above entry indicates that each repository must be setup to use the directory server.

That doesn’t cut it in my book.

What EMC Needs to Do

If I may make a suggestion or two to EMC…

1. Document! State, in no uncertain terms, this configuration requirement in the Distributed Configuration Guide AND in the Administration Guide.  There is a lot of documentation and to have it only implied in one of the documents is not enough.
2. Replicate the LDAP definitions with the Federation jobs. This would be pretty nice.  They could appear in the member repositories and then everything would just work.

The first option is easy.  The second one, along with appropriate documentation, would be better.  There may be a design reason why number two wasn’t implemented.  I suspect that it was “We don’t have time and it isn’t a burden to the user.”  It isn’t a burden, unless we have to figure out why things don’t work.