Archive

Posts Tagged ‘authentication’

Documentum Installation Owner and Windows Services

August 13, 2008 doquent Leave a comment

Documentum installation owner user id is used for installing Documentum Content Server. On Windows, the installation sets up services for each repository (docbase), connection broker (docbroker), and Java method server. If you run into issues related to the installation owner id (typically authentication related), there are two aspects that can be checked:

  1. Each repository service has an associated command-line which specifies the installation owner as an argument. This command-line is visible on service properties when inspected through Windows services. You can edit the command-line through Documentum Server Manager utility. Select the relevant repository and click on the Edit Service button.
    1. Note that this argument overrides the install owner specified in server.ini in case there is a conflict between the two.
  2. All the windows services use logon credentials and the Documentum services mentioned above use the installation owner credentials. These can be edited through the standard Windows service properties dialog.
Inspecting Documentum Repository Service

Inspecting Documentum Repository Service

Issues related to the installation owner may arise when it is a domain user (as opposed to a local user) and/or when multiple content servers are being used. Another aspect to remember is that while Windows treats the user id as case-insensitive Documentum treats it as case-sensitive. Repository configuration also creates a user in the repository for the installation owner, using the exact case as entered during the installation process (at login time prior to installation).

What’s in a name?

August 7, 2008 doquent Leave a comment

Quite a bit if you are a Documentum user.

Documentum uses the user_name attribute of dm_user for uniquely identifying a user. This means that permissions and object ownership are also assigned to a user using user_name. Rajendra discusses various drawbacks of this design choice. One of the comments also indicates the reason why r_object_id wasn’t used as the key – the LDAP Sync job would sometimes delete and recreate the user object and creating a new object id in the process.

I have also been asked why wouldn’t one use the login ID as the key. I don’t have an authoritative answer but I have some thoughts around the difficulty of doing that in Documentum. First note that there is a user_os_name attribute as well as a user_login_name attribute. These are expected to be unique only in combination with user_os_domain and user_login_domain respectively. The attribute user_ldap_dn is relevant only when an LDAP server is being used. The population of these attributes is tied to the authentication mechanism in use, which could even be a custom plugin.

That leaves us with really one good option for the key – r_object_id, provided the object id wouldn’t change for a user. However, that’s not the case currently.

So why should you care? Check Rajendra’s post if you didn’t earlier when it was mentioned above. My experience has been more around presence of commas in the user name. It is not handled robustly across the platform. Even though problems are fixed in various service packs, they seem to be scattered across architecture layers. I shared an issue with the queue() call in another post.

More recently, I encountered another issue. In 5.3 SP5, if you enable dmcl trace in a WDK app (using wdk/dmclTrace.jsp) the log file name is generated using the name of the logged in user as a prefix. If the user name contains a comma, the portion of the name is stripped up to the comma. The resulting log file name is not accepted by some other piece of code, which apprently expects the log file name to begin with the user name. Yes, you can specify an explicit log file name but it tries to generate the log file mentioned above anyway.

The takeaway is to treat the user_name attribute like a key – use simple characters and if you have a choice maybe store the login id from your authentication source into the user name attribute. More likely you already have a deployment – in that case, arm yourself with the knowledge of these issues so that you can tackle them successfully.