Table of Contents

Account protection system

What is the account protection system?

The goal is to ensure that even after removing the role assigned to the account by the user, this account is not immediately removed from the end system. By the time the last role assigned to the account is removed, the IDM account will be marked as Protected.

If a user assigns a role that assigns the same account (he has the same generated UID in AccAccount) then the Protected mark is removed from the IDM account (so the account returns to its original state).

How can I use it?

Activating account protection before deletion is performed on provisioning mapping in the IDM system. Two items are available here:

For an account that is in a protected mode, provisioning will no longer be performed.

Basic use case scenario:

If the role "roleLDAP" were not reassigned, the account will be deleted after 10 days (by scheduled task).
Direct account deletion (AccAccount) will only be avoided if it is in the Protected state and at the same time is within a valid protection interval!
You can manually delete an account (AccAccount) even if the system is marked as protected. Deletions can be performed over accounts that are not in the protected interval (ie, they are not "Protected" or not valid). This account delete only causes switch the account to the protection. All identity account relations will be deleted until last one.
Account marked as protected can be removed manually. You need to set end of protection date on the account detail to the past, then you can delete account by bulk operation on accounts table.
On identity delete is use force delete. That remove relationships between identity and account, event if the AccAccount is in the protected mode. Only identity-account relations are removed. The account on system (AccAccount) is not removed! From this moment is AccAccount orphan without any relations on indentity. If new identity with same system identifier will be created, then this protected account will be linked on it!

Limitations:

It is possible to change the values of the mapped system attributes, depending on whether the account is Protected (as described for the DN attribute). This dynamic attribute should not be marked as "identifier" . In this case, the protected account will not be paired (according to the newly generated UID). The result will be new account (not the original back to the unprotected state)!
At this time, account protection resolves only accounts assigned to Identity.

Configuration on mapping system:

List of accounts (with some in protected state):