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
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
