HI guys, You are probably both right because you are both power users (and even more!) and you should be able to use it without any trouble.
But in fact LSC is covering the specs precised at the following location at the bottom of the page : http://lsc-project.org/wiki/documentation/2.0/configuration/syncoptions If your source has values and you don't enforce through forceValues explicitely, the source values are simply reproduced. If your source does not provide any value then : - if the entry is created, the createValues will be used if they are specified - otherwise the defaultValues will be used So : - Clement: you are look to enforce values without any respect to the source values, so use a FORCE policy with forceValues. - Maxime: your use case is quite particular because you are trying to synchronize a value that you cannot read so the strategy you've found will always be the good one : using a create value. With a database as a source service, you may have completed the same resolution without renaming the column but simply by using alias: SELECT userpassword AS motDePasse FROM ... (what you may have done :) Now you know that most of the synchronization is designed to use the simple "identity" mapping (same values in source and destination), I'm really interested in all ideas to simplify and make it more understandable. Kind regards, -- Sebastien BAHLOUL IAM / Security specialist Ldap Synchronization Connector : http://lsc-project.org Blog : http://sbahloul.wordpress.com/ 2012/4/17 Maxime Pelletier <[email protected]> > Clément OUDOT <[email protected]> a écrit : > > > > Hi, > > > > another test today: I have an asyncLdapSourceService, and I want to > > force the objectClass values on entry creation, but keep existing > > values for existing entries. > > > > So I have this dataset: > > > > <dataset> > > <name>objectclass</name> > > <policy>KEEP</policy> > > <createValues> > > <string>"inetOrgPerson"</string> > > <string>"organizationalPerson"</string> > > <string>"person"</string> > > <string>"top"</string> > > </createValues> > > </dataset> > > > > > > When synchronizing, I have an error because the created objectClass > > values are the values from the source entry. Of course, source entry > > object classes are not compatible with destination object classes > > (imagine OpenLDAP and AD synchronization) > > > > I searched the reason: in async mode, the list of fetched attributes > > is ignored, all source attributes are fetched, including the > > objectclass attribute. And despite the dataset configuration of > > objectclass, the source objectclass is used. > > > > By replacing asyncLdapSourceService by ldapSourceService, it works. I > > confirm that objectclass is present in destination fetched attributes > > and not in source fetched attributes. > > > > > > What do you think, should I open an issue? > > > > > > Clément. > > _______________________________________________________________ > > Ldap Synchronization Connector (LSC) - http://lsc-project.org > > > > lsc-users mailing list > > [email protected] > > http://lists.lsc-project.org/listinfo/lsc-users > > > Hi, > > I do think that this should be changed. > > First of all, it's kind of a trap. It is not a trivial behavior. When you > specify some setting in lsc.xml you would normally expect that it will be > used. > > Second, let me share another case where it cause a problem. > > I synchronize a MySQL DB with a Novell eDirectory. The attribute > "userPassword" is special in eDirectory because it is "write-only". When I > run my task, LSC can't read the attribute (as if the attribute doesn't > exist at all), so it tries to create it with the value named "userPassword" > in the source DB. However, the value already exist in eDirectory but it > isn't exposed. As a result, LSC reset the password with a initial password > each time I run the task :( > > As a workaround, I had to rename the attribute in the source DB to > "motDePasse", and then assign it to the "createValue" of the "userPassword" > attribute. > > So in short, I think that the definition in lsc.xml should always override > any other rule/definition. > > Regards > > P.S.: Keep on the good work Sébastien and Clément! > > _______________________________________________________________ > 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
