<div dir="ltr"><div dir="ltr">@Ivan Noris:</div><div dir="ltr">Have you seen <a href="http://lists.evolveum.com/pipermail/midpoint/2020-January/005887.html">http://lists.evolveum.com/pipermail/midpoint/2020-January/005887.html</a> and my follow-up messages? This is a simple version version of what we are trying to do and with your second note fixed (no static schema and usage of "dn" in stead of "name").</div><div>May I also point out that I have seen your first note ("associations should work flawlessly" response after just a brief scan of the xml files) a few times on this mailing list, that this is not a constructive attitude and that I provided brief instructions on how to reproduce my use case in under 5 minutes.<br></div><div>It is in the simple-ldap-group branch of repository <a href="https://github.com/jalieven/midpoint-docker">https://github.com/jalieven/midpoint-docker</a> that I started from the Unix Story (<a href="https://wiki.evolveum.com/display/midPoint/Unix+Story+Test">https://wiki.evolveum.com/display/midPoint/Unix+Story+Test</a>) This makes my point clearer that when removing entitlements from the inbound PostgreSQL resource, the outbound LDAP resource is not managed correctly uniqueMember attributes are not cleaned up.</div><div><br></div><div>Kind regards,</div><div>Jan</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op ma 27 jan. 2020 om 15:16 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 (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>
<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: <<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>
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=<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>
"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>
> 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 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>
> <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>
> 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>" 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>
> <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>
> <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>
> 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>" 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>
> <synchronizationTimestamp>2020-01-24T13:30:38.108Z</synchronizationTimestamp><br>
><br>
> <fullSynchronizationTimestamp>2020-01-24T13:30:38.108Z</fullSynchronizationTimestamp><br>
> <objectClass>ri:AccountObjectClass</objectClass><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 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 the<br>
> association should get fetched from the inbound source (i.e. PostgreSQL) at<br>
> the right moment. But again I'm too novice to really know how to 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 <<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 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 which<br>
>> provides me with some fine log statement when the association (user->group:<br>
>> uniqueMember on the group) is made in LDAP:<br>
>> 2020-01-23 08:58:22,737 [PROVISIONING] [midPointScheduler_Worker-2] 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>
>> <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 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 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 ask?<br>
>> Well because in<br>
>> method 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 association.<br>
>><br>
>> Sorry if this is somewhat too technical, I realise there is a dev 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, 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>
>>>> 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 is<br>
>>>> happening in the unix story test. If this is a bug in midPoint all the more<br>
>>>> so to look at it. It is hard for me as a novice to say which one it 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 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 it<br>
>>>> doesn't help that the referred zip files does not resolve)<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>
>>>> <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 scripted sql<br>
>>>> connector, the latter of which does not apply in my described 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 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 package<br>
>>>> on trace org.identityconnectors.framework.spi.operations points to the fact<br>
>>>> that the delete is not happening in the connector.<br>
>>>><br>
>>>> May I also add that the page<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 work. So<br>
>>>> there is currently no way to add specific loggers at start up through 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 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 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 (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 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) 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: <<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>
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>
</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>