Hi Dunkan, Yes you are completely right, that's why you can customize it. Look at the following page :
http://lsc-project.org/wiki/documentation/2.0/configuration/service/sourceldap and set the "*dateFormat" value to the following setting (not tested) :* * * *yyyyMMddHHmmss.S'Z * The pattern to use is documented in standard Java documentation for SimpleDateFormat class: http://docs.oracle.com/javase/1.4.2/docs/api/java/text/SimpleDateFormat.html Regards, -- Sebastien BAHLOUL IAM / Security specialist Ldap Synchronization Connector : http://lsc-project.org Blog : http://sbahloul.wordpress.com/ 2012/8/7 dunkan <[email protected]> > Sorry to be spammy. From looking at tcpdumps I see it is checking the > modifytimestamp. It looks like the problem is the value is stored with a > decimal in the directory, but not in the filter. > > For example, it is looking for "(modifytimestamp>=20110807030345Z)", and > never gets any results. If I change that > to "(modifytimestamp>=20110807030345.0Z)" it returns the entries that are > modified. > > Thanks, > Joel > > > On Mon, Aug 6, 2012 at 9:00 PM, dunkan <[email protected]> wrote: > >> It looks like FORCE, with forcevalues will always put what I need, so >> that part is working out now. >> >> I'm not sure about the async job though. How does it determine that it >> needs to update? The logs give the indication that it is searching every 5 >> seconds, but changes don't show up. If I stop and re-run it again they are >> always picked up. >> >> -Joel >> >> >> On Mon, Aug 6, 2012 at 7:02 PM, dunkan <[email protected]> wrote: >> >>> Hey there, >>> >>> I am working on one way syncing AD to OpenLDAP. I am seeing a difference >>> in operation between using lsc in async vs sync mode. >>> >>> If I start lsc like so: >>> >>> # bin/lsc -f etc -a all >>> >>> users are read from active directory using my filter correctly, and >>> attributes are updated as I would expect. >>> >>> If I start lsc in async like so: >>> >>> # bin/lsc -f etc -s all >>> >>> lsc attempts to create users every time, and I will get a failure to add >>> as the entry already exists. >>> >>> From what I have read this sort of behavior shouldn't change using sync >>> vs async, is that correct? >>> It seems like an easy work around for now is to just use async and >>> trigger an event. >>> >>> >>> My second issue I believe is configuration. I have been using >>> http://lsc-project.org/wiki/documentation/2.0/configuration/syncoptions as >>> my guide for this. >>> >>> AD has a different objectclass than OpenLDAP. >>> >>> So in AD the objectClass will be OrgainzationalPerson, person >>> In OpenLDAP it is Account, PossixAccount. >>> >>> I want the values in OpenLDAP to always be the OpenLDAP values, leave >>> existing entries alone, and create new users with those values. >>> >>> I thought the way to do this would be to set policy to FORCE and >>> defaultvalues to my requested values. >>> This creates a new user ok, but existing users get trampled. >>> >>> If I set it to KEEP and defaultvalues to the requested values, existing >>> users don't get messed with, but new users use the AD objectclass. >>> >>> I tried using forcevalues and createvalues with KEEP/FORCE as well, but >>> am not having any luck getting the behavior I am looking for. >>> >>> Any tips? >>> >>> Thanks, >>> Joel >>> >>> >>> >> > > _______________________________________________________________ > 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
