[midPoint] reconcile failed adding auxiliary objectclasses
Radovan Semancik
radovan.semancik at evolveum.com
Thu Jun 21 09:05:34 CEST 2018
Hi,
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.
I strongly recommend to disable all three handlers when working with
LDAP or AD/LDAP resoruces.
I figured that this issue is not documented well. Therefore I have
updated the documentation.
--
Radovan Semancik
Software Architect
evolveum.com
On 06/21/2018 12:58 AM, Andrew Morgan wrote:
> I was able to resolve this issue.
>
> 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.
>
> 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:
>
> <icfs:resultsHandlerConfiguration>
> <icfs:enableFilteredResultsHandler>false</icfs:enableFilteredResultsHandler>
> </icfs:resultsHandlerConfiguration>
>
> I added the other 2 results handlers (disabled):
>
> <icfs:resultsHandlerConfiguration>
> <icfs:enableNormalizingResultsHandler>false</icfs:enableNormalizingResultsHandler>
> <icfs:enableFilteredResultsHandler>false</icfs:enableFilteredResultsHandler>
> <icfs:enableAttributesToGetSearchResultsHandler>false</icfs:enableAttributesToGetSearchResultsHandler>
> </icfs:resultsHandlerConfiguration>
>
> It appears that the AttributesToGetSearchResultsHandler must be
> disabled for this to work.
>
> I copied my original configuration from the example here:
>
> https://github.com/Evolveum/midpoint/blob/master/samples/resources/dsee/odsee-localhost-advanced-sync.xml
>
> Could someone update that to include the other 2 results handlers
> (disabled)?
>
> Thanks,
>
> Andy Morgan
> Systems Administrator, Identity & Access Management
> Information Services | Oregon State University
> 541-737-8877 | is.oregonstate.edu
>
> On Thu, 31 May 2018, Radovan Semancik wrote:
>
>> Hi,
>>
>> MidPoint usually supports auxiliary object classes well. Usually. But
>> there are many LDAP servers and all of them have their specific
>> glitches and quirks.
>>
>> I would say that there are several possibilities:
>> 1. midPoint does not see the entry completely and does not know that
>> the entry already has the object classes
>> 2. your LDAP server has a bad schema (quite a common problem) and
>> therefore LDAP connector does not properly detect auxiliary object
>> classes
>> 3. there is something really wrong with your midpoint configuration
>> 4. you have found a bug
>> 5. something else entirely :-)
>>
>> I would suggest to start with our connector troubleshooting guide here:
>>
>> https://wiki.evolveum.com/display/midPoint/Troubleshooting+Connectors
>>
>> here are also some LDAP-specific hints:
>>
>> https://wiki.evolveum.com/display/midPoint/LDAP+Connector+Troubleshooting
>>
>>
>> ... 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:
>>
>> https://wiki.evolveum.com/display/midPoint/Troubleshooting+Mappings
>>
>> --
>> Radovan Semancik
>> Software Architect
>> evolveum.com
>>
>>
>>
>>
>> On 05/31/2018 01:25 AM, Andrew Morgan wrote:
>>> I have an existing user entry in LDAP (created by midPoint). When I
>>> perform reconciliation on the midPoint user, I get an LDAP error:
>>>
>>> 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(resource:ef2bc95b-76e0-48e2-86d6-3d4f02d3e1aa(ONID
>>> 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
>>> objectClass: shadowAccount
>>> objectClass: inetOrgPerson
>>> objectClass: account
>>> objectClass: lpSghePerson,]: attributeOrValueExists: (20)
>>> org.identityconnectors.framework.common.exceptions.InvalidAttributeValueException:
>>> Error modifying LDAP entry
>>> osuuid=78013514100,ou=people,o=midpointdev: [add:objectClass: eduPerson
>>> objectClass: shadowAccount
>>> objectClass: inetOrgPerson
>>> objectClass: account
>>> objectClass: lpSghePerson,]: attributeOrValueExists: (20)
>>>
>>>
>>> These 5 objectclasses already exist on the LDAP entry, as you can
>>> see from this log entry earlier in the reconciliation process:
>>>
>>> 2018-05-30 15:20:55,758 [] [pool-6-thread-3] DEBUG
>>> (com.evolveum.polygon.connector.ldap.OperationLog): method: null
>>> msg:ldaps://ldap.onid.orst.edu/ Search RES Entry
>>> dn: osuuid=78013514100,ou=people,o=midpointdev
>>> objectClass: osuPerson
>>> objectClass: account
>>> objectClass: shadowAccount
>>> objectClass: eduPerson
>>> objectClass: lpSghePerson
>>> objectClass: inetOrgPerson
>>> objectClass: top
>>> objectClass: organizationalPerson
>>> objectClass: person
>>> uid: morgan
>>> osuPrimaryAffiliation: E
>>> osuPIDM: <redacted>
>>> givenName: Andrew
>>> osuUID: 78013514100
>>> sn: Morgan
>>> cn: Morgan, Andrew Jason
>>> osuID: <redacted>
>>> nsUniqueId: c4130201-5ee211e8-80d383a7-05078e7e
>>>
>>>
>>> The 5 objectclasses it is complaining about are the 5 auxiliary
>>> objectclassed defined in my resource:
>>>
>>> <objectClass>ri:osuPerson</objectClass>
>>> <auxiliaryObjectClass>ri:inetOrgPerson</auxiliaryObjectClass>
>>> <auxiliaryObjectClass>ri:account</auxiliaryObjectClass>
>>> <auxiliaryObjectClass>ri:shadowAccount</auxiliaryObjectClass>
>>> <auxiliaryObjectClass>ri:lpSghePerson</auxiliaryObjectClass>
>>> <auxiliaryObjectClass>ri:eduPerson</auxiliaryObjectClass>
>>>
>>>
>>> Why does midPoint think it needs to add these auxiliary
>>> objectclasses to the LDAP entry?
>>>
>>> Thanks,
>>>
>>> Andy Morgan
>>> Systems Administrator, Identity & Access Management
>>> Information Services | Oregon State University
>>> 541-737-8877 | is.oregonstate.edu
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180621/a5739e66/attachment.htm>
More information about the midPoint
mailing list