<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
Those "result handlers" are an artifact of an original Identity
Connector Framework over-engineering. The handlers are supposed to
assist connectors by implementing "mechanism" that the connector
or resource does not support - such as search result filtering,
data normalization and so on. However, those handler are generic
and they know nothing about the particulars of the resource that
the connector connects to. Therefore in vast majority of cases
those handlers just get into the way and they distort the data.
Good connectors usually do not need those handlers at all.
Unfortunately, these handler are enabled by default and there is
no way for a connector to tell the framework to turn them off. The
handlers needs to be explicitly disabled in the resource
configuration.<br>
<br>
I strongly recommend to disable all three handlers when working
with LDAP or AD/LDAP resoruces.<br>
<br>
I figured that this issue is not documented well. Therefore I have
updated the documentation.<br>
<br>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com
</pre>
<br>
<br>
On 06/21/2018 12:58 AM, Andrew Morgan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.DEB.2.11.1806201552040.7017@shell.onid.oregonstate.edu">I
was able to resolve this issue.
<br>
<br>
My LDAP schema had multiple objectclasses defined as structural.
I kept inetOrgPerson as structural (of course), and I changed our
locally-defined objectclasses to be auxiliary.
<br>
<br>
I still was having trouble with the reconcile after this, so I
looked more closely at the working OpenLDAP resource configuration
from another university. I discovered that I was missing some
configuration. I had:
<br>
<br>
<icfs:resultsHandlerConfiguration>
<br>
<icfs:enableFilteredResultsHandler>false</icfs:enableFilteredResultsHandler><br>
</icfs:resultsHandlerConfiguration>
<br>
<br>
I added the other 2 results handlers (disabled):
<br>
<br>
<icfs:resultsHandlerConfiguration>
<br>
<icfs:enableNormalizingResultsHandler>false</icfs:enableNormalizingResultsHandler><br>
<icfs:enableFilteredResultsHandler>false</icfs:enableFilteredResultsHandler><br>
<icfs:enableAttributesToGetSearchResultsHandler>false</icfs:enableAttributesToGetSearchResultsHandler><br>
</icfs:resultsHandlerConfiguration>
<br>
<br>
It appears that the AttributesToGetSearchResultsHandler must be
disabled for this to work.
<br>
<br>
I copied my original configuration from the example here:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/Evolveum/midpoint/blob/master/samples/resources/dsee/odsee-localhost-advanced-sync.xml">https://github.com/Evolveum/midpoint/blob/master/samples/resources/dsee/odsee-localhost-advanced-sync.xml</a><br>
<br>
Could someone update that to include the other 2 results handlers
(disabled)?
<br>
<br>
Thanks,
<br>
<br>
Andy Morgan
<br>
Systems Administrator, Identity & Access Management
<br>
Information Services | Oregon State University
<br>
541-737-8877 | is.oregonstate.edu
<br>
<br>
On Thu, 31 May 2018, Radovan Semancik wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
<br>
MidPoint usually supports auxiliary object classes well.
Usually. But there are many LDAP servers and all of them have
their specific glitches and quirks.
<br>
<br>
I would say that there are several possibilities:
<br>
1. midPoint does not see the entry completely and does not know
that the entry already has the object classes
<br>
2. your LDAP server has a bad schema (quite a common problem)
and therefore LDAP connector does not properly detect auxiliary
object classes
<br>
3. there is something really wrong with your midpoint
configuration
<br>
4. you have found a bug
<br>
5. something else entirely :-)
<br>
<br>
I would suggest to start with our connector troubleshooting
guide here:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://wiki.evolveum.com/display/midPoint/Troubleshooting+Connectors">https://wiki.evolveum.com/display/midPoint/Troubleshooting+Connectors</a>
<br>
<br>
here are also some LDAP-specific hints:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://wiki.evolveum.com/display/midPoint/LDAP+Connector+Troubleshooting">https://wiki.evolveum.com/display/midPoint/LDAP+Connector+Troubleshooting</a>
<br>
<br>
... which should help you to diagnose whether this is a problem
of LDAP server, LDAP connector or midPoint. In case that the
problem is in midPoint, there is another guide to follow:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://wiki.evolveum.com/display/midPoint/Troubleshooting+Mappings">https://wiki.evolveum.com/display/midPoint/Troubleshooting+Mappings</a>
<br>
<br>
-- <br>
Radovan Semancik
<br>
Software Architect
<br>
evolveum.com
<br>
<br>
<br>
<br>
<br>
On 05/31/2018 01:25 AM, Andrew Morgan wrote:
<br>
<blockquote type="cite">I have an existing user entry in LDAP
(created by midPoint). When I perform reconciliation on the
midPoint user, I get an LDAP error:
<br>
<br>
2018-05-30 15:21:03,241 [] [pool-6-thread-3] ERROR
(com.evolveum.midpoint.provisioning.ucf.impl.connid.ConnIdUtil):
ConnId Exception
org.identityconnectors.framework.common.exceptions.InvalidAttributeValueException
in connector:2550dac9-8c37-49b6-809e-1895204baa21(ConnId
com.evolveum.polygon.connector.ldap.LdapConnector
v1.5.1-osu1):
ConnectorSpec(<a class="moz-txt-link-freetext" href="resource:ef2bc95b-76e0-48e2-86d6-3d4f02d3e1aa(ONID">resource:ef2bc95b-76e0-48e2-86d6-3d4f02d3e1aa(ONID</a>
LDAP DEV), name=null,
oid=2550dac9-8c37-49b6-809e-1895204baa21) while adding
attribute values to object identified by ConnId UID
'c4130201-5ee211e8-80d383a7-05078e7e': Error modifying LDAP
entry osuuid=78013514100,ou=people,o=midpointdev:
[add:objectClass: eduPerson
<br>
objectClass: shadowAccount
<br>
objectClass: inetOrgPerson
<br>
objectClass: account
<br>
objectClass: lpSghePerson,]: attributeOrValueExists: (20)
<br>
org.identityconnectors.framework.common.exceptions.InvalidAttributeValueException:
Error modifying LDAP entry
osuuid=78013514100,ou=people,o=midpointdev: [add:objectClass:
eduPerson
<br>
objectClass: shadowAccount
<br>
objectClass: inetOrgPerson
<br>
objectClass: account
<br>
objectClass: lpSghePerson,]: attributeOrValueExists: (20)
<br>
<br>
<br>
These 5 objectclasses already exist on the LDAP entry, as you
can see from this log entry earlier in the reconciliation
process:
<br>
<br>
2018-05-30 15:20:55,758 [] [pool-6-thread-3] DEBUG
(com.evolveum.polygon.connector.ldap.OperationLog): method:
null msg:<a class="moz-txt-link-freetext" href="ldaps://ldap.onid.orst.edu/">ldaps://ldap.onid.orst.edu/</a> Search RES Entry
<br>
dn: osuuid=78013514100,ou=people,o=midpointdev
<br>
objectClass: osuPerson
<br>
objectClass: account
<br>
objectClass: shadowAccount
<br>
objectClass: eduPerson
<br>
objectClass: lpSghePerson
<br>
objectClass: inetOrgPerson
<br>
objectClass: top
<br>
objectClass: organizationalPerson
<br>
objectClass: person
<br>
uid: morgan
<br>
osuPrimaryAffiliation: E
<br>
osuPIDM: <redacted>
<br>
givenName: Andrew
<br>
osuUID: 78013514100
<br>
sn: Morgan
<br>
cn: Morgan, Andrew Jason
<br>
osuID: <redacted>
<br>
nsUniqueId: c4130201-5ee211e8-80d383a7-05078e7e
<br>
<br>
<br>
The 5 objectclasses it is complaining about are the 5
auxiliary objectclassed defined in my resource:
<br>
<br>
<objectClass>ri:osuPerson</objectClass>
<auxiliaryObjectClass>ri:inetOrgPerson</auxiliaryObjectClass><br>
<auxiliaryObjectClass>ri:account</auxiliaryObjectClass>
<br>
<auxiliaryObjectClass>ri:shadowAccount</auxiliaryObjectClass>
<br>
<auxiliaryObjectClass>ri:lpSghePerson</auxiliaryObjectClass>
<br>
<auxiliaryObjectClass>ri:eduPerson</auxiliaryObjectClass>
<br>
<br>
<br>
Why does midPoint think it needs to add these auxiliary
objectclasses to the LDAP entry?
<br>
<br>
Thanks,
<br>
<br>
Andy Morgan
<br>
Systems Administrator, Identity & Access Management
<br>
Information Services | Oregon State University
<br>
541-737-8877 | is.oregonstate.edu
<br>
_______________________________________________
<br>
midPoint mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
midPoint mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
</blockquote>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>