Hi, thanks for your answer. While this may be true (I'd have to check if the value is really escaped differently in the cb attribute), this solution will not help if there are escaped values in other RDNs of the DN (we don't know how many RDNs and which there are in our DNs).
Marian > Am 17.12.2014 um 16:27 schrieb Raphaël Ouazana-Sustowski > <[email protected]>: > > Hi, > > Le 2014-12-12 23:54, Benjamin Henne a écrit : >> Hi, >> we have tried to implement what you mention in your link. However, the >> problems seems to persist. Here's the new mainIdentifier construction: >> <mainIdentifier>var pos = srcBean.getMainIdentifier().indexOf(",OU="); >> var cn = >> srcBean.getMainIdentifier().substring(0,pos).split("=")[1]; > > I think your issue is here. Instead of trying to guess cn value based on DN, > you should take cn from source: > var cn = srcBean.getDatasetFirstValueById("cn") > >> var restDN = >> srcBean.getMainIdentifier().substring(pos); >> restDN = restDN.replace(",DC=de",",c=de"); >> var res = >> "cn="+javax.naming.ldap.Rdn.escapeValue(cn)+restDN; >> res</mainIdentifier> > > Then the escaping would be fine here. > >> The first sync works fine. But when starting the second the error that >> occurs is as follows: >> Dez 12 13:37:39 - ERROR - Error while synchronizing ID cn=Lastname\\, >> Firstname,ou=Benutzer,c=de: java.lang.RuntimeException: >> org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: >> expecting EQUALS, found ',' >> # Fri Dec 12 13:37:39 CET 2014 >> dn: cn=Lastname\\, Firstname,ou=Benutzer,c=de >> changetype: modrdn >> newrdn: cn=Lastname\, Firstname >> deleteoldrdn: 1 >> newsuperior: OU=Benutzer,c=de >> So LSC continues to stack the escapes. When I look at the debugger for >> the above statement, the "res" variable contains the correct string >> every time (both first and consecutive syncs). However, during the >> second sync, the dstBean variable contains exactly this double-escaped >> version that is also seen in the above error message. Thus, I think >> the problem is not in the construction of the MainIdentifier of the >> srcBean, but in reading the main identifier of the dstBean from >> OpenLDAP (which is not configurable as far as I understand it). As I >> wrote in my first post, AD and OpenLDAP seem to encode this >> differently and therefore LSC finds a DN mismatch. Any help is greatly >> appreciated. > > I think the double escaping is due to your script, not to LSC. > > Regards, > Raphaël Ouazana. > _______________________________________________________________ > Ldap Synchronization Connector (LSC) - http://lsc-project.org > > lsc-users mailing list > [email protected] > http://lists.lsc-project.org/listinfo/lsc-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________________________ Ldap Synchronization Connector (LSC) - http://lsc-project.org lsc-users mailing list [email protected] http://lists.lsc-project.org/listinfo/lsc-users
