Wrongful add of source's multivalued attributes values with a MERGE policy

[yeri60]

Testing a sync between LDAPs where uniqueMember (multivalued) is involved. A Dataset is set for it with the following settings:

       <dataset>
            <name>uniqueMember</name>
            <policy>MERGE</policy>
            <forceValues></forceValues>
       </dataset>

When running the Task I get the following error on some entries :

Aug 29 16:35:37 - ERROR - Error while modifying entry xyz=00001NIL,ou=rtzgroups,ou=sdf,ou=Applications,dc=exemple,dc=com in directory :javax.naming.directory.AttributeInUseException: [LDAP: error code 20 - Attribute Or value Exists]; remaining name 'xyz=00001NIL,ou=rtzgroups,ou=sdf,ou=Applications'
Aug 29 16:35:37 - ERROR - Error while synchronizing ID xyz=00001NIL,ou=rtzgroups,ou=sdf,ou=Applications,dc=exemple,dc=com: java.lang.Exception: Technical problem while applying modifications to the destination
# Wed Aug 29 16:35:37 MEST 2018
dn: xyz=00001NIL,ou=rtzgroups,ou=sdf,ou=Applications,dc=exemple,dc=com
changetype: modify
add: uniqueMember
uniqueMember: xyz=0000188W,ou=People,dc=exemple,dc=com
-

This error seems to occur when there is only one and the same uniqueMember value on either the source and the destination LDAP. [LDAP: error code 20 - Attribute Or value Exists] is a correct response of the dst Directory Server in this context. Should not LSC detect that there is no need to execute an ‘add:’ operation in this case ? When there are many (more than 1?) uniquemember, the MERGE policy adds only the new members and not the members already existing in the destination.

[coudot]

Could you verify that the value of the member is exactly the same in source and destination (check spaces for example) ?

[yeri60]

Hi,

‘xyz=0000188W,ou=People,dc=pictet,dc=com’ (source) ‘xyz=0000188W,ou=people,dc=pictet,dc=com’ (destination)

people vs People, LSC should treat dn as case incensitive, isn’t it ?

[coudot]

An issue is opened about this: #54

Could you see if the issue you have is linked to that, or if this is a different issue?

[yeri60]

#54 concerns characters sensitivity, #70 seems to have a similar issue. To have an insensitive comparison on LSC between source and destination should be an option. Not all LDAP implementation behave similarly but most I guess are case insensitive.