<div dir="ltr"><div dir="ltr"><div>@Radovan Semancik<br></div>First off, I would like to excuse myself for that statement. I am sorry and would like to make your product better and not waste your time doing so.<br>It pained me to see the only response I get is on an outdated mail saying that it should work while I keep on hitting a wall that looks like a bug but could be a mis-configuration on my part.<br>As you can see I have started debugging the code base to better understand what is going on. I posted my findings in the hope that someone with a deeper understanding of midPoint would say that this indeed is a bug, a limitation of midPoint or a misconfig on my part.<br>That way I can start writing a test in the midPoint code base and fix the issue. I am very determined to fix this issue.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op ma 27 jan. 2020 om 15:39 schreef <<a href="mailto:midpoint-request@lists.evolveum.com">midpoint-request@lists.evolveum.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send midPoint mailing list submissions to<br>
<a href="mailto:midpoint@lists.evolveum.com" target="_blank">midpoint@lists.evolveum.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:midpoint-request@lists.evolveum.com" target="_blank">midpoint-request@lists.evolveum.com</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:midpoint-owner@lists.evolveum.com" target="_blank">midpoint-owner@lists.evolveum.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of midPoint digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: LDAP role/group inducement (Jan Lievens)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 27 Jan 2020 15:39:33 +0100<br>
From: Jan Lievens <<a href="mailto:jan.lievens@biggerfish.be" target="_blank">jan.lievens@biggerfish.be</a>><br>
To: <a href="mailto:midpoint@lists.evolveum.com" target="_blank">midpoint@lists.evolveum.com</a><br>
Subject: Re: [midPoint] LDAP role/group inducement<br>
Message-ID:<br>
<CALKj1oZ0bRuO-ni6RSyGqCjdAXtZM_RZq=a_h8=<a href="mailto:TDZzXN-4dRA@mail.gmail.com" target="_blank">TDZzXN-4dRA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
@Ivan Noris:<br>
Have you seen<br>
<a href="http://lists.evolveum.com/pipermail/midpoint/2020-January/005887.html" rel="noreferrer" target="_blank">http://lists.evolveum.com/pipermail/midpoint/2020-January/005887.html</a> and<br>
my follow-up messages? This is a simple version version of what we are<br>
trying to do and with your second note fixed (no static schema and usage of<br>
"dn" in stead of "name").<br>
May I also point out that I have seen your first note ("associations should<br>
work flawlessly" response after just a brief scan of the xml files) a few<br>
times on this mailing list, that this is not a constructive attitude and<br>
that I provided brief instructions on how to reproduce my use case in under<br>
5 minutes.<br>
It is in the simple-ldap-group branch of repository<br>
<a href="https://github.com/jalieven/midpoint-docker" rel="noreferrer" target="_blank">https://github.com/jalieven/midpoint-docker</a> that I started from the Unix<br>
Story (<a href="https://wiki.evolveum.com/display/midPoint/Unix+Story+Test" rel="noreferrer" target="_blank">https://wiki.evolveum.com/display/midPoint/Unix+Story+Test</a>) This<br>
makes my point clearer that when removing entitlements from the inbound<br>
PostgreSQL resource, the outbound LDAP resource is not managed correctly<br>
uniqueMember attributes are not cleaned up.<br>
<br>
Kind regards,<br>
Jan<br>
<br>
Op ma 27 jan. 2020 om 15:16 schreef <<a href="mailto:midpoint-request@lists.evolveum.com" target="_blank">midpoint-request@lists.evolveum.com</a>>:<br>
<br>
> Send midPoint mailing list submissions to<br>
> <a href="mailto:midpoint@lists.evolveum.com" target="_blank">midpoint@lists.evolveum.com</a><br>
><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
> <a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
> or, via email, send a message with subject or body 'help' to<br>
> <a href="mailto:midpoint-request@lists.evolveum.com" target="_blank">midpoint-request@lists.evolveum.com</a><br>
><br>
> You can reach the person managing the list at<br>
> <a href="mailto:midpoint-owner@lists.evolveum.com" target="_blank">midpoint-owner@lists.evolveum.com</a><br>
><br>
> When replying, please edit your Subject line so it is more specific<br>
> than "Re: Contents of midPoint digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
> 1. Re: LDAP role/group inducement (Ivan Noris)<br>
> 2. Re: LDAP role/group inducement (Jan Lievens)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
> Message: 1<br>
> Date: Mon, 27 Jan 2020 13:50:57 +0100<br>
> From: Ivan Noris <<a href="mailto:ivan.noris@evolveum.com" target="_blank">ivan.noris@evolveum.com</a>><br>
> To: <a href="mailto:midpoint@lists.evolveum.com" target="_blank">midpoint@lists.evolveum.com</a><br>
> Subject: Re: [midPoint] LDAP role/group inducement<br>
> Message-ID: <<a href="mailto:4064f05c-67c2-0e78-dc5e-193e49697d80@evolveum.com" target="_blank">4064f05c-67c2-0e78-dc5e-193e49697d80@evolveum.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Hi Jan,<br>
><br>
> I have briefly checked your configuration and have two notes:<br>
><br>
> 1. associations should work flawlessly to add/remove group membership<br>
> even with tolerant=true. We are using it in trainings, I did the last<br>
> training 2 weeks ago with OpenLDAP instead of OpenDJ. Tolerant=false is<br>
> to allow midPoint to remove the account from associations not given by<br>
> midPoint, which may or may not be the "correct" behaviour for particular<br>
> projects<br>
><br>
> 2. I have seen your configuration of OpenDJ and am a little confused how<br>
> you are using "icfs:name" and "icfs:uid" attributes. This was the way<br>
> how we used them in the older LDAP connector (or legacy ICF/OpenICF<br>
> connectors). Instead we use ri:dn and whatever is the native "uid"<br>
> attribute (e.g. ri:entryuuid).<br>
><br>
> (I'm also confused that the schema is statically included in the examples.)<br>
><br>
> See<br>
><br>
> <a href="https://github.com/Evolveum/midpoint-samples/blob/master/samples/resources/opendj/opendj-resource-genericsync.xml" rel="noreferrer" target="_blank">https://github.com/Evolveum/midpoint-samples/blob/master/samples/resources/opendj/opendj-resource-genericsync.xml</a><br>
> for an example please.<br>
><br>
> Best regards,<br>
><br>
> Ivan<br>
><br>
> On 15. 1. 2020 16:19, Jan Lievens wrote:<br>
> > Hi,<br>
> ><br>
> > I have a question related to inducement construction on a role toward<br>
> > an LDAP resource.<br>
> > I have the following situation in midPoint (see the attachment for all<br>
> > the xml files)<br>
> > - Accounts and Entitlements (intent: privileges) are imported from a<br>
> > ScriptedSQL connector.<br>
> > - These imported entitlements have multiple privileges which are<br>
> > created as roles with an "assignmentTargetSearch"<br>
> > (post-initial-objects/210-entitlement-object-template.xml)<br>
> > - I also have these privilege/roles defined with an assignment to<br>
> > (multiple) fixed technical roles (kind:entitlement/intent:group).<br>
> > - Lastly I would like for these technical roles (groups) and the<br>
> > associated accounts to get synced to LDAP in an objectToSubject<br>
> > fashion. I do this with inducements and construction tags in<br>
> > post-initial-objects/100-profiles-webidm.xml.<br>
> > - The result I get in LDAP is that accounts are synced correctly but<br>
> > the group names are not what I expect (I expect technical role names<br>
> > eg. JiraUser) but get the names of the Entitlements<br>
> > (intent:privileges) defined in the DB.<br>
> > - Additionally the associations are not synced (no uniqueMember refs<br>
> > are synced on the LDAP groups).<br>
> ><br>
> > Surely I am missing something here. I think this use case is quiet<br>
> > standard (a hierarchy of roles and only the leafs get synced to LDAP).<br>
> > I have experimented with the order of the inducement but these came<br>
> > out even more negative (no accounts or groups were created).<br>
> > I also have experimented with the tolerant setting on the association<br>
> > (since I find a lot of answers in this mailing list suggesting this)<br>
> > but to no avail.<br>
> > It is quiet frustrating to be so close to having this use-case<br>
> > implemented DB->mP->LDAP but failing in the sync to LDAP.<br>
> ><br>
> > Kind regards,<br>
> > --<br>
> > Jan Lievens<br>
> > IT Consultant<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > midPoint mailing list<br>
> > <a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br>
> > <a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
><br>
> --<br>
> Ivan Noris<br>
> Senior Identity Engineer<br>
> <a href="http://evolveum.com" rel="noreferrer" target="_blank">evolveum.com</a><br>
><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<br>
> <a href="http://lists.evolveum.com/pipermail/midpoint/attachments/20200127/8f653a51/attachment-0001.htm" rel="noreferrer" target="_blank">http://lists.evolveum.com/pipermail/midpoint/attachments/20200127/8f653a51/attachment-0001.htm</a><br>
> ><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Mon, 27 Jan 2020 15:15:56 +0100<br>
> From: Jan Lievens <<a href="mailto:jan.lievens@biggerfish.be" target="_blank">jan.lievens@biggerfish.be</a>><br>
> To: <a href="mailto:midpoint@lists.evolveum.com" target="_blank">midpoint@lists.evolveum.com</a><br>
> Subject: Re: [midPoint] LDAP role/group inducement<br>
> Message-ID:<br>
> <CALKj1oYd_mevH=EJqMjn9Xq6JCv1dc4Q32E=<br>
> <a href="mailto:Ha2BhunXyD1iZg@mail.gmail.com" target="_blank">Ha2BhunXyD1iZg@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> So I figured out what the NullPointerException is all about: The code at<br>
> line ShadowAssociationWrapperFactoryImpl.java:193<br>
><br>
> "shadowAss.add(associationValue.findReference(ShadowAssociationType.F_SHADOW_REF).getValue().clone());"<br>
> expects to have a shadowRef in the association which it does not have (it<br>
> only has name and identifiers tags, like can be seen from my previous<br>
> post). Now I would say that this missing shadowRef needs to be fixed next<br>
> because when I null check this (and thus this line is not performed) the<br>
> lingering-"uniqueMember" bug in LDAP is resolved and the GUI admin does not<br>
> crash with a NPE but the shadow (the shadow of the entitlement that is, for<br>
> which the shadowRef should exist) is not cleaned up and can still be seen<br>
> in the repo. So when I again add the entitlement in PostgreSQL and perform<br>
> an import task on that resource it crashes on the fact that it sees<br>
> conflicting shadows (no surprise there).<br>
><br>
> Op za 25 jan. 2020 om 15:20 schreef Jan Lievens <<a href="mailto:jan.lievens@biggerfish.be" target="_blank">jan.lievens@biggerfish.be</a><br>
> >:<br>
><br>
> > So I debugged this problem with the lacking "association" item in the<br>
> > account shadow of the PostgreSQL resource. So again a tl;dr for the<br>
> people<br>
> > with no time to follow my lengthy explanation: the lingering uniqueMember<br>
> > reference gets cleaned up in LDAP when I remove<br>
> > line com.evolveum.midpoint.repo.sql.helpers.ObjectRetriever.java:557<br>
> > "prismObject.removeContainer(ShadowType.F_ASSOCIATION);"<br>
> ><br>
> > So what I see is that the shadow that gets written (xml in fullObject<br>
> > column) the first time into the repo and it contains the "association"<br>
> > item.<br>
> ><br>
> > <shadow xmlns="<br>
> > <a href="http://midpoint.evolveum.com/xml/ns/public/common/common-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>" xmlns:c="<br>
> > <a href="http://midpoint.evolveum.com/xml/ns/public/common/common-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>" xmlns:icfs="<br>
> ><br>
> <a href="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3</a><br>
> "<br>
> > xmlns:org="<a href="http://midpoint.evolveum.com/xml/ns/public/common/org-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/common/org-3</a>"<br>
> > xmlns:q="<a href="http://prism.evolveum.com/xml/ns/public/query-3" rel="noreferrer" target="_blank">http://prism.evolveum.com/xml/ns/public/query-3</a>" xmlns:ri="<br>
> > <a href="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/resource/instance-3</a>"<br>
> xmlns:t="<br>
> > <a href="http://prism.evolveum.com/xml/ns/public/types-3" rel="noreferrer" target="_blank">http://prism.evolveum.com/xml/ns/public/types-3</a>"<br>
> > oid="954b8cfe-5c84-4f82-946f-0196dcec92c0" version="0"><br>
> > <name>810710333333</name><br>
> > <resourceRef<br>
> > oid="dafe0482-faef-47b7-ae08-66b150929bb7" relation="org:default"<br>
> > type="c:ResourceType"><br>
> > <!-- Scripted SQL --><br>
> > </resourceRef><br>
> > <objectClass>ri:AccountObjectClass</objectClass><br>
> ><br>
> ><br>
> <primaryIdentifierValue>3fd83cd4-d1bb-4d7f-9a1a-12a02ed85a95</primaryIdentifierValue><br>
> > <kind>account</kind><br>
> > <exists>true</exists><br>
> > <attributes><br>
> > <icfs:name>810710333333</icfs:name><br>
> ><br>
> > <icfs:uid>3fd83cd4-d1bb-4d7f-9a1a-12a02ed85a95</icfs:uid><br>
> > </attributes><br>
> > <association id="1"><br>
> > <name>ri:ents</name><br>
> > <identifiers><br>
> ><br>
> > <icfs:name>20001-Milieumedewerker-01</icfs:name><br>
> > </identifiers><br>
> > </association><br>
> > <activation/><br>
> > </shadow><br>
> ><br>
> > It is afterwards (in a following reconciliation wave) that this gets<br>
> > overwritten with a version that has no association. Poof gone...<br>
> ><br>
> > <shadow xmlns="<br>
> > <a href="http://midpoint.evolveum.com/xml/ns/public/common/common-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>" xmlns:c="<br>
> > <a href="http://midpoint.evolveum.com/xml/ns/public/common/common-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>" xmlns:icfs="<br>
> ><br>
> <a href="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3</a><br>
> "<br>
> > xmlns:org="<a href="http://midpoint.evolveum.com/xml/ns/public/common/org-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/common/org-3</a>"<br>
> > xmlns:q="<a href="http://prism.evolveum.com/xml/ns/public/query-3" rel="noreferrer" target="_blank">http://prism.evolveum.com/xml/ns/public/query-3</a>" xmlns:ri="<br>
> > <a href="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/resource/instance-3</a>"<br>
> xmlns:t="<br>
> > <a href="http://prism.evolveum.com/xml/ns/public/types-3" rel="noreferrer" target="_blank">http://prism.evolveum.com/xml/ns/public/types-3</a>"<br>
> > oid="954b8cfe-5c84-4f82-946f-0196dcec92c0" version="1"><br>
> > <name>810710333333</name><br>
> > <resourceRef<br>
> > oid="dafe0482-faef-47b7-ae08-66b150929bb7" relation="org:default"<br>
> > type="c:ResourceType"/><br>
> ><br>
> ><br>
> <synchronizationTimestamp>2020-01-24T13:30:38.108Z</synchronizationTimestamp><br>
> ><br>
> ><br>
> <fullSynchronizationTimestamp>2020-01-24T13:30:38.108Z</fullSynchronizationTimestamp><br>
> > <objectClass>ri:AccountObjectClass</objectClass><br>
> ><br>
> ><br>
> <primaryIdentifierValue>3fd83cd4-d1bb-4d7f-9a1a-12a02ed85a95</primaryIdentifierValue><br>
> > <kind>account</kind><br>
> > <intent>webidm</intent><br>
> > <exists>true</exists><br>
> > <attributes xmlns:xsi="<br>
> > <a href="http://www.w3.org/2001/XMLSchema-instance" rel="noreferrer" target="_blank">http://www.w3.org/2001/XMLSchema-instance</a>" xmlns:c="<br>
> > <a href="http://midpoint.evolveum.com/xml/ns/public/common/common-3" rel="noreferrer" target="_blank">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>"<br>
> > xsi:type="c:ShadowAttributesType"><br>
> > <icfs:name>810710333333</icfs:name><br>
> ><br>
> > <icfs:uid>3fd83cd4-d1bb-4d7f-9a1a-12a02ed85a95</icfs:uid><br>
> > </attributes><br>
> > <activation/><br>
> > </shadow><br>
> ><br>
> > Immediately we see that the following modifications made to the just<br>
> > created shadow: REPLACE intent, kind, synchronizationTimestamp and<br>
> > fullSynchronizationTimestamp. It is in this replace that the<br>
> > "association"-part is removed and written into the repo. It is on<br>
> position<br>
> > com.evolveum.midpoint.repo.sql.helpers.ObjectRetriever.java:557 that the<br>
> > association from the shadow gets removed in a very explicit fashion with<br>
> > the ominous comment: "we store it because provisioning now sends it to<br>
> > repo, but it should be transient".<br>
> > When we remove this line that removes the association we get a fat NPE in<br>
> > the admin tool when opening the user, but our bug is fixed 😎.<br>
> > But somehow I can't shake the feeling that removing this line is hacky (I<br>
> > suppose other code might also depend on this line being there) and that<br>
> the<br>
> > association should get fetched from the inbound source (i.e. PostgreSQL)<br>
> at<br>
> > the right moment. But again I'm too novice to really know how to<br>
> configure<br>
> > that. Something of the likes of<br>
> > <searchStrategy>onResourceIfNeeded</searchStrategy> maybe?<br>
> > If someone could shime in here to actually verify that this is a bug then<br>
> > I could send in a pull request with the fix. I will look at the NPE in de<br>
> > admin GUI this monday so then I will know more on how unorthodox this fix<br>
> > is.<br>
> ><br>
> ><br>
> ><br>
> > Op vr 24 jan. 2020 om 10:14 schreef Jan Lievens <<br>
> <a href="mailto:jan.lievens@biggerfish.be" target="_blank">jan.lievens@biggerfish.be</a><br>
> > >:<br>
> ><br>
> >> Before diving into the more technical description of why I came to my<br>
> >> conclusion a short tl;dr for the impatient: something is probably not<br>
> >> correct in my schemaHandling part of the Scripted SQL resource with<br>
> respect<br>
> >> to the entitlement association. What that is, I have no clue about.<br>
> >><br>
> >> So I did a bit of code spelunking in midPoint to better understand the<br>
> >> problem. Here is what I came up with:<br>
> >><br>
> >> - To see what happened in the code with respect to the LDAP association<br>
> >> I put logger com.evolveum.midpoint.provisioning into the debug level<br>
> which<br>
> >> provides me with some fine log statement when the association<br>
> (user->group:<br>
> >> uniqueMember on the group) is made in LDAP:<br>
> >> 2020-01-23 08:58:22,737 [PROVISIONING] [midPointScheduler_Worker-2]<br>
> DEBUG<br>
> >> (com.evolveum.midpoint.provisioning.impl.ResourceObjectConverter):<br>
> >> PROVISIONING MODIFY operation on<br>
> >> resource:d0811790-6420-11e4-86b2-3c9755567874(OpenDJ)<br>
> >> MODIFY object, object class Technical Role, identified by:<br>
> >> {<br>
> >> entryUUID: 88972d7b-6deb-4d94-b343-d039099d23c4<br>
> >> dn: cn=jirauser,ou=groups,dc=didm,dc=be<br>
> >> }<br>
> >> changes: [<br>
> >> PropertyModificationOperation:<br>
> >> delta:<br>
> >> attributes/uniqueMember<br>
> >> ADD: uid=81071022511,ou=people,dc=didm,dc=be<br>
> >> matchingRule: {<br>
> >><br>
> <a href="http://prism.evolveum.com/xml/ns/public/matching-rule-3%7DstringIgnoreCase" rel="noreferrer" target="_blank">http://prism.evolveum.com/xml/ns/public/matching-rule-3}stringIgnoreCase</a><br>
> >> ]<br>
> >> - So basically I had to find out why the inverse is not happening when<br>
> >> the association is severed (when we delete the entitlement in the<br>
> >> PostgreSQL database)<br>
> >> - The conclusion I get from the code is that this should happen in the<br>
> >> ReconciliationProcessor.reconcileProjectionAssociations method. More<br>
> >> specifically at the end of that method it is decided to tolerate the<br>
> >> association or not (tolerant=false on the association is a required<br>
> thing<br>
> >> after all 😀).<br>
> >> - In this decideIfTolerateAssociation method I see this beautiful call<br>
> >> that is going to solve my world of pain:<br>
> >> recordAssociationDelta(valueMatcher, accCtx, assocDef,<br>
> >> ModificationType.DELETE, isCValue.getValue(), null, "it is not given by<br>
> any<br>
> >> mapping and the association is not tolerant");<br>
> >> - In my configuration this statement is not evaluated because it<br>
> >> requires that there is a PrismContainerValue<ShadowAssociationType><br>
> >> provided in the arguments of this method.<br>
> >> - And why is there no ShadowAssociationType in this case I hear you<br>
> ask?<br>
> >> Well because in<br>
> >> method<br>
> com.evolveum.midpoint.prism.impl.PrismContainerValueImpl#findItemByQName<br>
> >> it cannot find an "association" item in the shadow of the PostgreSQL<br>
> >> account (see screenshot in attachment).<br>
> >> - And indeed when I look at that specific shadow's repository object<br>
> >> xml, I see nothing that looks like an association.<br>
> >> - And why is there no "association" item on the PostgreSQL account<br>
> >> shadow? That I do not know. Maybe somebody can put me out of my misery?<br>
> >> - So basically I assume something is fishy about my schemaHandling part<br>
> >> of the Scripted SQL resource with respect to the entitlement<br>
> association.<br>
> >><br>
> >> Sorry if this is somewhat too technical, I realise there is a dev<br>
> mailing<br>
> >> list but I wanted to add it here so that people find the solution and<br>
> >> problem in the same space.<br>
> >><br>
> >> Op di 21 jan. 2020 om 15:50 schreef Jan Lievens <<br>
> >> <a href="mailto:jan.lievens@biggerfish.be" target="_blank">jan.lievens@biggerfish.be</a>>:<br>
> >><br>
> >>> Hi,<br>
> >>><br>
> >>> May I also add that I tried this setup with midPoint versions 4.0.1,<br>
> 4.0<br>
> >>> and 3.9 all with the same result (lingering uniqueMember attributes in<br>
> >>> LDAP).<br>
> >>><br>
> >>><br>
> >>> Op di 21 jan. 2020 om 14:47 schreef Jan Lievens <<br>
> >>> <a href="mailto:jan.lievens@biggerfish.be" target="_blank">jan.lievens@biggerfish.be</a>>:<br>
> >>><br>
> >>>> Hi all,<br>
> >>>><br>
> >>>> I have reduced the complexity of my use case and made it easy to<br>
> >>>> reproduce. Starting from the unix story (<br>
> >>>> <a href="https://wiki.evolveum.com/display/midPoint/Unix+Story+Test" rel="noreferrer" target="_blank">https://wiki.evolveum.com/display/midPoint/Unix+Story+Test</a>)<br>
> >>>> Now I have the following situation:<br>
> >>>> - Sync accounts from CSV to OpenDJ (works great)<br>
> >>>> - I have one meta-role that is assigned to a test role which results<br>
> >>>> in an LDAP group (works great)<br>
> >>>> - Then I assign this test role to a user which results in a<br>
> >>>> uniqueMember attribute on the LDAP group (nice)<br>
> >>>> - Then I unassign the test role from said user and the uniqueMember<br>
> >>>> attribute on the LDAP group is not getting removed (😭)<br>
> >>>> - The uniqueMember attribute cannot be removed even after running<br>
> >>>> reconcile/recompute on accounts and entitlements<br>
> >>>><br>
> >>>> More succinct description to reproduce:<br>
> >>>> - git checkout <a href="https://github.com/jalieven/midpoint-docker" rel="noreferrer" target="_blank">https://github.com/jalieven/midpoint-docker</a><br>
> >>>> - cd midpoint-docker<br>
> >>>> - git checkout simple-ldap-group<br>
> >>>> - 'make restart' (starts docker with postgres/opendj/midpoint)<br>
> >>>> - go to admin GUI <a href="http://localhost:8080/midpoint" rel="noreferrer" target="_blank">http://localhost:8080/midpoint</a><br>
> >>>> - login 'administrator' pwd '5ecr3t'<br>
> >>>> - create a new role 'TestGroup' with an assignment to role 'LDAP Group<br>
> >>>> Metarole'<br>
> >>>> [- in OpenDJ: be.didm.group.TestGroup is created] => OK (checking can<br>
> >>>> be done with 'make check_ldap' in root project)<br>
> >>>> - in admin GUI: add 'TestGroup' to 'user01' assignments<br>
> >>>> [- in OpenDJ: the be.didm.group.TestGroup gets the attribute<br>
> >>>> uniqueMember set to 'uid=user01,ou=people,dc=didm,dc=be'] => OK<br>
> >>>> - in admin GUI: remove 'TestGroup' from 'user01' assignments (minus<br>
> >>>> button and SAVE)<br>
> >>>> [- in OpenDJ: nothing happens: uniqueMember is not removed from<br>
> >>>> be.didm.group.TestGroup] => Not OK!<br>
> >>>> - to verify this stale uniqueMember attribute: in root of project do<br>
> >>>> 'make check_ldap'<br>
> >>>><br>
> >>>> Config files can be found in<br>
> >>>><br>
> demo/simple/midpoint_server/container_files/mp-home/post-initial-objects<br>
> >>>><br>
> >>>> As you can see reproducing this bug/miss-config takes 5min of work. If<br>
> >>>> this is a miss-configuration you might want to check because the same<br>
> is<br>
> >>>> happening in the unix story test. If this is a bug in midPoint all<br>
> the more<br>
> >>>> so to look at it. It is hard for me as a novice to say which one it<br>
> is.<br>
> >>>><br>
> >>>> It seems to me that this is a common use-case. I have come across this<br>
> >>>> issue a few times in this mailing list, none of which provide a<br>
> sufficient<br>
> >>>> solution:<br>
> >>>> <a href="http://lists.evolveum.com/pipermail/midpoint/2016-April/001720.html" rel="noreferrer" target="_blank">http://lists.evolveum.com/pipermail/midpoint/2016-April/001720.html</a><br>
> >>>> (the 'it-works-on-my-machine'-stance is kind of lame in this case and<br>
> it<br>
> >>>> doesn't help that the referred zip files does not resolve)<br>
> >>>><br>
> <a href="http://lists.evolveum.com/pipermail/midpoint/2016-November/002807.html" rel="noreferrer" target="_blank">http://lists.evolveum.com/pipermail/midpoint/2016-November/002807.html</a><br>
> >>>> (a lot of tolerant/strength stuff here)<br>
> >>>><br>
> <a href="http://lists.evolveum.com/pipermail/midpoint/2016-November/002843.html" rel="noreferrer" target="_blank">http://lists.evolveum.com/pipermail/midpoint/2016-November/002843.html</a><br>
> >>>> (suggests association shortcuts and multivalued schema fix in<br>
> scripted sql<br>
> >>>> connector, the latter of which does not apply in my described<br>
> use-case)<br>
> >>>><br>
> >>>> The midPoint Confluence suggests also to set various packages to trace<br>
> >>>> log level to debug what is going on but I must say that in so much<br>
> logging<br>
> >>>> I have no idea what to look for.<br>
> >>>> When I set the projector/clockwork to debug all I see is that the<br>
> >>>> remove of the association is not happening. More specifically this<br>
> package<br>
> >>>> on trace org.identityconnectors.framework.spi.operations points to<br>
> the fact<br>
> >>>> that the delete is not happening in the connector.<br>
> >>>><br>
> >>>> May I also add that the page<br>
> >>>><br>
> <a href="https://wiki.evolveum.com/display/midPoint/Initial+Logging+Setup+HOWTO" rel="noreferrer" target="_blank">https://wiki.evolveum.com/display/midPoint/Initial+Logging+Setup+HOWTO</a> is<br>
> >>>> not up to date. Setting the skipRepositoryLoggingSettings does not<br>
> work. So<br>
> >>>> there is currently no way to add specific loggers at start up through<br>
> the<br>
> >>>> logback(-extra).xml. It always gets overwritten by what is inside the<br>
> >>>> repository.<br>
> >>>> It appears that the skipRepositoryLoggingSettings was removed from the<br>
> >>>> code some time ago.<br>
> >>>><br>
> >>>> Kind Regards,<br>
> >>>> Jan Lievens<br>
> >>>><br>
> >>>> Op wo 15 jan. 2020 om 16:19 schreef Jan Lievens <<br>
> >>>> <a href="mailto:jan.lievens@biggerfish.be" target="_blank">jan.lievens@biggerfish.be</a>>:<br>
> >>>><br>
> >>>>> Hi,<br>
> >>>>><br>
> >>>>> I have a question related to inducement construction on a role toward<br>
> >>>>> an LDAP resource.<br>
> >>>>> I have the following situation in midPoint (see the attachment for<br>
> all<br>
> >>>>> the xml files)<br>
> >>>>> - Accounts and Entitlements (intent: privileges) are imported from a<br>
> >>>>> ScriptedSQL connector.<br>
> >>>>> - These imported entitlements have multiple privileges which are<br>
> >>>>> created as roles with an "assignmentTargetSearch"<br>
> >>>>> (post-initial-objects/210-entitlement-object-template.xml)<br>
> >>>>> - I also have these privilege/roles defined with an assignment to<br>
> >>>>> (multiple) fixed technical roles (kind:entitlement/intent:group).<br>
> >>>>> - Lastly I would like for these technical roles (groups) and the<br>
> >>>>> associated accounts to get synced to LDAP in an objectToSubject<br>
> fashion. I<br>
> >>>>> do this with inducements and construction tags in<br>
> >>>>> post-initial-objects/100-profiles-webidm.xml.<br>
> >>>>> - The result I get in LDAP is that accounts are synced correctly but<br>
> >>>>> the group names are not what I expect (I expect technical role names<br>
> >>>>> eg. JiraUser) but get the names of the Entitlements<br>
> (intent:privileges)<br>
> >>>>> defined in the DB.<br>
> >>>>> - Additionally the associations are not synced (no uniqueMember refs<br>
> >>>>> are synced on the LDAP groups).<br>
> >>>>><br>
> >>>>> Surely I am missing something here. I think this use case is quiet<br>
> >>>>> standard (a hierarchy of roles and only the leafs get synced to<br>
> LDAP).<br>
> >>>>> I have experimented with the order of the inducement but these came<br>
> >>>>> out even more negative (no accounts or groups were created).<br>
> >>>>> I also have experimented with the tolerant setting on the association<br>
> >>>>> (since I find a lot of answers in this mailing list suggesting this)<br>
> but to<br>
> >>>>> no avail.<br>
> >>>>> It is quiet frustrating to be so close to having this use-case<br>
> >>>>> implemented DB->mP->LDAP but failing in the sync to LDAP.<br>
> >>>>><br>
> >>>>> Kind regards,<br>
> >>>>> --<br>
> >>>>> Jan Lievens<br>
> >>>>> IT Consultant<br>
> >>>>><br>
> >>>>><br>
> >>>><br>
> >>>> --<br>
> >>>> Jan Lievens<br>
> >>>> IT Consultant<br>
> >>>> Bigger Fish<br>
> >>>> Hoogstraat 35<br>
> >>>> 9450 Haaltert<br>
> >>>> Belgium<br>
> >>>> VAT: BE 0734.993.447<br>
> >>>> Mob: +32 494 84 66 97<br>
> >>>><br>
> >>><br>
> >>><br>
> >>> --<br>
> >>> Jan Lievens<br>
> >>> IT Consultant<br>
> >>> Bigger Fish<br>
> >>> Hoogstraat 35<br>
> >>> 9450 Haaltert<br>
> >>> Belgium<br>
> >>> VAT: BE 0734.993.447<br>
> >>> Mob: +32 494 84 66 97<br>
> >>><br>
> >><br>
> >><br>
> >> --<br>
> >> Jan Lievens<br>
> >> IT Consultant<br>
> >> Bigger Fish<br>
> >> Hoogstraat 35<br>
> >> 9450 Haaltert<br>
> >> Belgium<br>
> >> VAT: BE 0734.993.447<br>
> >> Mob: +32 494 84 66 97<br>
> >><br>
> ><br>
> ><br>
> > --<br>
> > Jan Lievens<br>
> > IT Consultant<br>
> > Bigger Fish<br>
> > Hoogstraat 35<br>
> > 9450 Haaltert<br>
> > Belgium<br>
> > VAT: BE 0734.993.447<br>
> > Mob: +32 494 84 66 97<br>
> ><br>
><br>
><br>
> --<br>
> Jan Lievens<br>
> IT Consultant<br>
> Bigger Fish<br>
> Hoogstraat 35<br>
> 9450 Haaltert<br>
> Belgium<br>
> VAT: BE 0734.993.447<br>
> Mob: +32 494 84 66 97<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<br>
> <a href="http://lists.evolveum.com/pipermail/midpoint/attachments/20200127/01d6defc/attachment.htm" rel="noreferrer" target="_blank">http://lists.evolveum.com/pipermail/midpoint/attachments/20200127/01d6defc/attachment.htm</a><br>
> ><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
><br>
> _______________________________________________<br>
> midPoint mailing list<br>
> <a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br>
> <a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of midPoint Digest, Vol 93, Issue 31<br>
> ****************************************<br>
><br>
<br>
<br>
-- <br>
Jan Lievens<br>
IT Consultant<br>
Bigger Fish<br>
Hoogstraat 35<br>
9450 Haaltert<br>
Belgium<br>
VAT: BE 0734.993.447<br>
Mob: +32 494 84 66 97<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.evolveum.com/pipermail/midpoint/attachments/20200127/1fc4469c/attachment.htm" rel="noreferrer" target="_blank">http://lists.evolveum.com/pipermail/midpoint/attachments/20200127/1fc4469c/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
midPoint mailing list<br>
<a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
<br>
<br>
------------------------------<br>
<br>
End of midPoint Digest, Vol 93, Issue 32<br>
****************************************<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><div><div dir="ltr"><div><div dir="ltr"><div>Jan Lievens<div dir="ltr"><span><div><div dir="ltr"><div><div dir="ltr"><div><div style="font-size:12.8px;letter-spacing:0.2px">IT Consultant</div><div style="letter-spacing:0.2px"><font size="1">Bigger Fish</font></div><div style="letter-spacing:0.2px"><font size="1">Hoogstraat 35</font></div><div style="letter-spacing:0.2px"><font size="1">9450 Haaltert</font></div><div style="letter-spacing:0.2px"><font size="1">Belgium<br></font></div><div style="letter-spacing:0.2px"><font size="1">VAT: BE 0734.993.447</font></div><div style="font-size:12.8px;letter-spacing:0.2px"><div><font size="1">Mob: +32 494 84 66 97</font></div></div></div></div></div></div></div></span></div></div></div></div></div></div></span></div></div></div></div></div></div></div>