When updating an entry, the LDAP connector checks whether it is necessary to do a MODIFYDN. It compares existing entry DN and new entry DN, but it does escapeDNValueofJNDIReservedChars on the existing entry DN only, not the new entry DN.
=> If the DN contains a character like a slash '/', this results in the escaped and non-escaped DNs appearing to be different, and thus a wrong MODIFYDN op.
Reproduced on IDM 6.0.0 and 7.0.0 (nightly snapshot).
1. Set up LDAP provisioner to DS 6.0.0.
2. Set up mapping from managed user -> LDAP, with a userName -> DN mapping transform that escapes any '/' character in the DN.
The scripted condition applies the mapping if it is an existing object, and the object.userName does not match the oldTarget.uid:
3. By default, managed.json disallows '/' in userName:
Remove this section.
4. On IDM, create a managed user with userName "abc/test1".
5. On IDM, update the managed user, e.g. modify the user's "description".
DS access log shows MODIFYDN:
Looking at this in a debugger:
- the '/' in the existing entryDN is escaped ("uid=abc\2ftest1,...") because escapeDNValueOfJNDIReservedChars is used.
- but the new entryDN is not escaped ("uid=abc/test1,...").
- so the LDAP connector compares the existing and new entryDN, finds that they are different, and hence does a MODIFYDN.