Uploaded image for project: 'OpenICF'
  1. OpenICF
  2. OPENICF-1161

LDAP connector: inconsistency in escaping special chars when comparing new DN with existing entry DN (when updating entry), results in MODIFYDN



      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).


      TEST CASE:
      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:

       "target" : "dn",
       "source" : "userName",
       "transform" : {
       "type" : "text/javascript",
       "source" : "('uid=' + source + ',ou=people,dc=example,dc=com').replace(/\\//g,\"\\\\2f\");"
       "condition" : {
       "type" : "text/javascript",
       "source" : "if (oldTarget) { oldTarget.uid != object.userName;} else {true};"

      3. By default, managed.json disallows '/' in userName:

       "policyId" : "cannot-contain-characters",
       "params" : {
       "forbiddenChars" : [

      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:

      [03/Sep/2019:11:06:45 +0800] MODIFYDN REQ conn=33 op=19 msgID=20 dn="uid=abc/test1,ou=people,dc=example,dc=com" newRDN="uid=abc" deleteOldRDN="true"
      [03/Sep/2019:11:06:45 +0800] MODIFYDN RES conn=33 op=19 msgID=20 result=0 etime=1

      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.


          Issue Links



              • Assignee:
                gael Gael Allioux
                wei-yee.lum Wei-Yee Lum
                QA Assignee:
                Son Nguyen
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: