On 04/01/2017 15:32, PSYND wrote:
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.
Good news, then: the ConnId Active Directory connector in fact fully
supports SYNC [5].
Regards.
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 <https://syncope.apache.org/docs/reference-guide.html#pull-mode>],
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
<https://connid.atlassian.net/wiki/display/BASE/LDAP#LDAP-SupportedOperations>].
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
<https://syncope.apache.org/docs/reference-guide.html#provisioning-pull>]
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
[5]
https://connid.atlassian.net/wiki/pages/viewpage.action?pageId=360482#ActiveDirectory(JNDI)-SupportedOperations
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
