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…
- 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.
- 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.
4 thoughts on “Tip: Federations and Replicating LDAP Definitions”
It’s true as of now, setting up LDAP configuration to make work in federation setup requires manual step of replicating the LDAP config object’s from the governing repository to member repositories.The second option is the one which came into mind when i even started looking at the LDAP configuration in federation setup and it is nice to have. There is white paper titled “Deployment Strategies of an EMC Documentum Content Server Integration with LDAP”, which contains more information about LDAP configuration”@http://powerlink.emc.com:80/km/live1/en_US/Offering_Technical/White_Paper/h5638-deployment-strategies-of-documentum-ldap-wp.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tTZWFyY2hSZXN1bHRzRXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwMzk0Yjg1LGRhdGFTb3VyY2U9RENUTV9lbl9VU18w. See if that helps in configuring LDAP.
Continueing the above discussion there are some practical reasons for not doing this automatically..let’s consider a practical scenario where an organization has a federation which consists of member repositories spread across different geographical locations like one in india, one in US and one in Europe, in such a setup organizations will have replicated directory servers for each and every location, so it is better to for the member repostiory to use the local directory server for authentication rather than the directory server configured for the governing repository. Also there might be scenarios where the directory server accessible to governing repository may not be accessible to the member repository. Such scenarios require manual step of creating a LDAP config objects.
I figure there are good reasons for not doing this automatically, which you illustrate, but setting it up as “Global” could trigger it. In my situation, everything is co-located, so it would work.
The other option, documentation in the manuals, would also make sense and is what is needed more.
Comments are closed.