<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Jan,</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CALKj1oaktOGi-QKXish_Pg=_scPLS-C5xmrV4yscLpQCz4G34A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">@Ivan Noris & @Pavol Mederly<br>
<div>Ivan, your suggestion that I should remove the
native-capabilities tag from the opendj resource did the trick
(uniqueMember attribute is cleared from the group when
deleting the entitlement). I think that I took that part from
an xml snippet from the mailing list.</div>
</div>
</blockquote>
<p>It was not just the capabilities, but also the ICF result
handlers (see
<a class="moz-txt-link-freetext" href="https://wiki.evolveum.com/display/midPoint/ICF+Issues#ICFIssues-ResultHandlers">https://wiki.evolveum.com/display/midPoint/ICF+Issues#ICFIssues-ResultHandlers</a>
- one of the trickiest ICF legacy). Anyway, native capabilities
should be always fetched by the connector.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CALKj1oaktOGi-QKXish_Pg=_scPLS-C5xmrV4yscLpQCz4G34A@mail.gmail.com">
<div dir="ltr">
<div>Together with the fact that I did not read up on that part
in Confluence: it was a disaster in the making.</div>
<div>My sanity has returned along with my confidence in the fact
that midPoint is the right tool for our use-case.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Having the confidence for midPoint is always good thing and we
are glad for that. Especially when there were issues that are now
resolved. And especially when the resolution is by a
configuration, not a bugfix.<br>
</p>
<p>Yes there could be some issue also with the documentation and
anyone is welcome to report such issues to be solved or even
contribute the fix(es). In parallel we are considering how to
improve our documentation in reasonable time.</p>
<blockquote type="cite"
cite="mid:CALKj1oaktOGi-QKXish_Pg=_scPLS-C5xmrV4yscLpQCz4G34A@mail.gmail.com">
<div dir="ltr">
<div>Pavol, thank you for your detailed feedback on my clumsy
attempt at bypassing my mis-configuration with hacks :) As I
said, I knew I was doing iffy stuff by commenting that line.
But one does strange things when facing a seemingly
insurmountable problem.</div>
<div>I am greatly indebted for your help and I must say I am
impressed with the state of your project (well documented
Confluence, readable code, helpful community).</div>
<div>FYI: We are seeking professional help from DAASI for the
follow-up verification of config/usage/deployment. I wanted to
verify the basic usage in a PoC myself to see if midPoint was
a fit.<br>
</div>
</div>
</blockquote>
<p>Good to hear!</p>
<p>Good luck & best regards</p>
<p>Ivan<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CALKj1oaktOGi-QKXish_Pg=_scPLS-C5xmrV4yscLpQCz4G34A@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op di 28 jan. 2020 om 08:40
schreef Jan Lievens <<a
href="mailto:jan.lievens@biggerfish.be"
moz-do-not-send="true">jan.lievens@biggerfish.be</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">
<div dir="ltr">So now my conclusion is that the NPE in the
admin points to the fact that together with name and
identifiers there should also be a shadowRef saved in the
shadow (PostgreSQL account) repo.<br>
We see that only the name and identifiers are saved in the
beginning (first import task). I suppose the shadowRef is at
that point not resolvable (perhaps the entitlements are not
imported yet so the shadow of an entitlement is not yet
available).<br>
Now we also see that if we perform a null safe check on the
NPE site our use-case works (uniqueMember is cleared of the
LDAP group when we remove entitlement from PostgreSQL) but
we see that the shadow of the entitlement is lingering in
the repo (and indeed when we again add the entitlement again
in PostgreSQL an exception is thrown saying that there are
conflicting shadows in the import task run).<br>
So my hunch is that the shadowRef should be saved on the
association when possible. I see that during the
reconciliation the shardowRef is correctly added beside the
name and identifiers tags (but alas never saved to the
repo).<br>
I will pursue this line of thinking. My best guess is to
save this shadowRef in the association someplace in the
ShadowManager.<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op ma 27 jan. 2020 om
15:15 schreef Jan Lievens <<a
href="mailto:jan.lievens@biggerfish.be"
target="_blank" moz-do-not-send="true">jan.lievens@biggerfish.be</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">
<div dir="ltr">So I figured out what the
NullPointerException is all about: The code at
line ShadowAssociationWrapperFactoryImpl.java:193
"shadowAss.add(associationValue.findReference(ShadowAssociationType.F_SHADOW_REF).getValue().clone());"
expects to have a shadowRef in the association which
it does not have (it only has name and identifiers
tags, like can be seen from my previous post). Now I
would say that this missing shadowRef needs to be
fixed next because when I null check this (and thus
this line is not performed) the
lingering-"uniqueMember" bug in LDAP is resolved and
the GUI admin does not crash with a NPE but the shadow
(the shadow of the entitlement that is, for which the
shadowRef should exist) is not cleaned up and can
still be seen in the repo. So when I again add the
entitlement in PostgreSQL and perform an import task
on that resource it crashes on the fact that it sees
conflicting shadows (no surprise there).</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op za 25 jan. 2020
om 15:20 schreef Jan Lievens <<a
href="mailto:jan.lievens@biggerfish.be"
target="_blank" moz-do-not-send="true">jan.lievens@biggerfish.be</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">
<div dir="ltr">So I debugged this problem with the
lacking "association" item in the account shadow
of the PostgreSQL resource. So again a tl;dr for
the people with no time to follow my lengthy
explanation: the lingering uniqueMember reference
gets cleaned up in LDAP when I remove
line com.evolveum.midpoint.repo.sql.helpers.ObjectRetriever.java:557
"prismObject.removeContainer(ShadowType.F_ASSOCIATION);"
<div><br>
<div>So what I see is that the shadow that gets
written (xml in fullObject column) the first
time into the repo and it contains the
"association" item. <br>
<br>
<shadow xmlns="<a
href="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>"
xmlns:c="<a
href="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>"
xmlns:icfs="<a
href="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3</a>"
xmlns:org="<a
href="http://midpoint.evolveum.com/xml/ns/public/common/org-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/common/org-3</a>"
xmlns:q="<a
href="http://prism.evolveum.com/xml/ns/public/query-3"
target="_blank" moz-do-not-send="true">http://prism.evolveum.com/xml/ns/public/query-3</a>"
xmlns:ri="<a
href="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/resource/instance-3</a>"
xmlns:t="<a
href="http://prism.evolveum.com/xml/ns/public/types-3"
target="_blank" moz-do-not-send="true">http://prism.evolveum.com/xml/ns/public/types-3</a>"
oid="954b8cfe-5c84-4f82-946f-0196dcec92c0"
version="0"><br>
<name>810710333333</name><br>
<resourceRef
oid="dafe0482-faef-47b7-ae08-66b150929bb7"
relation="org:default"
type="c:ResourceType"><br>
<!-- Scripted SQL
--><br>
</resourceRef><br>
<objectClass>ri:AccountObjectClass</objectClass><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>
<icfs:uid>3fd83cd4-d1bb-4d7f-9a1a-12a02ed85a95</icfs:uid><br>
</attributes><br>
<association id="1"><br>
<name>ri:ents</name><br>
<identifiers><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
overwritten with a version that has no
association. Poof gone...<br>
<br>
<shadow xmlns="<a
href="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>"
xmlns:c="<a
href="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>"
xmlns:icfs="<a
href="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3</a>"
xmlns:org="<a
href="http://midpoint.evolveum.com/xml/ns/public/common/org-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/common/org-3</a>"
xmlns:q="<a
href="http://prism.evolveum.com/xml/ns/public/query-3"
target="_blank" moz-do-not-send="true">http://prism.evolveum.com/xml/ns/public/query-3</a>"
xmlns:ri="<a
href="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/resource/instance-3</a>"
xmlns:t="<a
href="http://prism.evolveum.com/xml/ns/public/types-3"
target="_blank" moz-do-not-send="true">http://prism.evolveum.com/xml/ns/public/types-3</a>"
oid="954b8cfe-5c84-4f82-946f-0196dcec92c0"
version="1"><br>
<name>810710333333</name><br>
<resourceRef
oid="dafe0482-faef-47b7-ae08-66b150929bb7"
relation="org:default"
type="c:ResourceType"/><br>
<synchronizationTimestamp>2020-01-24T13:30:38.108Z</synchronizationTimestamp><br>
<fullSynchronizationTimestamp>2020-01-24T13:30:38.108Z</fullSynchronizationTimestamp><br>
<objectClass>ri:AccountObjectClass</objectClass><br>
<primaryIdentifierValue>3fd83cd4-d1bb-4d7f-9a1a-12a02ed85a95</primaryIdentifierValue><br>
<kind>account</kind><br>
<intent>webidm</intent><br>
<exists>true</exists><br>
<attributes xmlns:xsi="<a
href="http://www.w3.org/2001/XMLSchema-instance" target="_blank"
moz-do-not-send="true">http://www.w3.org/2001/XMLSchema-instance</a>"
xmlns:c="<a
href="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
target="_blank" moz-do-not-send="true">http://midpoint.evolveum.com/xml/ns/public/common/common-3</a>"
xsi:type="c:ShadowAttributesType"><br>
<icfs:name>810710333333</icfs:name><br>
<icfs:uid>3fd83cd4-d1bb-4d7f-9a1a-12a02ed85a95</icfs:uid><br>
</attributes><br>
<activation/><br>
</shadow><br>
</div>
<div><br>
</div>
<div>Immediately we see that the following
modifications made to the just created shadow:
REPLACE intent, kind, synchronizationTimestamp
and fullSynchronizationTimestamp. It is in
this replace that the "association"-part is
removed and written into the repo. It is on
position
com.evolveum.midpoint.repo.sql.helpers.ObjectRetriever.java:557
that the association from the shadow gets
removed in a very explicit fashion with the
ominous comment: "we store it because
provisioning now sends it to repo, but it
should be transient".</div>
<div>When we remove this line that removes the
association we get a fat NPE in 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 suppose other
code might also depend on this line being
there) and that the association should get
fetched from the inbound source (i.e.
PostgreSQL) at the right moment. But again I'm
too novice to really know how to configure
that. Something of the likes of
<searchStrategy>onResourceIfNeeded</searchStrategy>
maybe?<br>
</div>
<div>If someone could shime in here to actually
verify that this is a bug then I could send in
a pull request with the fix. I will look at
the NPE in de admin GUI this monday so then I
will know more on how unorthodox this fix is.</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op vr 24 jan.
2020 om 10:14 schreef Jan Lievens <<a
href="mailto:jan.lievens@biggerfish.be"
target="_blank" moz-do-not-send="true">jan.lievens@biggerfish.be</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">
<div dir="ltr">
<div>Before diving into the more technical
description of why I came to my conclusion a
short tl;dr for the impatient: something is
probably not correct in my schemaHandling
part of the Scripted SQL resource with
respect to the entitlement association. What
that is, I have no clue about.</div>
<div><br>
</div>
<div>So I did a bit of code spelunking in
midPoint to better understand the problem.
Here is what I came up with:</div>
<div><br>
</div>
<div> - To see what happened in the code with
respect to the LDAP association I put logger
com.evolveum.midpoint.provisioning into the
debug level which provides me with some fine
log statement when the association
(user->group: uniqueMember on the group)
is made in LDAP:</div>
<div>2020-01-23 08:58:22,737 [PROVISIONING]
[midPointScheduler_Worker-2] DEBUG
(com.evolveum.midpoint.provisioning.impl.ResourceObjectConverter):
PROVISIONING MODIFY operation on
<a class="moz-txt-link-freetext" href="resource:d0811790-6420-11e4-86b2-3c9755567874(OpenDJ)">resource:d0811790-6420-11e4-86b2-3c9755567874(OpenDJ)</a><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: {<a
href="http://prism.evolveum.com/xml/ns/public/matching-rule-3%7DstringIgnoreCase"
target="_blank" moz-do-not-send="true">http://prism.evolveum.com/xml/ns/public/matching-rule-3}stringIgnoreCase</a><br>
]<br>
</div>
<div> - So basically I had to find out why the
inverse is not happening when the
association is severed (when we delete the
entitlement in the PostgreSQL database)</div>
<div> - The conclusion I get from the code is
that this should happen in the
ReconciliationProcessor.reconcileProjectionAssociations
method. More specifically at the end of that
method it is decided to tolerate the
association or not (tolerant=false on the
association is a required thing after
all 😀).</div>
<div> - In this decideIfTolerateAssociation
method I see this beautiful call that is
going to solve my world of pain:</div>
<div>recordAssociationDelta(valueMatcher,
accCtx, assocDef, ModificationType.DELETE,
isCValue.getValue(), null, "it is not given
by any mapping and the association is not
tolerant");<br>
</div>
<div> - In my configuration this statement is
not evaluated because it requires that there
is a
PrismContainerValue<ShadowAssociationType>
provided in the arguments of this method.</div>
<div> - And why is there no
ShadowAssociationType in this case I hear
you ask? Well because in
method com.evolveum.midpoint.prism.impl.PrismContainerValueImpl#findItemByQName
it cannot find an "association" item in the
shadow of the PostgreSQL account (see
screenshot in attachment).</div>
<div> - And indeed when I look at that
specific shadow's repository object xml, I
see nothing that looks like an association.</div>
<div> - And why is there no "association" item
on the PostgreSQL account shadow? That I do
not know. Maybe somebody can put me out of
my misery?</div>
<div> - So basically I assume something is
fishy about my schemaHandling part of the
Scripted SQL resource with respect to the
entitlement association.</div>
<div><br>
</div>
<div>Sorry if this is somewhat too technical,
I realise there is a dev mailing list but I
wanted to add it here so that people find
the solution and problem in the same space.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op di 21
jan. 2020 om 15:50 schreef Jan Lievens <<a
href="mailto:jan.lievens@biggerfish.be"
target="_blank" moz-do-not-send="true">jan.lievens@biggerfish.be</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">
<div dir="ltr">Hi,
<div><br>
</div>
<div>May I also add that I tried this
setup with midPoint versions 4.0.1, 4.0
and 3.9 all with the same result
(lingering uniqueMember attributes in
LDAP).</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op di 21
jan. 2020 om 14:47 schreef Jan Lievens
<<a
href="mailto:jan.lievens@biggerfish.be"
target="_blank" moz-do-not-send="true">jan.lievens@biggerfish.be</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">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>I have reduced the complexity of
my use case and made it easy to
reproduce. Starting from the unix
story (<a
href="https://wiki.evolveum.com/display/midPoint/Unix+Story+Test"
target="_blank"
moz-do-not-send="true">https://wiki.evolveum.com/display/midPoint/Unix+Story+Test</a>)</div>
<div>Now I have the following
situation:</div>
<div> - Sync accounts from CSV to
OpenDJ (works great)</div>
<div> - I have one meta-role that is
assigned to a test role which
results in an LDAP group (works
great)</div>
<div> - Then I assign this test role
to a user which results in a
uniqueMember attribute on the LDAP
group (nice)</div>
<div> - Then I unassign the test role
from said user and the uniqueMember
attribute on the LDAP group is not
getting removed (😭)</div>
<div> - The uniqueMember attribute
cannot be removed even after running
reconcile/recompute on accounts and
entitlements</div>
<div><br>
</div>
<div>More succinct description to
reproduce:</div>
<div>- git checkout <a
href="https://github.com/jalieven/midpoint-docker"
target="_blank"
moz-do-not-send="true">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"
target="_blank"
moz-do-not-send="true">http://localhost:8080/midpoint</a>
<br>
- login 'administrator' pwd '5ecr3t'<br>
- create a new role 'TestGroup' with
an assignment to role 'LDAP Group
Metarole'<br>
[- in OpenDJ:
be.didm.group.TestGroup is created]
=> OK (checking can 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 uniqueMember set to
'uid=user01,ou=people,dc=didm,dc=be']
=> OK<br>
- in admin GUI: remove 'TestGroup'
from 'user01' assignments (minus
button and SAVE)<br>
[- in OpenDJ: nothing happens:
uniqueMember is not removed from
be.didm.group.TestGroup] => Not
OK!</div>
<div>- to verify this stale
uniqueMember attribute: in root of
project do 'make check_ldap'<br>
<br>
Config files can be found in
demo/simple/midpoint_server/container_files/mp-home/post-initial-objects<br>
</div>
<div><br>
</div>
<div>As you can see reproducing this
bug/miss-config takes 5min of work.
If this is a miss-configuration you
might want to check because the same
is happening in the unix story test.
If this is a bug in midPoint all the
more so to look at it. It is hard
for me as a novice to say which one
it is. </div>
<div><br>
</div>
<div>
<div>It seems to me that this is a
common use-case. I have come
across this issue a few times in
this mailing list, none of which
provide a sufficient solution:</div>
<div><a
href="http://lists.evolveum.com/pipermail/midpoint/2016-April/001720.html"
target="_blank"
moz-do-not-send="true">http://lists.evolveum.com/pipermail/midpoint/2016-April/001720.html</a>
(the
'it-works-on-my-machine'-stance is
kind of lame in this case and it
doesn't help that the referred zip
files does not resolve)<br>
</div>
<div><a
href="http://lists.evolveum.com/pipermail/midpoint/2016-November/002807.html"
target="_blank"
moz-do-not-send="true">http://lists.evolveum.com/pipermail/midpoint/2016-November/002807.html</a>
(a lot of tolerant/strength stuff
here)<br>
</div>
<div><a
href="http://lists.evolveum.com/pipermail/midpoint/2016-November/002843.html"
target="_blank"
moz-do-not-send="true">http://lists.evolveum.com/pipermail/midpoint/2016-November/002843.html</a>
(suggests association shortcuts
and multivalued schema fix in
scripted sql connector, the latter
of which does not apply in my
described use-case)</div>
</div>
<div><br>
</div>
<div>The midPoint Confluence suggests
also to set various packages to
trace log level to debug what is
going on but I must say that in so
much logging I have no idea what to
look for.</div>
<div>When I set the
projector/clockwork to debug all I
see is that the remove of the
association is not happening. More
specifically this package on
trace org.identityconnectors.framework.spi.operations
points to the fact that the delete
is not happening in the connector.</div>
<div><br>
</div>
<div>May I also add that the page <a
href="https://wiki.evolveum.com/display/midPoint/Initial+Logging+Setup+HOWTO"
target="_blank"
moz-do-not-send="true">https://wiki.evolveum.com/display/midPoint/Initial+Logging+Setup+HOWTO</a> is
not up to date. Setting the
skipRepositoryLoggingSettings does
not work. So there is currently no
way to add specific loggers at start
up through the logback(-extra).xml.
It always gets overwritten by what
is inside the repository.<br>
</div>
<div>It appears that the
skipRepositoryLoggingSettings was
removed from the code some time
ago. </div>
<div><br>
</div>
<div>Kind Regards,</div>
<div>Jan Lievens</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op
wo 15 jan. 2020 om 16:19 schreef Jan
Lievens <<a
href="mailto:jan.lievens@biggerfish.be"
target="_blank"
moz-do-not-send="true">jan.lievens@biggerfish.be</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">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I have a question related to
inducement construction on a
role toward an LDAP resource.</div>
<div>I have the following
situation in midPoint (see the
attachment for all the xml
files)</div>
<div>- Accounts and Entitlements
(intent: privileges) are
imported from a ScriptedSQL
connector.</div>
<div>- These imported entitlements
have multiple privileges which
are created as roles with an
"assignmentTargetSearch"
(post-initial-objects/210-entitlement-object-template.xml)</div>
<div>- I also have these
privilege/roles defined with an
assignment to (multiple) fixed
technical roles
(kind:entitlement/intent:group).</div>
<div>- Lastly I would like for
these technical roles (groups)
and the associated accounts to
get synced to LDAP in an
objectToSubject fashion. I do
this with inducements and
construction tags in
post-initial-objects/100-profiles-webidm.xml.</div>
<div>- The result I get in LDAP is
that accounts are synced
correctly but the group names
are not what I expect (I expect
technical role names
eg. JiraUser) but get the names
of the Entitlements
(intent:privileges) defined in
the DB.</div>
<div>- Additionally the
associations are not synced (no
uniqueMember refs are synced on
the LDAP groups).</div>
<div><br>
</div>
<div>Surely I am missing something
here. I think this use case is
quiet standard (a hierarchy of
roles and only the leafs get
synced to LDAP).</div>
<div>I have experimented with the
order of the inducement but
these came out even more
negative (no accounts or groups
were created).</div>
<div>I also have experimented with
the tolerant setting on the
association (since I find a lot
of answers in this mailing list
suggesting this) but to no
avail.</div>
<div>It is quiet frustrating to be
so close to having this use-case
implemented DB->mP->LDAP
but failing in the sync to LDAP.</div>
<div><br clear="all">
<div>Kind regards,</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><span>
<div dir="ltr">
<div dir="ltr">Jan
Lievens
<div dir="ltr"><span>
<div dir="ltr">
<div dir="ltr">
<div
style="font-size:12.8px;letter-spacing:0.2px">IT
Consultant</div>
<div
style="letter-spacing:0.2px"><br>
</div>
</div>
</div>
</span></div>
</div>
</div>
</span></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<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>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<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>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<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>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<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>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<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>
</blockquote>
</div>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<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>
</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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Ivan Noris
Senior Identity Engineer
evolveum.com
</pre>
</body>
</html>