I will try that, but I think that LSC could be more resilient to such “erroneous” scripts which would make it easier for users. Otherwise you should be much more explicit about the requirements of the javascript statements in the respective configuration parts. Otherwise there will be many other people asking the same questions in the future, because how am I supposed to know that I cannot simply use replace() on getMainIdentifier() or that I can only use it in certain situations.
Also, as I said in my previous mail, what if its not just cn=Surname\\, Lastname,ou=Org,c=de but cn=Surname\, Lastname,ou=Shipping\+Handling,c=de or even more complex cases where I cannot just use getDatasetFirstValueById() with string addition to create the main identifier? I’ll get back to you tomorrow. Marian > On 17. Dec 2014, at 17:25, Raphaël Ouazana-Sustowski > <[email protected]> wrote: > > In fact LSC should already handle this case, and there should never be a > '\\,' value. I think this value is due to your erroneous script, not to LSC > way of handling DN. > Of course there were some bugs in LSC way of handling DN, so if you still > have the case with the fixed script, please submit it. > > Regards, > Raphaël Ouazana. > > Le 2014-12-17 16:49, Marian Harbach a écrit : >> 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 -- Marian Harbach Research Associate Distributed Computing and Security Group Leibniz Universität Hannover Schloßwender Str. 5, 30159 Hannover, Germany Tel. +49 (0) 511 762 79 9038
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
