Documentum story – Authentication failed for Installation Owner with the correct password

When installing a new Remote Content Server (High Availability), everything was going according to the plan until we try to login to DA using this new CS: the login using the Installation Owner (dmadmin) failed… Same result from dqMan or any other third party tools and only the iapi or idql sessions on the Content Server itself were still working because of the local trust. When something strange is happening regarding the authentication of the Installation Owner, I tink the first to do is always to verify if the dm_check_password is able to recognize your username/password:

[dmadmin@content_server_01 ~]$ $DOCUMENTUM/dba/dm_check_password
Enter user name: dmadmin
Enter user password:
Enter user extra #1 (not used):
Enter user extra #2 (not used):
$DOCUMENTUM/dba/dm_check_password: Result = (245) = (DM_CHKPASS_BAD_LOGIN)

As you can see above, this was actually not working so apparently the CS is thinking that the password isn’t the correct one… This might happen for several reasons:

1. Wrong permissions on the dm_check_password script

This script is part of the few scripts that need some specific permissions to be working… This is either done by the Installer if you provide the root’s password during the installation or you can run the $DOCUMENTUM/dba/dm_root_task script manually using the root account (using sudo/dzdo or asking your UNIX admin team for example). These are the permissions that are needed for this script:

[dmadmin@content_server_01 ~]$ ls -l $DOCUMENTUM/dba/dm_check_password
-rwsr-s---. 1 root dmadmin 14328 Oct 10 12:57 $DOCUMENTUM/dba/dm_check_password

If the permissions aren’t the right ones or if you think that this file has been corrupted somehow, then you can re-execute the dm_root_task again as root. It will ask you if you want to overwrite the current files and it will in the end set the permissions properly.

2. Expired password/account

If the OS password/account you are testing (Installation Owner in my case) is expired then there are several behaviors. In case the account is expired, then the dm_check_password will return a DM_CHKPASS_ACCOUNT_EXPIRED error. If it is the password that is expired, then in some OS, the dm_check_password won’t work with the bad login error shown at the beginning of this blog. This can be checked pretty easily on most OS. On a RedHat for example, it would be something like:

[dmadmin@content_server_01 ~]$ chage -l dmadmin
Last password change                                    : Oct 10, 2016
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 4294967295
Number of days of warning before password expires       : 7

In our case, we are setting the password/account to never expire to avoid such issues so that’s not the problem here. By the way, an expired password will also prevent you to use the crontab for example…

To change these parameters, you will need to have root permissions. That’s how it is done for example (press enter to just use the proposed value if that’s fine for you). The value between brackets is the current/proposed value and you can put your desired value after the colon:

[root@content_server_01 ~]$ chage dmadmin
Changing the aging information for dmadmin
Enter the new value, or press ENTER for the default

        Minimum Password Age [0]: 0
        Maximum Password Age [4294967295]: 4294967295
        Last Password Change (YYYY-MM-DD) [2016-10-10]:
        Password Expiration Warning [7]:
        Password Inactive [-1]: -1
        Account Expiration Date (YYYY-MM-DD) [-1]: -1

3. Wrong OS password

Of course if the OS password isn’t the correct one, then the dm_check_password will return a BAD_LOGIN… Makes sense, isn’t it? What I wanted to explain in this section is that in our case, we are always using sudo/dzdo options to change the current user to the Installation Owner and therefore we never really use the Installation Owner’s password at the OS level (only in DA, dqMan, aso…). To check if the password is correct at the OS level, you can of course start a ssh session with dmadmin directly or any other command that would require the password to be entered like a su or sudo on itself in our case:

[dmadmin@content_server_01 ~]$ su - dmadmin
Password:
[dmadmin@content_server_01 ~]$

As you can see, the OS isn’t complaining and therefore this is working properly: the OS password is the correct one.

4. Wrong mount options

Finally the last thing that can prevent you to login to your docbases remotely is some wrong options on your mount points… For this paragraph, I will suppose that $DOCUMENTUM has been installed on a mount point /app. So let’s check the current mount options, as root of course:

[root@content_server_01 ~]$ mount | grep "/app"
/dev/mapper/VG01-LV00 on /app type ext4 (rw,nodev,nosuid)
[root@content_server_01 ~]$
[root@content_server_01 ~]$ cat /etc/fstab | grep "/app"
/dev/mapper/VG01-LV00 /app                ext4        nodev,nosuid        1 2

That seems alright but actually it isn’t… For Documentum to work properly, the nosuid shouldn’t be present on the mount point where it has been installed! Therefore we need to change this. First of all, you need to update the file /etc/fstab so this change will remain after a reboot of the linux host. Just remove “,nosuid” to have something like that:

[root@content_server_01 ~]$ cat /etc/fstab | grep "/app"
/dev/mapper/VG01-LV00 /app                ext4        nodev               1 2

Now, the configuration inside the file /etc/fstab isn’t applied or reloaded if /app is already mounted. Therefore you need to remount it with the right options and that’s how you can do it:

[root@content_server_01 ~]$ mount | grep "/app"
/dev/mapper/VG01-LV00 on /app type ext4 (rw,nodev,nosuid)
[root@content_server_01 ~]$
[root@content_server_01 ~]$ mount -o remount,nodev /app
[root@content_server_01 ~]$
[root@content_server_01 ~]$ mount | grep "/app"
/dev/mapper/VG01-LV00 on /app type ext4 (rw,nodev)

Now that the mount options are correct, we can check again the dm_check_password:

[dmadmin@content_server_01 ~]$ $DOCUMENTUM/dba/dm_check_password
Enter user name: dmadmin
Enter user password:
Enter user extra #1 (not used):
Enter user extra #2 (not used):
$DOCUMENTUM/dba/dm_check_password: Result = (0) = (DM_EXT_APP_SUCCESS)

As you can see, this is now working… That’s a miracle ;).