Dear Francesco, thank you for your support, we've been actually able to update users using the AD connector instead of the generic LDAP one.
Thanks On 2017-01-04 08:33, Francesco Chicchiriccò wrote: > On 03/01/2017 19:39, PSYND wrote: > >> Dear Experts, >> >> we connected our Syncope to an OpenLDAP. >> >> We are able to create users from OpenLDAP to Syncope, and we are able to >> list them from the dashboard. >> >> We update the user in the LDAP, we check using the Explore Resource and we >> can correctly display the change we made. > > That's good to hear. > >> So we run the change as Incremental, but the logs say: >> >> JobExecutionException: While pulling from connector >> org.quartz.JobExecutionException: While pulling from connector [See nested >> exception: >> org.identityconnectors.framework.common.exceptions.ConnectorException: >> Unable to locate the replication change log. >> From the admin console please verify that the change log is enabled under >> Configuration: Replication: Supplier Settings and that the Retro Change Log >> Plugin is enabled under Configuration: Plug-ins: Retro Change Log Plugin] >> at >> org.apache.syncope.core.provisioning.java.pushpull.PullJobDelegate.doExecuteProvisioning(PullJobDelegate.java:284) >> at >> org.apache.syncope.core.provisioning.java.pushpull.PullJobDelegate.doExecuteProvisioning(PullJobDelegate.java:60) >> at >> org.apache.syncope.core.provisioning.java.pushpull.AbstractProvisioningJobDelegate.doExecute(AbstractProvisioningJobDelegate.java:558) > > As I was saying recently [1], and as reported by the reference guide > [2 [1]], the incremental pull mode requires the SYNC operation to be > implemented on the related connector bundle, and the LDAP connector > bundle implements that "only with Sun / Oracle DSEE, RedHat 389 and > OpenDS / OpenDJ" [3 [2]]. > If you are using other implementations, say OpenLDAP, only full and > filtered pull modes are effective. > >> If we try this time with a Full Reconciliation, the event will be SUCCESS, >> but the log will display: >> >> Users [created/failures]: 0/0 [updated/failures]: 0/0 [deleted/failures]: >> 0/0 [no operation/ignored]: 1/0 >> >> Users no operation: >> NONE SUCCESS (key/name): acff92f7-00f9-4f9a-bf92-f700f9ff9a34/cros >> >> Any idea? > > The execution of the full reconciliation is SUCCESS because it > succeeded without breaking errors. > > The result summary above states that the pull task execution has found > a single user, and that the internal logic decided to not perform any > operation on it. This happens, for example, when you have set the > unmatching rule [4 [3]] to IGNORE on the pull task. > > HTH > Regards. > > [1] > https://lists.apache.org/thread.html/19ff0c439a68eebac36be2c19a3cf2d9e4bf5aab6a32fcd5aa356e5d@%3Cuser.syncope.apache.org%3E > [2] https://syncope.apache.org/docs/reference-guide.html#pull-mode > [3] > https://connid.atlassian.net/wiki/display/BASE/LDAP#LDAP-SupportedOperations > [4] https://syncope.apache.org/docs/reference-guide.html#provisioning-pull Links: ------ [1] https://syncope.apache.org/docs/reference-guide.html#pull-mode [2] https://connid.atlassian.net/wiki/display/BASE/LDAP#LDAP-SupportedOperations [3] https://syncope.apache.org/docs/reference-guide.html#provisioning-pull
