[midPoint] Unlinking accounts when user is deleted / unassigned?
Ivan Noris
ivan.noris at evolveum.com
Tue Aug 14 10:21:14 CEST 2018
Hi,
I assume you are deleting user from midPoint. In that case the mappings
for existence seem not to be evaluated which may be a bug.
But the following scenario should work if existence mapping is set to
return "true" in all cases:
1. edit user
2. unassign the role keeping the AD / Exchange account (or all roles)
3. existence mapping will keep the account forever; administrativeStatus
mapping will keep the account disabled
But in this scenario the user will be kept in midPoint.
I was briefly discussing this with my coleagues. There are multiple
ways/recommendations how to achieve something reasonable with the
features I'm aware of:
a) keep users in midPoint forever, use "Disable instead of delete" to
keep the accounts forever on target systems, or combine with "Delayed
delete" feature to delete the accouns after e.g. 30 days after disable
b) delete users from midPoint and use disabled delete capability (I have
copied links for possible enhancements for this earlier, namely the
configurable capabilities per objectType - which would be your case)
c) maybe you've discovered a bug/missing feature with the existence
mappings being not (correctly) evaluated when user is deleted in
midPoint. Please create a new issue in jira.evolveum.com and describe as
much as possible for this scenario.
Best regards,
Ivan
On 13.08.2018 23:29, Alcides Carlos de Moraes Neto wrote:
> Hi Ivan,
>
> I have tested this with 3.7, and the account gets deleted if the user
> is deleted, even if existence mapping is set to true.
>
> Em sex, 10 de ago de 2018 às 04:15, Ivan Noris
> <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>> escreveu:
>
> Hi,
>
> there is one other thing. When using disable instead of delete,
> the <existence> mapping may just return "true" all the time and
> the account will never be deleted when deleting the user or
> unassigning the role. (This is not the same as disabling the
> capability for deletion; you may want to combine both to prevent
> explicit account deletion.)
>
> You just need to update the existence mapping from returning
> <path>$focusExists</path> to <value>true</value>
>
> I think I have tried that some time ago (definitely not recently)
> and I don't know if there are any tests, but it should work.
>
> That should cover the deletion of user but still keep the account
> forever (the shadow in repository as well).
>
> You can try that and see.
>
> https://wiki.evolveum.com/display/midPoint/Disable+instead+of+Delete
> (this sample does contain the above mentioned configuration)
>
> Best regards,
> Ivan
>
> On 09.08.2018 20:43, Alcides Carlos de Moraes Neto wrote:
>> Thanks for the info, Ivan.
>>
>> In regards to unlinking, our mappings and correlation expressions
>> work in a way that, if a deactivated user would be unlinked the
>> account, it would not be linked again. But I understand it would
>> be an issue for a lot of cases.
>> The best practice would be to delete the user in midPoint.
>>
>> The main reason behind this is that I want to keep the AD login
>> account intact so the Exchange mailbox is not lost when a user
>> leaves.
>>
>>
>> Em qui, 9 de ago de 2018 às 05:56, Ivan Noris
>> <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>> escreveu:
>>
>> Hi,
>>
>> just to inform you that we are already tracking:
>>
>> https://jira.evolveum.com/browse/MID-2142 (Capabilities per
>> objectType (e.g. Delete capability only for some intents)
>>
>> and
>>
>> https://jira.evolveum.com/browse/MID-2144 (Configured
>> capabilities - add a way to ignore instead of "Operation not
>> supported" error)
>>
>> There are marked as "subscription needed", so you may want to
>> use a subscription to prioritize them.
>>
>> Related to unlinking: I'm not aware of any way, but even if
>> there was a way how to unlink an account (probably it's
>> possible using bulk tasks), the account would be linked back
>> if any synchronization would run for that resource and
>> unlinked->link reaction would be specified. This is because
>> unlink = dropping linkRef reference from user object to
>> shadow, but the shadow would still remain in the repository.
>> Even if the shadow would not remain, it would be recreated
>> upon next reconciliation with the system, as the account
>> still exists.
>>
>> So the best option would be avoid deletion of the accounts by
>> using configured capabilities, but as you correctly stated,
>> the current behaviour would apply for all objects on the
>> resource (accounts, groups etc.). That's why we are tracking
>> the features in our JIRA.
>>
>> Best regards,
>>
>> Ivan
>>
>>
>> On 08.08.2018 21:57, Alcides Carlos de Moraes Neto wrote:
>>> Hello list,
>>>
>>> Quick question: Is it possible to not delete, but unlink
>>> accounts when a user is deleted and/or unassigned from the
>>> account?
>>>
>>> Right now I'm able to disable instead of delete, but the
>>> account remains linked to the user.
>>> I would like to either delete the user without deleting the
>>> account, or unlink the user from the account automatically.
>>>
>>> I have simulated this by removing the "delete" capability
>>> from the resource, but this is not viable, as I need to be
>>> able to delete groups, but not users.
>>>
>>> Thanks!
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>> --
>> Ivan Noris
>> Senior Identity Engineer
>> evolveum.com <http://evolveum.com>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
> --
> Ivan Noris
> Senior Identity Engineer
> evolveum.com <http://evolveum.com>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
--
Ivan Noris
Senior Identity Engineer
evolveum.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180814/7f244065/attachment.htm>
More information about the midPoint
mailing list