[midPoint] Problem deprovisioning

Thu Oct 22 17:45:52 CEST 2020

Hi Richard,

thank you for your great help! We are trying to do something similar, I'll let you know what we managed to do.

Regards,
Andrea

From: Richard Frovarp <richard.frovarp at ndsu.edu>
Sent: Wednesday, October 21, 2020 6:35 PM
To: Andrea Picconi <andrea.picconi at innovery.net>; midpoint at lists.evolveum.com
Cc: Marianna De Biasio <marianna.debiasio at innovery.net>; Jacopo Giuliano <jacopo.giuliano at innovery.net>
Subject: Re: [midPoint] Problem deprovisioning

I'm very much a novice at this as well.

I don't remember what you need in there if it is a built in attribute. You may want to look at the samples, and see if you can find something there. But you are very much correct that the F_EXTENSION is because I'm using extended attributes. It's easier with built in ones, I just don't have an example handy.

You can use the query playground to build that part out. That greater is there because I couldn't find a not null condition that worked for me. There are two attributes as those are the two I care about most. The other two, DeptId and supervisor are actually ones I recently added that needed to be blanked about. In theory any of them other than supervisor id could be the single one I use to query on. I ran into a problem early on when trying to come up with this where I set the attributes to effectively the empty string, instead of null. I wanted null. And my first round of experiments only changed one of those two. So I queried off of both. Now that my data should be consistent, I should be able to drop to just one of them.

Effectively it is looking for anyone that has either of those values set to anything other than null. Turns out that the empty string is greater than null. It doesn't catch empty strings, but I shouldn't have cases of that happening in my data. So it find all user objects that have those values set. Right now I have 37k users in midPoint, and that query filters it down to only those that have one of those two attributes set. I'm at a university, so most of my users are students, and don't have titles. So this is the first good filter I can do to reduce the number of users I search.

Then from there the script checks to see if the user has an active shadow on the DB resource that put the attributes there. If it has an active shadow on that resource, then they are an active employee, and thus should keep those attributes. So it fires a return to not touch that user.

So given how the file is laid out, it is kind of backwards. The object query fires first to generate a list of users, which is then passed to the executeScript one at a time. So the script doesn't do the looping, it is what is being called in the loop over each user.

I do something very similar to remove people from orgs when they aren't in the right resource anymore (and at a prescribed time). I'm hoping late in November I can write something more comprehensive up and contribute examples back. Right now I'm in the middle of a giant migration, and don't have much time to do that.

On Wed, 2020-10-21 at 16:15 +0000, Andrea Picconi wrote:
Hi Richard,

thank you for your help. A couple of question about your .xml:

I think that in the first part you are providing to the application the attributes that needs, right?
F_EXTENSION refers to the fact that they are extended attributes, but if instead they were “normal” attributes (the base attributes of Midpoint) what can I use?

In the second part (I apologize but I’m not familiar with coding ecc.), how the object query works? Which steps perform? Why I see only two attributes inside the <greater> tag?

Thank you for your time and help!

Andrea

From: midPoint <midpoint-bounces at lists.evolveum.com<mailto:midpoint-bounces at lists.evolveum.com>> On Behalf Of Richard Frovarp via midPoint
Sent: Wednesday, October 21, 2020 4:47 PM
To: midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>
Cc: Richard Frovarp <richard.frovarp at ndsu.edu<mailto:richard.frovarp at ndsu.edu>>
Subject: Re: [midPoint] Problem deprovisioning

I was able to find a reasonable work around for my user population. I have a bulk task that runs every day. One feature that would be nice is this functionality in the query options that I use all of the time in our legacy system in direct SQL

where pk not in (select pk from other_table where user has some sort of attribute)

Since I can't figure out how to do that in this query syntax, have a slight work around. I have a bulk task that runs on schedule. It queries for everyone that has one of the attributes I want to blank out. It then iterates through each of those users to see if they have a shadow in the resource that created those attributes. If they don't, it blanks the attributes out. Attached is one such task. For anyone wondering, I am supporting two different institutions in midPoint, hence the need for custom schema extension for attributes in midPoint already, like title. Plus I'm higher education, so people can be in multiple departments, hence the "primary". This takes just over 3 minutes on just under 6k people. And we really haven't taken any time to tune the performance of our environment other than making sure midPoint has plenty of memory assigned to it.

There's also probably a way to collapse this down to be a bit more efficient, but this is efficient enough for us at this moment. Note my method for checking if the user has a shadow in the specified resource. I was doing bad things previously where I iterated over all shadows the user had, and that wasn't good. So only hunt for the one you want.

On Wed, 2020-10-21 at 16:34 +0200, Pavol Mederly via midPoint wrote:

Hello,

as far as I know, this seemingly "innocent" scenario is surprisingly not directly supported by midPoint. Richard Frovarp asked about it here in July. Just look for "How to blank out user properties?" thread.

The technical reason why the data cannot be cleaned up by the same mapping that provides them is the fact that the inbound mapping is no longer applied when the account is gone.

So a workaround has to be conceived. Some of these workarounds are discussed in the mentioned thread. (What comes to my mind, though, is to map data from the resource to a set of auxiliary user properties, from where they are propagated to the "main" properties - Titolo, Matricola, ... - under condition of hasLinkedAccount for the resource.)

Best regards,

Pavol Mederly

Software developer

evolveum.com

On 21/10/2020 15:43, Andrea Picconi via midPoint wrote:
Hi Petr,

I mean that the field (or fields) must be blank.
With the account still linked, the fields are filled (example here)

[cid:image001.jpg at 01D6A89A.D7D85FC0]

but if I unlink the account, I expect midpoint to deprovision and remove the attributes of that account (here the same with what I expect)

[cid:image002.jpg at 01D6A89A.D7D85FC0]

Thanks

From: Petr Gašparík - AMI Praha a.s. <petr.gasparik at ami.cz><mailto:petr.gasparik at ami.cz>
Sent: Wednesday, October 21, 2020 3:32 PM
To: midPoint General Discussion <midpoint at lists.evolveum.com><mailto:midpoint at lists.evolveum.com>
Cc: Andrea Picconi <andrea.picconi at innovery.net><mailto:andrea.picconi at innovery.net>; Marianna De Biasio <marianna.debiasio at innovery.net><mailto:marianna.debiasio at innovery.net>; Jacopo Giuliano <jacopo.giuliano at innovery.net><mailto:jacopo.giuliano at innovery.net>
Subject: Re: [midPoint] Problem deprovisioning

Please elaborate more on what means "delete attributes" :)

--

s pozdravem

Petr Gašparík
konzultant IT bezpečnosti

gsm: [+420] 603 523 860
e‑mail: petr.gasparik at ami.cz<mailto:petr.gasparik at ami.cz>

AMI Praha a.s.
Pláničkova 11, 162 00 Praha 6

tel.: [+420] 274 783 239 | web: www.ami.cz<https://www.ami.cz>

[Immagine rimossa dal                                              mittente. AMI Praha a.s.]

Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá za společnost AMI Praha a.s.
jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně písemnou formu.

Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může obsahovat důvěrné nebo osobní
informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv zveřejňování, zprostředkování
nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail neoprávněně, informujte o tom prosím
odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně všech jeho příloh. Nakládáním
s neoprávněně získanými informacemi se vystavujete riziku právního postihu.

st 21. 10. 2020 v 15:24 odesílatel Andrea Picconi via midPoint <midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>> napsal:

Hello everyone,

I have a problem while unlinking an account from a user: what happens is that the unlink process correctly removes the account inside the Projections tab , but it doesn’t deprovision the attributes that are mapped within that account.

What could cause this unexpected behaviour? And how do i get all these attributes to be deleted from Midpoint ?

Regards,
Andrea Picconi
IAM (Identity Access Management)
[Innovery]
Skype: precons
T:  +39 06 51963439 (int. 196)

Strada Quattro Palazzina A6 c/o Centro Direzionale Milanofiori, 20057 Assago (MI).
www.innovery.net<http://www.innovery.net/> |  T: +39 06 519 63 439

_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
https://lists.evolveum.com/mailman/listinfo/midpoint

_______________________________________________

midPoint mailing list

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

https://lists.evolveum.com/mailman/listinfo/midpoint

_______________________________________________

midPoint mailing list

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

https://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201022/b7d5d7bb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 10200 bytes
Desc: image001.jpg
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201022/b7d5d7bb/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 9004 bytes
Desc: image002.jpg
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201022/b7d5d7bb/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image003.jpg
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201022/b7d5d7bb/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 8058 bytes
Desc: image004.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201022/b7d5d7bb/attachment.png>