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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: