[midPoint] reconcile failed adding auxiliary objectclasses

[Andrew Morgan]

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