Using an LDAP Server with Documentum (or any ECM for that matter) is pretty common to avoid managing users locally. In this blog, I wanted to talk about something that isn’t very common and that is the change of an LDAP Server. I’m not talking about just changing the server where your LDAP is hosted but rather changing the full LDAP Server Config inside Documentum (including its name). This is probably something that you will not do very often but I had this use case before so I thought it would be interesting to share.

 

So the use case I had was the following one: during a migration (including an upgrade in the process) from Virtual Machines to Kubernetes pods of dozens of environments, I had to automate the setup & management of the LDAP Server as well as normalize the configuration (name & other parameters) according to certain characteristics. The source and target LDAP Server was the same (a_application_type: netscape) so it was really just a matter of automation and conventions (if the target isn’t the same, it wouldn’t change anything for this blog). As you know if you already came across one of my previous blogs, DA is doing some magic, which prevents you to really manage the LDAP Server in the same way between DA and automation.

 

Therefore, the first part of the use case could have just been to change the LDAP Config object “certdb_location” parameter from the default “ldapcertdb_loc” to another “dm_location” which is using a “file” “path_type” and not a “directory” one. If you understood that last sentence, well done! If you didn’t, don’t worry, I would just suggest you to go and read the blog I linked above. It shows why you would need to use a dedicated dm_location with a path_type set to a file (that is the SSL Certificate of the LDAP Server) in order to automate the setup of an LDAP Config object. Of course, this is only needed if you are using SSL communications with the LDAP Server (i.e. LDAPS). Therefore, that would have been the simple part that is easily understandable, however it is another story if you also need to normalize the LDAP Config object setup in the process. Changing parameters of the LDAP Config object is easy and shouldn’t bring any issues or interruptions, but it’s another story if you need to change the name of the LDAP object… If the field is greyed out in DA, it’s for a reason ;).

 

The dozens of environments were all using the exact same backend LDAP Server but there were still some small differences in the setup like different names of course, different attributes mapped here and there, things like that. To be sure everything would be aligned on the target, I took the simplest road: removing all the source LDAP Config objects and recreating them in our CI/CD (JenkinsX pipelines, Ansible playbooks, aso…). Before removing anything, make sure that you understand what it means for your specific setup, it might not always be that straightforward! Alright, let’s check the status of the LDAP at the beginning:

[dmadmin@stg_cs ~]$ export docbase=REPO1
[dmadmin@stg_cs ~]$
[dmadmin@stg_cs ~]$ iapi ${docbase} -U${USER} -Pxxx << EOC
> ?,c,select r_object_id, object_name from dm_ldap_config;
> ?,c,select ldap_config_id from dm_server_config;
> ?,c,select user_source, count(*), user_login_domain from dm_user group by user_login_domain, user_source;
> EOC


        EMC Documentum iapi - Interactive API interface
        (c) Copyright EMC Corp., 1992 - 2016
        All rights reserved.
        Client Library Release 7.3.0040.0025


Connecting to Server using docbase REPO1
[DM_SESSION_I_SESSION_START]info:  "Session 010f123451ad5e0f started for user dmadmin."


Connected to Documentum Server running Release 7.3.0050.0039  Linux64.Oracle
Session id is s0
API> 
r_object_id       object_name
----------------  ----------------
080f1234500edaf3  Source_LDAP_Name
(1 row affected)

API> 
ldap_config_id
----------------
080f1234500edaf3
080f1234500edaf3
080f1234500edaf3
(3 rows affected)

API> 
user_source       count(*)                user_login_domain
----------------  ----------------------  -----------------
LDAP                               55075  Source_LDAP_Name
inline password                      307  
                                    1466  
(3 rows affected)

API> Bye
[dmadmin@stg_cs ~]$

 

As you can see above, there is currently one LDAP Config object that is used by around 55k users. There are three rows for the second query because it’s a HA Repository with 3 Content Servers. The first thing I did was therefore to remove the LDAP Config object and change the different references to prepare for the new name of the object (you can put the two last update commands in just one query, it would be better but I split them here for this example):

[dmadmin@stg_cs ~]$ export old_ldap_name=Source_LDAP_Name
[dmadmin@stg_cs ~]$ export new_ldap_name=Target_LDAP_Name
[dmadmin@stg_cs ~]$
[dmadmin@stg_cs ~]$ iapi ${docbase} -U${USER} -Pxxx << EOC
> ?,c,delete dm_ldap_config objects where object_name='${old_ldap_name}';
> ?,c,update dm_server_config object set ldap_config_id='0000000000000000';
> ?,c,update dm_user object set user_login_domain='${new_ldap_name}' where user_login_domain='${old_ldap_name}' and user_source='LDAP';
> ?,c,update dm_user object set user_global_unique_id='' where user_login_domain='${new_ldap_name}' and user_source='LDAP';
> ?,c,update dm_group object set group_global_unique_id='' where group_source='LDAP';
> EOC
 
 
        EMC Documentum iapi - Interactive API interface
        (c) Copyright EMC Corp., 1992 - 2016
        All rights reserved.
        Client Library Release 7.3.0040.0025
 
 
Connecting to Server using docbase REPO1
[DM_SESSION_I_SESSION_START]info:  "Session 010f123451ad5e11 started for user dmadmin."
 
 
Connected to Documentum Server running Release 7.3.0050.0039  Linux64.Oracle
Session id is s0
API> 
objects_deleted
---------------
              1
(1 row affected)
[DM_QUERY_I_NUM_UPDATE]info:  "1 objects were affected by your DELETE statement."
 
 
API> 
objects_updated
---------------
              3
(1 row affected)
[DM_QUERY_I_NUM_UPDATE]info:  "3 objects were affected by your UPDATE statement."
 
 
API> 
objects_updated
---------------
          55075
(1 row affected)
[DM_QUERY_I_NUM_UPDATE]info:  "55075 objects were affected by your UPDATE statement."
 
 
API> 
objects_updated
---------------
          55075
(1 row affected)
[DM_QUERY_I_NUM_UPDATE]info:  "55075 objects were affected by your UPDATE statement."
 
 
API>
objects_updated
---------------
            350
(1 row affected)
[DM_QUERY_I_NUM_UPDATE]info: "350 objects were affected by your UPDATE statement."
 
 
API> Bye
[dmadmin@stg_cs ~]$

 

At the moment, the new LDAP Config object wasn’t created yet but to avoid any disturbance, I already changed the “user_login_domain” from the old name to the new one. Another point to note is the reset of the “user_global_unique_id” parameter to an empty value (and do the same for the “group_global_unique_id”). As soon as users are synchronized using an LDAP, for example, they will be assigned with a unique identity. For an LDAP account, the id should be something like “###dm_ldap_config.object_name###:###random_numbers###” (E.g.: Source_LDAP_Name:078b1d9f-f4c35cd2-cad867c1-1f4a7872) while for an inline account it should be more “###dm_docbase_config.object_name###:###dm_user.user_name###” (E.g.: REPO1:Patou Morgan). If you just change the LDAP Config object name and update the “user_login_domain” of the user without anything else, in the end, the users won’t be able to login and if you try to execute the LDAP Sync, you should see some warnings showing that your users haven’t been synched (skipped). This is because the user already exist with a different identity. The message on the LDAP Sync would be something like “WARNING: A User with same user_name (Patou Morgan) exists in the docbase with a different identity”. The identity is generated by Documentum and written in the dm_user object under the “user_global_unique_id” attribute. Setting this to an empty value will allow Documentum to generate a new identity so that the user can work with the new LDAP.

 

Verification after the deletion:

[dmadmin@stg_cs ~]$ iapi ${docbase} -U${USER} -Pxxx << EOC
> ?,c,select r_object_id, object_name from dm_ldap_config;
> ?,c,select ldap_config_id from dm_server_config;
> ?,c,select user_source, count(*), user_login_domain from dm_user group by user_login_domain, user_source;
> EOC


        EMC Documentum iapi - Interactive API interface
        (c) Copyright EMC Corp., 1992 - 2016
        All rights reserved.
        Client Library Release 7.3.0040.0025


Connecting to Server using docbase REPO1
[DM_SESSION_I_SESSION_START]info:  "Session 010f123451ad5e12 started for user dmadmin."


Connected to Documentum Server running Release 7.3.0050.0039  Linux64.Oracle
Session id is s0
API> 
r_object_id       object_name
----------------  ----------------
(0 rows affected)

API> 
ldap_config_id
----------------
0000000000000000
0000000000000000
0000000000000000
(3 rows affected)

API> 
user_source       count(*)                user_login_domain
----------------  ----------------------  -----------------
LDAP                               55075  Target_LDAP_Name
inline password                      307  
                                    1466  
(3 rows affected)

API> Bye
[dmadmin@stg_cs ~]$

 

Once that was done, I simply re-created a new LDAP Config object as described in the blog I linked at the beginning of this post and using the new name “Target_LDAP_Name” (including the re-encryption of the password). Then running the LDAP Sync to make sure everything is working properly and checking the user_global_unique_id of some LDAP users to make sure it has been regenerated properly (you can do the same for some groups as well). It should be something like “Source_LDAP_Name:078b1d9f-f4c35cd2-cad867c1-1f4a7872” before and then updated to something like “Target_LDAP_Name:2d7c130d-84a47969-926907fa-f1649678” after the change of LDAP Config object name (+ execution of LDAP Sync) – obviously the names and the IDs will change in your case.