Value splitting of CN with escaped character matching defaultDelimiter

[cyrilstoll]

Issue detected when syncing groups from AD to OpenLDAP when group names contain special characters. In order to sync the javax.naming.ldap.Rdn.escapeValue function is used.

excerpt from lsc.xml

<propertiesBasedSyncOptions><mainIdentifier>js:"cn=" + javax.naming.ldap.Rdn.escapeValue(srcBean.getDatasetFirstValueById("cn")) + ",ou=Groups,ou=Something,dc=domain,dc=tld"</mainIdentifier>
<defaultDelimiter>;</defaultDelimiter>

Dry-run output producing two cn if group name contains a semicolon

dn: cn=.Country.Area.Research;Development,ou=Groups,ou=Something,dc=domain,dc=tld
changetype: add
member: uid=somename1,ou=People,ou=Something,dc=domain,dc=tld
member: uid=somename2,ou=People,ou=Something,dc=domain,dc=tld
cn: .Country.Area.Research
cn: Development
objectclass: groupOfNames

It looks like the issue is the default delimiter. If I change the defaultDelimiter to a "?" (which is not used in any group name, at least not yet) then the dry-run output looks fine. However since the semicolon in the group name is escaped in AD this is unexpected behaviour.

[coudot]

However since the semicolon in the group name is escaped in AD this is unexpected behaviour.
I don't understand the problem. Does it work if you change the default delimiter?

[cyrilstoll]

Sorry for the late reply, Github did not inform me about the question from @coudot.

Yes, I did change the default delimiter to a question mark instead of a semicolon and since then it works without issues. That is my current workaround suggested by Soisik Froger on the mailinglist (https://mail.ow2.org/wws/arc/lsc-users/2023-11/msg00003.html).

We currently don't have a group with a question mark in the name. However if we had such a group and kept using the question mark as default delimiter then I expect it would have the same issue.

In other words it looks like whatever is used as default delimiter must not be used as a character in a group name, even if that character is escaped in the group name.

[coudot]

Not so easy, but you can configure the delimiter only for the cn dataset. Could you try to set it to empty value?

        <dataset>
          <name>cn</name>
          <policy>FORCE</policy>
          <forceValues>
            <string>srcBean.getDatasetFirstValueById("cn")</string>
          </forceValues>
          <delimiter></delimiter>
        </dataset>

[cyrilstoll]

Just tried that now but unfortunately not using any delimiter does not solve the problem. It actually looks worse. The output I got of a dry run when using no delimiter is:

# Tue Jan 30 18:30:43 CET 2024
dn: cn=.Country.Area.frb2311&amp\;&amp\;Test,ou=Groups,ou=Something,dc=domain,dc=tld
changetype: modify
replace: cn
cn: .Country.Area.frb2311&amp
cn: &amp
cn: Test

Beware this is not the same group as in my original post, it is just the one that showed issues when testing. The group from my original post here has probably been deleted by now.

[coudot]

Ok, in this case the solution is indeed to set a delimiter which is never used in cn values, but you don't have to set it as default delimiter, you can just configure it for the cn dataset

[cyrilstoll]

Ok, thanks for the info. I will check that out. However I don't expect anyone in our company to use a question mark in a group name (though, you never know). That is to say this is a viable workaround for me and not the reason for opening this post. Actually I only opened it because Soisik Froger asked me to create a bug report in the mailing list message I linked above. Feel free to close this post if you don't see a need to change LSCs behaviour in this regard.