Both objectSID and objectGUID must be unique for every object in AD. I personally use objectSID as it can be deconstructed into data that has relevance to other objects in AD. For example the objectSID of a group can be used to related a user to their "primaryGroup".
-Jon C. Kidder American Electric Power Middleware Services Email: [email protected]<mailto:[email protected]> Phone: 614-716-4970 From: [email protected] [mailto:[email protected]] On Behalf Of Clément OUDOT Sent: Friday, November 29, 2013 8:53 AM To: Matteo Perego Cc: lsc-userslsc-users Subject: Re: [lsc-users] AD single OU sync / DN mangling This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. ________________________________ 2013/11/29 Matteo Perego <[email protected]<mailto:[email protected]>> Il 29/11/2013 11:39, Clément OUDOT ha scritto: Hi Clement, with that rule and a getOneFilter like this: <getOneFilter>(distinguishedName={distinguishedName})</getOneFilter> I didn't get results on the destination AD cause {distinguishedName} seems to be resolved on the SRC main identifier and not the DST one. Without results LSC try to create an already existing entry. I cannot use other attributes (like {cn}) cause they're not unique. You should use sAMAccountName as pivot, as they should be unique. Clément. Hi Clement, unfortunately contacts doesn't have a samaccountname. I wonder if I can set the ldap search to be "one level" and not "sub" type as workaround... No, you can't change the scope of the search. I think AD should have a technical attribute storing a unique ID. If anyone has an idea? Clément.
_______________________________________________________________ Ldap Synchronization Connector (LSC) - http://lsc-project.org lsc-users mailing list [email protected] http://lists.lsc-project.org/listinfo/lsc-users
