How do I update the uidAttribute map value in the LDAP provisioner configuration to entryUUID in IDM 5.x and OpenIDM 4.x?

Last updated Jan 18, 2022

The purpose of this article is to provide assistance with changing the map value for uidAttribute in the LDAP provisioner configuration in IDM/OpenIDM. You should map the uidAttribute to entryUUID, nsUniqueId or objectGUID to be immutable; however, our samples incorrectly defaulted this value to dn.

Archived

This article has been archived and is no longer maintained by ForgeRock.

Overview

For LDAP resources, it is always recommended to have entryUUID as your uidAttribute since it's an immutable and unique identifier that is assigned to each entry in the directory server and utilized by the replication subsystem for tracking changes. If uidAttribute=dn and the DN of an entry changes, your link between IDM/OpenIDM and the directory server becomes invalid; therefore you must map uidAttribute to the LDAP entryUUID attribute, which never changes over the lifetime of the entry even if the DN changes.

You should map to the following attributes depending on your directory server:

DS/OpenDJ - map to entryUUID.
ODSEE - map to nsUniqueId.
Active Directory® (AD) - map to objectGUID.

Caution

For LiveSync to function correctly, the uidAttribute must be entryUUID or DN for DS/OpenDJ, or nsUniqueId or DN for OSDEE. In particular, delete operations will fail with a "Failed to get OperationOptionsBuilder: Unsupported Uid attribute" error if the DN of the user or group uidAttribute does not correlate with the entry in the directory server changelog, which is the DN of the entry that has been deleted, and its unique id which corresponds to entryUUID.

A sample LDAP provisioner file incorrectly defaulted uidAttribute=dn; this sample has now been corrected in IDM 6. This article details the recommended way to change the map value if you used the sample and mapped to dn.

Changing the map value for uidAttribute

Note

The procedure described below requires that a correlation query or script is configured for the mapping that reliably associates the entries in the IDM/OpenIDM repository with entries in the directory server. It is highly recommended that the steps are tried out in a test environment first and it is verified that the entries are re-linked as expected.

You can change the map value as follows depending on which directory server you use:

DS/OpenDJ

Update the attribute in your provisioner configuration file (for example, provisioner.openicf-ldap.json located in the /path/to/idm/conf directory). From: "uidAttribute" : "dn" To: "uidAttribute" : "entryUUID"
Delete the existing link entries that use dn; you can delete them directly from the database using an SQL query similar to this: delete from links where linktype='managedUser_OpenDJ'
Run an IDM/OpenIDM to DS/OpenDJ reconciliation.

Providing all entries in IDM/OpenIDM and DS/OpenDJ are correctly associated by your correlation query, this reconciliation will result in the situation FOUND. This means that the correlation query has identified two entries in IDM/OpenIDM and DS/OpenDJ, but has not found a link. If the action for FOUND is set to UPDATE, the reconciliation process will re-create the links; this should be a relatively quick operation as no entry data needs to be updated.

ODSEE

Update the attribute in your provisioner configuration file (for example, provisioner.openicf-ldap.json located in the /path/to/idm/conf directory). From: "uidAttribute" : "dn" To: "uidAttribute" : "nsUniqueId"
Delete the existing link entries that use dn; you can delete them directly from the database using an SQL query similar to this: delete from links where linktype='managedUser_systemODSEEAccount'
Run an IDM/OpenIDM to ODSEE reconciliation.

Providing all entries in IDM/OpenIDM and ODSEE are correctly associated by your correlation query, this reconciliation will result in the situation FOUND. This means that the correlation query has identified two entries in IDM/OpenIDM and ODSEE, but has not found a link. If the action for FOUND is set to UPDATE, the reconciliation process will re-create the links; this should be a relatively quick operation as no entry data needs to be updated.

Active Directory

Update the attribute in your provisioner configuration file (for example, provisioner.openicf-ldap.json located in the /path/to/idm/conf directory). From: "uidAttribute" : "dn" To: "uidAttribute" : "objectGUID"
Delete the existing link entries that use dn; you can delete them directly from the database using an SQL query similar to this: delete from links where linktype='managedUser_systemActivedirectoryAccount'
Run an IDM/OpenIDM to AD reconciliation.

Providing all entries in IDM/OpenIDM and AD are correctly associated by your correlation query, this reconciliation will result in the situation FOUND. This means that the correlation query has identified two entries in IDM/OpenIDM and AD, but has not found a link. If the action for FOUND is set to UPDATE, the reconciliation process will re-create the links; this should be a relatively quick operation as no entry data needs to be updated.

Related Training

N/A

Related Issue Tracker IDs

OPENIDM-3330 (inconsistent use of uidAttribute in Ldap Provisioner Config)

OPENICF-996 (LDAP Connector: uidAttribute=entryUUID will avoid problems with liveSync of deletes)

OPENICF-946 (delete sync operation failing if uidAttribute is not entryUUID, nsUniqueId or dn)