Add a safety threshold for the Delete Accounts feature (in an Identity Profile's Lifecycle state)

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

We would like to turn on the Delete Accounts feature for an Active Directory source in the INACTIVE_LONG_TERM lifecycle state

image
image883×238 12.5 KB

but with an added safety measure: we would stop the deletions from happening (or at least further deletions from happening) if they exceed a set threshold, say 40 for the sake of the exercise.

Is it something doable via a Rule? Which kind (I’m guessing ProvisioningRule ?), and how to obtain the number of deletions set to be triggered (or that have already been triggered) in the plan? I’m unfortunately fully trained with Rules.

2

Setup a separate LCS.

If your deletion happens 90 days after a separation, have different LCS state that is for 60 days after separation. On that LCS, send an email to the manager indicating the account will be deleted in x number of days, and cc your IGA team. Or just send it to a given administrator.

Turn it into a business process rather than trying to catch a unique edge case.

Train staff not to bulk set Lifecycle states and to be cautions when modifying your LCS transform. As a precaution, disable the delete transform when revamping logic.

3

Thanks, but we already do have the business process in place.

Here, we are looking to a technical answer to a technical risk (e.g. a bug in the HRIS / authoritative source or in ISC itself). If there is none, we’ll deal with it - we can script things outside ISC - but we’d want to do it in ISC if possible.

4

Hi @christophe_choumert,
Is the threshold of 40 based on the number of identities eligible for deletion on a single day? If yes, then each identity will have a separate plan created for its AD accounts to be deleted hence the count cannot be determined in Before Prov Rule. Here’s one possible approach (New Identity Attribute+Workflow+New LCS) -

Create a Delete Eligible identity attribute that becomes true when an identity is within 5 days of its end date. Build a workflow with “Scheduled Trigger” which runs daily that retrieves all identities using “Get Identities” with Delete Eligible = true, stores their current lifecycle state which would be most probably “inactive” in a “Define Variable”, and set their LCS to a new On Hold lifecycle state using “HTTP Request” by calling “Set LifecycleState API”

Include a Form action (5‑day deadline) sent to an admin to review the 40+ identities and confirm data accuracy. Use a Compare Strings step to check the response:

  • If the form is submitted with “Yes”, restore each identity’s previous lifecycle state (by calling “Set LifecycleState API”) and end the workflow.

  • If the form is not submitted or the response is “No”, leave the identity in On Hold.

Admins can later manually move identities to Delete if appropriate.

On the actual deletion date:

  • If the workflow restored the original lifecycle state, the LCS logic proceeds normally and transitions the identity to Delete.

  • If no action was taken in the workflow, the identity remains On Hold.

    • Update the LCS transform/rule so that when delete conditions are met (e.g., after 90 days of inactivity), it checks the identity’s current LCS:

      • If LCS = On Hold, continue returning On Hold.

      • Otherwise, return Delete.