I recently faced another pretty interesting case with an incorrect r_object_id reference in OTDS. In a non-production (dev) Active Directory (Azure EntraID) that is used as source of truth for the users/groups, it looked like there was an account which was a bit messed-up. By that, I mean that the mail address, user name and other fields from that account were actually using the values from another account, which was completely separate. That resulted in a bit of mess inside OTDS and inside the Documentum Resource used behind it.

Dctm user not synchronized

The main problem was that at that customer, the Documentum “dm_user.user_name” is set to a custom “Display Name” value, which isn’t the default Display Name of the AD but a custom attribute generated/filled with some logic behind. With OTDS, you can add some logic into the Resource through JavaScript, but you often still rely on the background AD to get correct details. For that specific account (USERID01 below), that custom Display Name was set to the value from another account (USERID02). Because of that, OTDS mapped the user to a certain Documentum account. Later, the messed-up account was corrected but OTDS wasn’t able to recognize that the Dctm reference that it had stored was, then, incorrect and therefore it couldn’t update the account anymore.

Initially, the Application Team reached out to me because they weren’t able to see a value for the “dm_user.user_global_unique_id” field (of USERID01). That parameter, when using OTDS, is supposed to contain the “oTObjectGUID” (by default mapped to AD objectGUID). So, I quickly checked inside the Documentum Repository to see if this account was synched or not, if there were duplicate accounts or some other evident issues:

[dmadmin@cs-0 mop]$ iapi $DOCBASE_NAME -Udmadmin -Pxxx

        OpenText Documentum iapi - Interactive API interface
        Copyright (c) 2023. OpenText Corporation
        All rights reserved.
        Client Library Release 23.4.0000.0180

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

Connected to OpenText Documentum Server running Release 23.4.0000.0143  Linux64.Oracle
Session id is s0
API> ?,c,select r_object_id, user_login_name, user_name from dm_user where upper(user_login_name) like '%USERID01%';
r_object_id       user_login_name        user_name
----------------  ---------------------  -----------------------------
110f12348000c96b  USERID01               User Display Name 01

(1 row affected)

API> dump,c,110f12348000c96b
...
USER ATTRIBUTES

  user_name                       : User Display Name 01
  user_os_name                    : USERID01
  user_address                    : [email protected]
  user_group_name                 :
  user_privileges                 : 0
  owner_def_permit                : 7
  world_def_permit                : 3
  group_def_permit                : 5
  default_folder                  : /Home/User Display Name 01
  user_db_name                    :
  description                     :
  acl_domain                      : User Display Name 01
  acl_name                        : dm_450f12348000f652
  user_os_domain                  :
  home_docbase                    :
  user_state                      : 0
  client_capability               : 2
  globally_managed                : F
  user_delegation                 :
  workflow_disabled               : F
  alias_set_id                    : 0000000000000000
  user_source                     : OTDS
  user_ldap_dn                    :
  user_xprivileges                : 32
  failed_auth_attempt             : 0
  user_admin                      :
  user_global_unique_id           :
  user_login_name                 : USERID01
  user_login_domain               :
  user_initials                   :
  user_password                   : ****************
  user_web_page                   :
  first_failed_auth_utc_time      : nulldate
  last_login_utc_time             : 1/3/2022 13:39:00
  deactivated_utc_time            : nulldate
  deactivated_ip_addr             :
  restricted_folder_ids         []: <none>
  root_log_dir                    :

SYSTEM ATTRIBUTES

  r_is_group                      : F
  r_modify_date                   : 11/6/2025 07:12:07
  r_has_events                    : F
  r_object_id                     : 110f12348000c96b

APPLICATION ATTRIBUTES


INTERNAL ATTRIBUTES

  i_is_replica                    : F
  i_vstamp                        : 13

API> exit
Bye
[dmadmin@cs-0 mop]$

As you can see above, the “user_global_unique_id” is empty and some other fields also confirmed that the OTDS synchronization wasn’t done / working. Based on the OTDS Resource configuration, there should have been a lot of changes to that account, which wasn’t the case here.

OTDS user consolidation

Therefore, I tried to trigger a consolidation on the user itself from the OTDS UI, to see what the logs were saying:

Thread Id: 654,623      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.UpdateApiOp      Method: update  Level: OK       Message: Enter: update(ObjectClass: __ACCOUNT__, Attribute: {Name=__UID__, Value=[110f12348004510b]}, [Attribute: {Name=__TENANT__, Value=[]}, Attribute: {Name=user_os_name, Value=[]}, Attribute: {Name=AccountDisabled, Value=[false]}, Attribute: {Name=user_global_unique_id, Value=[9ibc9uqrfKafp/K1LRb0og==]}, Attribute: {Name=user_rename_unlock_locked_obj, Value=[T]}, Attribute: {Name=client_capability, Value=[2]}, Attribute: {Name=user_login_domain, Value=[]}, Attribute: {Name=user_name, Value=[User Display Name 01]}, Attribute: {Name=user_ldap_dn, Value=[CN=USERID01,OU=Users,DC=domain,DC=com]}, Attribute: {Name=user_address, Value=[[email protected]]}, Attribute: {Name=user_login_name, Value=[USERID01]}, Attribute: {Name=user_xprivileges, Value=[32]}, Attribute: {Name=create_default_cabinet, Value=[F]}, Attribute: {Name=user_privileges, Value=[0]}, Attribute: {Name=__PARTITION__, Value=[PARTITION01]}, Attribute: {Name=__OTDS_UUID__, Value=[7748abe9-7a51-9d43-b6c4-13ba639481b5]}, Attribute: {Name=user_type, Value=[dm_user]}, Attribute: {Name=user_rename_enabled, Value=[T]}, Attribute: {Name=default_folder, Value=[/Home/User Display Name 01]}, Attribute: {Name=__NAME__, Value=[User Display Name 01]}], null)
Thread Id: 654,631      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f12348000051b]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@68f2554c})
Thread Id: 654,634      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f12348000051e]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@6fa3934d})
Thread Id: 654,635      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f123480007dd8]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@41d7fb29})
Thread Id: 654,637      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f12348000451d]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@7a229867})
Thread Id: 654,638      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f12348000451e]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@4e95620c})
Thread Id: 654,665      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.UpdateApiOp      Method: update  Level: OK       Message: Enter: update(ObjectClass: __ACCOUNT__, Attribute: {Name=__UID__, Value=[110f12348004510b]}, [Attribute: {Name=__TENANT__, Value=[]}, Attribute: {Name=user_os_name, Value=[]}, Attribute: {Name=AccountDisabled, Value=[false]}, Attribute: {Name=user_global_unique_id, Value=[9ibc9uqrfKafp/K1LRb0og==]}, Attribute: {Name=user_rename_unlock_locked_obj, Value=[T]}, Attribute: {Name=client_capability, Value=[2]}, Attribute: {Name=user_login_domain, Value=[]}, Attribute: {Name=user_name, Value=[User Display Name 01]}, Attribute: {Name=user_ldap_dn, Value=[cn=USERID01,ou=users,dc=domain,dc=com]}, Attribute: {Name=user_address, Value=[[email protected]]}, Attribute: {Name=user_login_name, Value=[USERID01]}, Attribute: {Name=user_xprivileges, Value=[32]}, Attribute: {Name=create_default_cabinet, Value=[F]}, Attribute: {Name=user_privileges, Value=[0]}, Attribute: {Name=__PARTITION__, Value=[PARTITION01]}, Attribute: {Name=__OTDS_UUID__, Value=[7748abe9-7a51-9d43-b6c4-13ba639481b5]}, Attribute: {Name=user_type, Value=[dm_user]}, Attribute: {Name=user_rename_enabled, Value=[T]}, Attribute: {Name=default_folder, Value=[/Home/User Display Name 01]}, Attribute: {Name=__NAME__, Value=[User Display Name 01]}], null)
Thread Id: 654,623      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.UpdateApiOp      Method: update  Level: OK       Message: Exception:
com.opentext.otds.connectors.rest.HttpException: Error updating member: 400 Bad Request <!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1></body></html>
        at com.opentext.otds.connectors.rest.RestSession.updateMember(RestSession.java:314)
        at com.opentext.otds.connectors.rest.RestConnector$9.endOfAttributes(RestConnector.java:557)
        at com.opentext.otds.connectors.rest.RestConnector$9.endOfAttributes(RestConnector.java:526)
        at com.opentext.otds.connectors.rest.RestAttributeParser.parse(RestAttributeParser.java:29)
        at com.opentext.otds.connectors.rest.RestConnector.updateMember(RestConnector.java:564)
        ...
Thread Id: 654,635      Time: 11/18/25, 8:53 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Exception:
com.opentext.otds.connectors.rest.HttpException: Error adding group members: 404 Not Found <!doctype html><html lang="en"><head><title>HTTP Status 404 – Not Found</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 404 – Not Found</h1></body></html>
        at com.opentext.otds.connectors.rest.RestSession.addMembersToGroup(RestSession.java:387)
        at com.opentext.otds.connectors.rest.RestConnector$3.endOfAttributes(RestConnector.java:222)
        at com.opentext.otds.connectors.rest.RestConnector$3.endOfAttributes(RestConnector.java:172)
        at com.opentext.otds.connectors.rest.RestAttributeParser.parse(RestAttributeParser.java:29)
        ...

So OTDS Consolidation ends-up with “400 Bad Request” and “404 Not Found” errors. While looking into the message in more details, you can see that it has a “__UID__” attribute (“Attribute: {Name=__UID__, Value=[110f12348004510b]}“) which represents the r_object_id of the dm_user, normally… But in this case, it’s different from the one in the dump above. And that r_object_id doesn’t exist in the Repository anymore:

[dmadmin@cs-0 ~]$ iapi $DOCBASE_NAME -Udmadmin -Pxxx << EOC
> dump,c,110f12348004510b
> exit
> EOC

        OpenText Documentum iapi - Interactive API interface
        Copyright (c) 2023. OpenText Corporation
        All rights reserved.
        Client Library Release 23.4.0000.0180

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

Connected to OpenText Documentum Server running Release 23.4.0000.0143  Linux64.Oracle
Session id is s0
API> ...
[DM_API_E_EXIST]error:  "Document/object specified by 110f12348004510b does not exist."

[DM_SESSION_W_FETCH_FAILED]warning:  "Fetch of object with handle 110f12348004510b and type NULL failed."

API> Bye
[dmadmin@cs-0 ~]$

What happened exactly? I’m not sure, I tried to ask the people that were looking at that case / trying to fix the AD account, but nobody could tell me if there was another account that was removed / re-assigned. I can only assume OTDS initially created a duplicate account (USERID02) because it couldn’t map the existing account in the Repository since the user_name was messed-up in the AD. And that someone either deleted or re-assigned the OTDS account to the other account (which was initially created by the LDAP Sync years ago, before the migration to OTDS in the past few days/weeks).

Reflection on the way to fix it

In any cases, what can be done to fix the situation…? The problem is that now OTDS references a r_object_id that doesn’t exist in Documentum and that prevent the synchronization to happen properly. Even if an account exists in the Repository with the expected user_login_name / user_name, since it’s not the one OTDS has internally, it’s not doing anything.

I could see 2 options to solve the case:

  1. Since it’s part of a Synchronized Partition, you cannot delete the OTDS account. Therefore, a first solution could be to exclude this specific account from the Partition (by updating the user filter to specifically exclude that one), execute a consolidation to make sure all references of it disappears before re-adding the account again.
  2. Find and update the wrong reference in the OTDS DB

The safest approach is probably the #1, but since I was in the middle of debugging the issue, I wanted to try the second one instead. This is to confirm how OTDS behaves and maybe to get more insights on how the DB is organized… Who knows, it might be helpful at some point in the future ;).

From what I already knew, the users are put inside the “MEMBERS” table but that would only contain things from the Source system (AD here). The possible external details like the “r_object_id” I’m looking for here would usually be in the “RESOURCEACCESS” table instead. Therefore, I found my user through its user id, fetched the UUID that is the cross-reference used by OTDS and was indeed able to find the wrong reference there:

SQL> SET PAGES 999;
SQL> SET WRAP OFF;
SQL> SET LINESIZE 50;
SQL> SELECT UUID, NAME FROM MEMBERS WHERE NAME='USERID01';

UUID                             NAME
-------------------------------- -----------------
7BE9748AA57149D3BC641A948363B1B5 USERID01

SQL> SELECT MEMBERID, IDINRESOURCE FROM RESOURCEACCESS WHERE MEMBERID='7BE9748AA57149D3BC641A948363B1B5';

MEMBERID                         IDINRESOURCE
-------------------------------- -----------------
7BE9748AA57149D3BC641A948363B1B5 110f12348004510b

DB Crawler – Preparation

But what if you aren’t certain if this is the only reference in the whole DB…? I was in this position too. I knew I could find what I was looking for in these 2 tables, but I wasn’t 100% certain if it was the only place. Well, I sure hoped so, as having duplicates / multiple references for the same thing in the DB could be pretty bad.

Let’s crawl the DB to see if there are any other references then! First of all, I created a small SQL file which contains the connection to the DB, the generation of all needed SELECT statements for each column of each table which have a string data_type and finally the execution of the generated selects:

[dmadmin@cs-0 mop]$ ls -l
total 4
-rw-r----- 1 dmadmin dmadmin 536 Nov 18 09:03 generate_and_execute_selects.sql
[dmadmin@cs-0 mop]$
[dmadmin@cs-0 mop]$ cat generate_and_execute_selects.sql
CONNECT otds-user/otds-password@otds-tns
spool selects.sql
set pagesize 0
set linesize 10000
set trims on
SELECT
    'SELECT ''' || table_name || ''' AS table_name, ''' ||
    column_name || ''' AS column_name, "' ||
    column_name || '" AS value_found ' ||
    'FROM ' || owner || '.' || table_name ||
    ' WHERE "' || column_name || '" LIKE ''%110f12348004510b%'';'
  FROM
    all_tab_columns
  WHERE
    data_type IN ('VARCHAR2','NVARCHAR2','CHAR','NCHAR','CLOB','RAW')
    AND owner = 'OTDS';
spool off
set echo on
@selects.sql
quit
[dmadmin@cs-0 mop]$

Note 1: I put the CONNECT inside the SQL file, but you can obviously set it at command line or through variables, so it doesn’t show in the bash history. It’s just an example.

Note 2: You can change the string that you are looking for, it’s in between the ‘%string%‘ (line 11 of the SQL file). You can also change the data_type as required (line 15 of the SQL file). For OTDS on Oracle, only VARCHAR2, CLOB and RAW are used.

Note 3: I’m using double quotes (“) around the column_name. This is because, unfortunately, some columns for OTDS appears to be created by the product with case sensitivity… Therefore, without these double quotes, you wouldn’t be able to query for the 2 tables: “SCHEMA_HISTORY” and “BOOTSTRAP_HISTORY“. Without it, the DB Crawling would succeed for all tables except these 2 where you would get an “invalid identifier” on the column name… As an example, you can try to execute these two queries:

select * from SCHEMA_HISTORY WHERE description like '%setup%'; -- this might not work
select * from SCHEMA_HISTORY WHERE "description" like '%setup%'; -- this works

DB Crawler – Execution

Once you have the above SQL file, you can execute it. As mentioned, it will start with the generation of another SQL file, containing all needed SELECT statements for all columns of all tables. And it will then execute all these SELECT statements one by one. All the logs will be inside the “selects.log” file in this case:

[dmadmin@cs-0 mop]$ sqlplus /nolog @generate_and_execute_selects.sql > selects.log
[dmadmin@cs-0 mop]$
[dmadmin@cs-0 mop]$ echo $?
0
[dmadmin@cs-0 mop]$
[dmadmin@cs-0 mop]$ ls -l
total 96
-rw-r----- 1 dmadmin dmadmin   536 Nov 18 09:03 generate_and_execute_selects.sql
-rw-r----- 1 dmadmin dmadmin 54518 Nov 18 09:03 selects.log
-rw-r----- 1 dmadmin dmadmin 25122 Nov 18 09:03 selects.sql
[dmadmin@cs-0 mop]$

I usually start a first execution with “@selects.sql” being commented in the “generate_and_execute_selects.sql” file. This is to generate the SELECT statements without executing them. I can first verify if everything looks good before cleaning and re-executing without the line commented out.

For OTDS, there are 164 SELECT statements being generated. For this environment, there are 252 columns owned by “OTDS” in total, but 49+39 of these that have a TIMESTAMP+NUMBER data_type, respectively, which gives us the 164 results, as expected:

[dmadmin@cs-0 mop]$ cat selects.sql
SELECT 'ACCESSROLEMEMBERS' AS table_name, 'TENANTID' AS column_name, "TENANTID" AS value_found FROM OTDS.ACCESSROLEMEMBERS WHERE "TENANTID" LIKE '%110f12348004510b%';
SELECT 'ACCESSROLEMEMBERS' AS table_name, 'ACCESSROLEID' AS column_name, "ACCESSROLEID" AS value_found FROM OTDS.ACCESSROLEMEMBERS WHERE "ACCESSROLEID" LIKE '%110f12348004510b%';
SELECT 'ACCESSROLEMEMBERS' AS table_name, 'MEMBERID' AS column_name, "MEMBERID" AS value_found FROM OTDS.ACCESSROLEMEMBERS WHERE "MEMBERID" LIKE '%110f12348004510b%';
SELECT 'SCHEMA_HISTORY' AS table_name, 'version' AS column_name, "version" AS value_found FROM OTDS.SCHEMA_HISTORY WHERE "version" LIKE '%110f12348004510b%';
SELECT 'SCHEMA_HISTORY' AS table_name, 'description' AS column_name, "description" AS value_found FROM OTDS.SCHEMA_HISTORY WHERE "description" LIKE '%110f12348004510b%';
...
...
SELECT 'JOBS' AS table_name, 'NAME' AS column_name, "NAME" AS value_found FROM OTDS.JOBS WHERE "NAME" LIKE '%110f12348004510b%';
SELECT 'JOBS' AS table_name, 'TARGET' AS column_name, "TARGET" AS value_found FROM OTDS.JOBS WHERE "TARGET" LIKE '%110f12348004510b%';
SELECT 'BOOTSTRAP_HISTORY' AS table_name, 'version' AS column_name, "version" AS value_found FROM OTDS.BOOTSTRAP_HISTORY WHERE "version" LIKE '%110f12348004510b%';
SELECT 'BOOTSTRAP_HISTORY' AS table_name, 'description' AS column_name, "description" AS value_found FROM OTDS.BOOTSTRAP_HISTORY WHERE "description" LIKE '%110f12348004510b%';
SELECT 'BOOTSTRAP_HISTORY' AS table_name, 'type' AS column_name, "type" AS value_found FROM OTDS.BOOTSTRAP_HISTORY WHERE "type" LIKE '%110f12348004510b%';
SELECT 'BOOTSTRAP_HISTORY' AS table_name, 'script' AS column_name, "script" AS value_found FROM OTDS.BOOTSTRAP_HISTORY WHERE "script" LIKE '%110f12348004510b%';
SELECT 'BOOTSTRAP_HISTORY' AS table_name, 'installed_by' AS column_name, "installed_by" AS value_found FROM OTDS.BOOTSTRAP_HISTORY WHERE "installed_by" LIKE '%110f12348004510b%';

164 rows selected.

[dmadmin@cs-0 mop]$

To verify if all SELECT statements were executed successfully and to check the list of occurrences of the specific string, you can use such commands:

[dmadmin@cs-0 mop]$ grep '^SQL> SELECT' selects.log | wc -l
164
[dmadmin@cs-0 mop]$
[dmadmin@cs-0 mop]$ grep -i 'ERROR' selects.log | wc -l
0
[dmadmin@cs-0 mop]$
[dmadmin@cs-0 mop]$ grep 'no rows selected' selects.log | wc -l
163
[dmadmin@cs-0 mop]$
[dmadmin@cs-0 mop]$ grep -B1 '[^%]110f12348004510b' selects.log
SQL> SELECT 'RESOURCEACCESS' AS table_name, 'IDINRESOURCE' AS column_name, "IDINRESOURCE" AS value_found FROM OTDS.RESOURCEACCESS WHERE "IDINRESOURCE" LIKE '%110f12348004510b%';
RESOURCEACCESS IDINRESOURCE 110f12348004510b
[dmadmin@cs-0 mop]$

Fixing the wrong r_object_id reference in OTDS

Therefore, that confirms that all 164 SELECT statements were executed, there was 0 errors, 163 empty results (no match in the full column) and only a single query that matched. This means that the only reference present for the Documentum r_object_id in the OTDS DB is indeed stored inside the “RESOURCEACCESS.IDINRESOURCE” column. So let’s update / correct that value:

SQL> SELECT MEMBERID, IDINRESOURCE FROM RESOURCEACCESS WHERE MEMBERID='7BE9748AA57149D3BC641A948363B1B5';

MEMBERID                         IDINRESOURCE
-------------------------------- -----------------
7BE9748AA57149D3BC641A948363B1B5 110f12348004510b

SQL> UPDATE RESOURCEACCESS SET IDINRESOURCE='110f12348000c96b' WHERE MEMBERID='7BE9748AA57149D3BC641A948363B1B5';

1 row updated.

SQL> SELECT MEMBERID, IDINRESOURCE FROM RESOURCEACCESS WHERE MEMBERID='7BE9748AA57149D3BC641A948363B1B5';

MEMBERID                         IDINRESOURCE
-------------------------------- -----------------
7BE9748AA57149D3BC641A948363B1B5 110f12348000c96b

Now that it’s corrected, the final step is to trigger a new consolidation for that specific account, to see if OTDS is now able to update the account in Documentum:

Thread Id: 655,026      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.UpdateApiOp      Method: update  Level: OK       Message: Enter: update(ObjectClass: __ACCOUNT__, Attribute: {Name=__UID__, Value=[110f12348000c96b]}, [Attribute: {Name=__TENANT__, Value=[]}, Attribute: {Name=user_os_name, Value=[]}, Attribute: {Name=AccountDisabled, Value=[false]}, Attribute: {Name=user_global_unique_id, Value=[9ibc9uqrfKafp/K1LRb0og==]}, Attribute: {Name=user_rename_unlock_locked_obj, Value=[T]}, Attribute: {Name=client_capability, Value=[2]}, Attribute: {Name=user_login_domain, Value=[]}, Attribute: {Name=user_name, Value=[User Display Name 01]}, Attribute: {Name=user_ldap_dn, Value=[CN=USERID01,OU=Users,DC=domain,DC=com]}, Attribute: {Name=user_address, Value=[[email protected]]}, Attribute: {Name=user_login_name, Value=[USERID01]}, Attribute: {Name=user_xprivileges, Value=[32]}, Attribute: {Name=create_default_cabinet, Value=[F]}, Attribute: {Name=user_privileges, Value=[0]}, Attribute: {Name=__PARTITION__, Value=[PARTITION01]}, Attribute: {Name=__OTDS_UUID__, Value=[7748abe9-7a51-9d43-b6c4-13ba639481b5]}, Attribute: {Name=user_type, Value=[dm_user]}, Attribute: {Name=user_rename_enabled, Value=[T]}, Attribute: {Name=default_folder, Value=[/Home/User Display Name 01]}, Attribute: {Name=__NAME__, Value=[User Display Name 01]}], null)
Thread Id: 655,032      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f123480007dd8]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@289175b7})
Thread Id: 655,033      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f12348000051b]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@2551d69b})
Thread Id: 655,036      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f12348000051e]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@3f885a33})
Thread Id: 655,038      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f12348000451d]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@39b49b96})
Thread Id: 655,040      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Enter: create(ObjectClass: DIRECTIONAL_ASSOCIATION, [Attribute: {Name=ToObjClassName, Value=[__GROUP__]}, Attribute: {Name=FromObjClassName, Value=[__MEMBER__]}, Attribute: {Name=From, Value=[[Multiple Members]]}, Attribute: {Name=To, Value=[120f12348000451e]}, Attribute: {Name=Type, Value=[MemberOfGroup]}], OperationOptions: {Members=[Ljava.lang.String;@4504edb8})
Thread Id: 655,066      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.UpdateApiOp      Method: update  Level: OK       Message: Enter: update(ObjectClass: __ACCOUNT__, Attribute: {Name=__UID__, Value=[110f12348000c96b]}, [Attribute: {Name=__TENANT__, Value=[]}, Attribute: {Name=user_os_name, Value=[]}, Attribute: {Name=AccountDisabled, Value=[false]}, Attribute: {Name=user_global_unique_id, Value=[9ibc9uqrfKafp/K1LRb0og==]}, Attribute: {Name=user_rename_unlock_locked_obj, Value=[T]}, Attribute: {Name=client_capability, Value=[2]}, Attribute: {Name=user_login_domain, Value=[]}, Attribute: {Name=user_name, Value=[User Display Name 01]}, Attribute: {Name=user_ldap_dn, Value=[cn=USERID01,ou=users,dc=domain,dc=com]}, Attribute: {Name=user_address, Value=[[email protected]]}, Attribute: {Name=user_login_name, Value=[USERID01]}, Attribute: {Name=user_xprivileges, Value=[32]}, Attribute: {Name=create_default_cabinet, Value=[F]}, Attribute: {Name=user_privileges, Value=[0]}, Attribute: {Name=__PARTITION__, Value=[PARTITION01]}, Attribute: {Name=__OTDS_UUID__, Value=[7748abe9-7a51-9d43-b6c4-13ba639481b5]}, Attribute: {Name=user_type, Value=[dm_user]}, Attribute: {Name=user_rename_enabled, Value=[T]}, Attribute: {Name=default_folder, Value=[/Home/User Display Name 01]}, Attribute: {Name=__NAME__, Value=[User Display Name 01]}], null)
Thread Id: 655,026      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.UpdateApiOp      Method: update  Level: OK       Message: Return: Attribute: {Name=__UID__, Value=[110f12348000c96b]}
Thread Id: 655,033      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Return: Attribute: {Name=__UID__, Value=[[Multiple Members]__com.opentext.otds.connectors.reserved.string____MEMBER__%%%__GROUP__%%%MemberOfGroup__com.opentext.otds.connectors.reserved.string__120f12348000051b]}
Thread Id: 655,032      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Return: Attribute: {Name=__UID__, Value=[[Multiple Members]__com.opentext.otds.connectors.reserved.string____MEMBER__%%%__GROUP__%%%MemberOfGroup__com.opentext.otds.connectors.reserved.string__120f123480007dd8]}
Thread Id: 655,066      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.UpdateApiOp      Method: update  Level: OK       Message: Return: Attribute: {Name=__UID__, Value=[110f12348000c96b]}
Thread Id: 655,038      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Return: Attribute: {Name=__UID__, Value=[[Multiple Members]__com.opentext.otds.connectors.reserved.string____MEMBER__%%%__GROUP__%%%MemberOfGroup__com.opentext.otds.connectors.reserved.string__120f12348000451d]}
Thread Id: 655,040      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Return: Attribute: {Name=__UID__, Value=[[Multiple Members]__com.opentext.otds.connectors.reserved.string____MEMBER__%%%__GROUP__%%%MemberOfGroup__com.opentext.otds.connectors.reserved.string__120f12348000451e]}
Thread Id: 655,036      Time: 11/18/25, 9:11 AM Class: org.identityconnectors.framework.api.operations.CreateApiOp      Method: create  Level: OK       Message: Return: Attribute: {Name=__UID__, Value=[[Multiple Members]__com.opentext.otds.connectors.reserved.string____MEMBER__%%%__GROUP__%%%MemberOfGroup__com.opentext.otds.connectors.reserved.string__120f12348000051e]}

The logs look clean and the same is shown on Documentum:

[dmadmin@cs-0 ~]$ iapi $DOCBASE_NAME -Udmadmin -Pxxx << EOC
> dump,c,110f12348000c96b
> exit
> EOC

        OpenText Documentum iapi - Interactive API interface
        Copyright (c) 2023. OpenText Corporation
        All rights reserved.
        Client Library Release 23.4.0000.0180

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

Connected to OpenText Documentum Server running Release 23.4.0000.0143  Linux64.Oracle
Session id is s0
API> ...
USER ATTRIBUTES

  user_name                       : User Display Name 01
  user_os_name                    :
  user_address                    : [email protected]
  user_group_name                 :
  user_privileges                 : 0
  owner_def_permit                : 7
  world_def_permit                : 3
  group_def_permit                : 5
  default_folder                  : /Home/User Display Name 01
  user_db_name                    :
  description                     :
  acl_domain                      : User Display Name 01
  acl_name                        : dm_450f12348000f652
  user_os_domain                  :
  home_docbase                    :
  user_state                      : 0
  client_capability               : 2
  globally_managed                : F
  user_delegation                 :
  workflow_disabled               : F
  alias_set_id                    : 0000000000000000
  user_source                     : OTDS
  user_ldap_dn                    : cn=USERID01,ou=users,dc=domain,dc=com
  user_xprivileges                : 32
  failed_auth_attempt             : 0
  user_admin                      :
  user_global_unique_id           : 9ibc9uqrfKafp/K1LRb0og==
  user_login_name                 : USERID01
  user_login_domain               :
  user_initials                   :
  user_password                   : ****************
  user_web_page                   :
  first_failed_auth_utc_time      : nulldate
  last_login_utc_time             : 1/3/2022 13:39:00
  deactivated_utc_time            : nulldate
  deactivated_ip_addr             :
  restricted_folder_ids         []: <none>
  root_log_dir                    :

SYSTEM ATTRIBUTES

  r_is_group                      : F
  r_modify_date                   : 11/18/2025 09:11:38
  r_has_events                    : F
  r_object_id                     : 110f12348000c96b

APPLICATION ATTRIBUTES


INTERNAL ATTRIBUTES

  i_is_replica                    : F
  i_vstamp                        : 15

API> Bye
[dmadmin@cs-0 ~]$

The account was just updated, the “user_global_unique_id” has been populated with some others as well. Therefore, the OTDS synchronization is now correct for that account. In summary, this case was pretty specific, with issues inside the AD directly, which created a bit of a mess in OTDS and Documentum with a mapping to a wrong user which is apparently not present anymore, etc… But once the AD was fixed, I was able to reset the r_object_id reference in OTDS, so that it could restore itself to a correct behavior.