[Edit: See Comments for details on the “Why” of the edits.]
I’ve spent the last several weeks working on LDAP issues. Some have been simple, others, not so much. Suffice it to say, if you have Documentum 6.0 sp1, get the hot fixes for LDAP. They are readily available from EMC. Most of these are rolled up into D6.5 sp1.
Those issues aren’t isn’t what I want to talk about today. What I want to talk about is the advent of large systems and the need for applications, like Documentum, to accommodate the broader reality of some of today’s environments.
Before I go much deeper, I want to state that some vendors handle this worse than EMC, and some handle it better. I’m not going to name names. I do know at least one major player that does a much worse job, and I am pretty sure I can accurately pick one that handles it better.
ALL vendors need to understand this problem.
Enter the Multi-Domain Enterprise
Documentum has supported, for a while, the concept of multiple domains for users. If you have three LDAP directories in your organization, you could create three definitions to bring your users into the Content Server. This is a great feature.
Now comes the problem. Due to old, legacy, design considerations, both the user’s login id and the user’s name must be unique in the entire repository. There are still some objects, ACLs for one, that use the name field as a key. Well, when you have multiple organizations, each with their own LDAP directory, you might run into a problem.
Let’s take a random name, John Smith. He could be jsmith or smithj in one directory. In another directory, there could be a Jane Smith that could get the same login id another John Smith with the same display name. If they were in the same directory, LDAP would presumably prevent the duplication, but in separate directory, there are no such preventative measures.
Now, let’s take a directory with 10,000+ users. You will have a lot of names, all unique. Bring them into Documentum and you have a busy system. Now say you want to bring in 3,000+ users from another organization into the same repository. If their naming convention has the same style, you are going to have some overlap. Some users are not going to be able to access the system when they bomb out of the LDAP synch job.
This is a problem. This is probably a rare problem, but it is going to become more frequent as organizations grow.
When a merger of two companies occurs, this scenario can play out. When two different government agencies decide to work together, this scenario can play out. When two parts of the some company create separate domains because they don’t trust each other’s IT, this scenario plays out.
Let us not forget the user names as well. This can be fixed, as of D6, by appending a small string to the end of the user name with the organization abbreviation when you bring them into Documentum. This isn’t viable for the login id as the user needs to know how to login to the Documentum system and changing their login makes that challenging.
EMC needs to bite the bullet and invest in updating the Identity Management components of Documentum. Use the internal r_object_id as the key everywhere. Allow duplicate user names and login ids within a user domain. The domains already exist, with LDAP definition belonging to its own. USE IT!
I’ll leave you with a simple question…
Is a product truly Enterprise class when it can’t handle every user from two different authentication sources with confidence?