Setting up an unsupported active-directory

I was recently asked by a technologist on how to go about adding a new active directory sync which is not supported by Documentum. As I was thinking through it, I remembered that James McGovern had posed this question in the past – Why does Documentum need its own user store when it can use other systems which are developed solely for this purpose?

Well, off top of my head, here are some thoughts on it. First off, having a user store right in Documentum provides a way for users to get into Documentum even if its not setup to work with Enterprise active directory. This also means that we could create test users at the application level and not have the active directory corrupted. On top of this, the user store makes it possible for the Documentum application to apply (additional) security at that level. And personally, as a Technical Consultant, I love this feature as it gives more power to develop, deploy and maintain.

Now, lets go back to the original question. Taking the current LDAP design, here’s the communication layout:

[Active Directory] –> Custom Method –> [Docbase]

The high-level steps to achieve this would be:

1) Set up a config object in Documentum for the Job initialization.
2) Create a custom class which connects to the new active directory to get the user information and updates the Docbase.
3) Create a Documentum method out of this class and setup a Job.

Tada – that is all the magic there is to it.