Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
I’m working on an LDAP integration where the account DN is derived from the user’s UID (badge ID). Contractors have a badge ID starting with “C”, and when they convert to full-time employees, the badge ID changes to start with “E”.
What I’ve tried so far is creating a new identity attribute in the HR Source identity profile and populating the UID using transforms (concatenation logic based on the badge ID). I also created a separate transform to construct the LDAP distinguished name using this UID and enabled attribute sync so the value flows into LDAP.
When the badge ID changes, SailPoint attempts to update the UID in LDAP. This results in a Modify RDN error (LDAP error 67 – operation not allowed on RDN). I’ve seen this consistently in the Events section during provisioning when the conversion happens.
I looked into whether this could be handled by renaming the LDAP DN, since LDAP supports Modify RDN, but I don’t see a clear way to do this using the SailPoint LDAP connector. When the badge ID changes (which is part of the DN), the update fails during provisioning.
Right now, the result I’m seeing is a failed provisioning attempt whenever a contractor converts to an employee and the UID changes. What I was expecting was either a supported way to handle the rename or guidance on what the recommended approach is in this scenario. I’m trying to understand how others handle contractor-to-employee conversions in LDAP when the UID is part of the DN, and whether this is typically solved through workflows, rules, or by deleting and recreating the account.
Hello Tarun,
I believe your failure is because the RDN itself is changing (e.g., uid=C123 → uid=E456). That requires an LDAP ModifyDN/ModifyRDN operation. LDAP servers reject a normal Modify on an RDN attribute (error 67).
Does yout Service Account have the required permissions on the LDAP server?
I am also syncing CN + DN from Identity Profile attributes directly to AD without an issue.
Can you try to do the exact same update manually via the service-account in LDAP?
Hi Sebastian,
Yes, agreed the failure is happening because the RDN itself is changing (UID changes from contractor to employee), which requires a ModifyDN/ModifyRDN operation. The service account does have sufficient permissions for standard modify, create, and delete operations, but from what I can see, SailPoint is attempting a normal Modify on the UID attribute rather than issuing a ModifyDN request, which is where LDAP returns error 67.
I haven’t tried performing the ModifyDN manually yet, using the service account. That’s a good suggestion, and I can validate whether the LDAP server allows it directly(The LDAP team mentioned they use the command line to modify the RDN).
Also, just to clarify, this issue is with an LDAP directory (not AD). I’ve seen CN/DN sync work fine in AD as well, but LDAP seems to behave differently when the RDN attribute changes.
moving the DN and changing CN (or UID) from transform?
Please check this article if you have not already.
@Tarunithamsetty you might need to use a before provisioning rule to achieve the same
If the target LDAP server is except Active Directory like OUD, OPendLDAP, OPenDJ etc, then the generic LDAP connector doesn’t support the operation you are trying to perform.
Note-
uid is the RDN attribute. Most LDAP servers will reject a normal Modify that changes the RDN attribute value, returning LDAP error 67 (LDAP_NOT_ALLOWED_ON_RDN). To change it, the client must perform a ModifyDN/ModifyRDN operation (rename), not a regular Modify.
Reference - IBM Documentation
how can the rule perform that operation?