Documentum and LDAP, Time to Grow Up

[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?

5 thoughts on “Documentum and LDAP, Time to Grow Up”

  1. ChaithanyaLekkalapudi says:

    Hi pie,

    The following statement may not be true all the times”Due to old, legacy, design considerations, both the user’s login id and the user’s name must be unique in the entire repository”. It is only username which corresponds to user_name of dm_user object type required to be unique, we can create two user object’s with the same user login id(user_login_name) with a different user login domain when the domain required mode is turned on the docbase. So the user login id need not be unique in case of multi domain environment and when the domain required mode is turned on.In case of LDAP config, the LDAP config object name becomes the user login domain for the users that have been synchronized from the corresponding LDAP server and you can point one LDAP config object to only one LDAP server(If we have two domains, we can create a seperate LDAP config object for each and every domain), so two users with the same login id but from different directory server can coexist with the restriction that user name is not same and domain needs to be provided while corresponding user’s login.

    Like

    • ChaithanyaLekkalapudi says:

      So configuring a docbase in domain required mode tries to solve this problem even in the case of LDAP.

      Like

    • Responding to you once…Yes, you are correct, it does solve the problem. Why EMC Support never said this in over a week is a mystery to me. Making the change to the Authentication Protocol setting on the repository from “Domain required” to Domain not Required” necessitates the running of a script and is a one-way change that cannot be undone.

      Support Note:
      https://solutions.emc.com/emcsolutionview.asp?id=esg6339

      Still doesn’t alleviate the issue with the user’s name needing to be unique.

      Going to try it, but will have to back-up the Dev environment first because not being able to roll-back is a problem.

      Like

  2. Bongo says:

    Entirely agree with you on this. Unfortunately, this is still one of the issues that plagues Documentum in many areas. It’s all over the RPS/RM models, where users are referenced by name not ID.

    Like

Comments are closed.