[midPoint] Problem with auxiliaryObjectClass definition in LDAP Connector on midPoint 4.6

Patrik Sidler patrik.sidler at itconcepts.ch
Wed Nov 30 17:24:34 CET 2022


Hi Pascal,

Thank you for you help.
I have implemented it the way you have explained it and it works for me as well.

Best Regards

Patrik Sidler

Von: midPoint <midpoint-bounces at lists.evolveum.com> Im Auftrag von Pascal PÉRICHON via midPoint
Gesendet: Montag, 28. November 2022 13:28
An: midpoint at lists.evolveum.com
Cc: Pascal PÉRICHON <pascal.perichon at u-paris.fr>
Betreff: Re: [midPoint] Problem with auxiliaryObjectClass definition in LDAP Connector on midPoint 4.6


Hi,

I'm not sure, because it was a long time ago, but (maybe) your problem seems to be familiar...

Some of accounts of one of my LDAP were not symetric, i.e some LDAP accounts didn't use/have all the objectClass that are listed in your midPoint auxiliaryObjectClass.

If the missing objectClass occurs in one LDAP account then midpoint try to access and add the objectClass in the LDAP schema account, even if the concerned LDAP attribute of the objectClass is null (not used) : your error is something like "add:objectClass=ipaSshUser insufficientAccessRights: Insufficient 'write' privilege to the 'objectClass' attribute "...

I solved my problem this way (by taking control on missing attributes/objectClasses and I can access to account with or without missing objectClass in LDAP account schema)  :

<auxiliaryObjectClassMappings>

    <tolerant>true</tolerant>

                <inbound>

                   <!--

                        Remove "<auxiliaryObjectClass>ri:ipaSshUser</auxiliaryObjectClass>" in your declaration.

                        I don't remember exactly but I think if you use "source" on missing LDAP objectClass it's going to explode.

                        Better use groovy code and basic.getAttributeValues(projection, 'attributeIn_ipaSshUser_Class') that send you null.

                       relativityMode helps is LDAP attribute is multi valued.

                        Be careful relativityMode always gives you tabular even if monovalued

                     -->

                    <!--source>

                        <c:path>$c:projection/c:attributes/ipaSshUser</c:path>

                    </source-->

                    <expression>

                        <script>

                            <relativityMode>absolute</relativityMode>

                            <code>

                                myVar = basic.getAttributeValues(projection, 'attributeIn_ipaSshUser_Class')



                                if(!basic.isEmpty(myVar)) {

                                    // bla bla

                                    this.binding.variables.each {k,v -> log.info("-------> {} = {}", k, v)};

                                }

                                // if ipaSshUser is not there

                                return null

                            </code>

                        </script>

                    </expression>

                    <target>

                        <path>$focus/</path>

                    </target>

                </inbound>

</auxiliaryObjectClassMappings>



Hope it's your problem :)

Best regards



-------



Pascal PÉRICHON

Direction des systèmes d'information et du numérique

Université Paris Cité



Le 24/11/2022 à 15:08, Patrik Sidler via midPoint a écrit :
Hi All,

I am having a problem, configuring the auxiliaryObjectClass on my LDAP Connector (Version 3.5) running on midPoint 4.6.


The configuration midPoint 4.4.3 (LDAP Connector) worked perfect:

<objectClass>ri:inetOrgPerson</objectClass>
<auxiliaryObjectClass>ri:ipaObject</auxiliaryObjectClass>
<auxiliaryObjectClass>ri:iamUser</auxiliaryObjectClass>
<auxiliaryObjectClass>ri:inetUser</auxiliaryObjectClass>
<auxiliaryObjectClass>ri:ipaSshUser</auxiliaryObjectClass>
<auxiliaryObjectClass>ri:krbTicketPolicyAux</auxiliaryObjectClass>
<auxiliaryObjectClass>ri:krbPrincipalAux</auxiliaryObjectClass>
<auxiliaryObjectClass>ri:aspectraUser</auxiliaryObjectClass>
<auxiliaryObjectClass>ri:posixAccount</auxiliaryObjectClass>
<auxiliaryObjectClass>ri:ipaNTUserAttrs</auxiliaryObjectClass>
<auxiliaryObjectClassMappings>
    <tolerant>true</tolerant>
</auxiliaryObjectClassMappings>


With midPoint 4.6 and LDAP Connector 3.5, the configuration looks the following:

<objectType id="4">

    <kind>account</kind>

    <intent>ldapAccount</intent>

    <displayName>LDAP Account</displayName>

    <default>true</default>

    <delineation>

        <objectClass>ri:inetOrgPerson</objectClass>

        <auxiliaryObjectClass>ri:ipaObject</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:iamUser</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:inetUser</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:ipaSshUser</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:krbTicketPolicyAux</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:krbPrincipalAux</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:aspectraUser</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:posixAccount</auxiliaryObjectClass>

        <auxiliaryObjectClass>ri:ipaNTUserAttrs</auxiliaryObjectClass>

    </delineation>

But I am not able to set the auxiliaryObjectClassMappings to tolerant. I also found no description/example to do this with the new Wizard thing…

Anyone an Idea how to solve this problem?

Thank you in advance for your help.

Best regards
Patrik




_______________________________________________

midPoint mailing list

midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>

https://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20221130/a49432a7/attachment-0001.htm>


More information about the midPoint mailing list