SailPoint ISC: Handling AD Account Deletion During Lifecycle State Transitions Based on Trusted Source Attributes

IdentityIQ (IIQ) IIQ Discussion and Questions
, , , , ,
1

Hi,

We have a scenario and would appreciate advice on the best way to handle it in SailPoint ISC.

We have an LCS called LCS-1, where an identity is generally not entitled to have a downstream AD account. However, under certain circumstances, such as when attribute01 in the trusted source contains XXX, the identity is entitled to have an AD account. I have configured roles to accommodate this requirement, and the role assignment works as expected.

The issue occurs when an identity transitions from LCS-2 (where an AD account is entitled) to LCS-1. Although the role is removed during the transition, the AD account remains because removing the role only removes the associated entitlement; it does not delete the account.

I cannot configure a blanket account deletion rule at the Identity Profile level for LCS-1 because, as explained above, an identity in LCS-1 may still be entitled to an AD account if the trusted source attribute meets the required condition.

One approach I am considering is to handle this scenario through the existing Before Provisioning (BP) rule for AD. Since there can only be one trusted source, we could retrieve the corresponding trusted source account in ISC using:

Account testAccount = idn.getFirstAccount("Trusted SOURCE", identity.getName());

We could then retrieve the relevant attribute using:

idn.getAccountAttribute(testAccount, "attribute01");

If the attribute value is XXX, the AD account should be retained. Otherwise, we could trigger account deletion through the BP rule using:

accReq.setOp(ProvisioningPlan.ObjectOperation.Delete);

The subsequent scheduled aggregation would then reflect the account deletion in the AD source in SailPoint ISC.

Is this the recommended approach, or is there a better-practice way to handle this scenario?

Ideally, I would prefer to achieve this through the standard ISC UI configuration rather than introducing additional logic in a BP rule, if possible, but I doubt

I would appreciate advice on the recommended best practice, including any alternative mechanisms available in ISC,

2

Hello Lalitha. You are correct. Removing the role revokes its entitlements, but it does not delete the AD account.

For your conditional case, I would use a Workflow with Privileged Task Automation (PTA) rather than extending your Before Provisioning rule. The AD connector lists Delete as N/A for regular user accounts, so Manage Accounts > Delete will not help here. PTA has an Active Directory > Delete User action that deletes the user directly over LDAPS using the distinguished name, independent of the connector.

A possible flow:

  1. Map attribute01 to an ISC identity attribute so the workflow can read it.
  2. Trigger on Identity Lifecycle State Change Processed and match the LCS-2 to LCS-1 move (previousState.name and newState.name are in the payload).
  3. If attribute01 = XXX, retain the account and stop.
  4. Otherwise, confirm the role is removed and its provisioning completed, then resolve the DN and run PTA > Delete User. Skip the delete if the attribute is missing or the DN cannot be resolved.

A few notes:

  • PTA needs a Privileged Action Gateway and credentials. It does not inherit the source account deletion approval settings, so add a workflow approval step if you need one, and enable Verify Certificate in production.
  • The lifecycle-state Delete Accounts option does not fit, since it is only available for Inactive (long-term) states and cannot condition on attribute01.
  • The BP rule only modifies an existing plan. It cannot initiate the delete on its own or get past the connector limitation.

If a hard delete is not mandatory, disabling the account is supported and reversible, and is often the more standard mover action. I would test both the XXX and non-XXX transitions in non-prod.

3

Hi @punna0001 Thanks for detailed answer,

Unfortunately, we do not have the Workflow module enabled in our tenant, so the approach described above does not appear to be an option. However, it has given me a good direction to explore.

My current plan is to configure an Account Updated trigger with a filter similar to the following, to detect when attribute01 becomes empty while the identity is in LCS-1:

$[?($.account.attributes.LIFECYCLE == "LCS-1")].singleValueAttributeChanges[?(@.name == "attribute01" && @.newValue =="")]

The trigger would then call an Azure Logic App or Automation Runbook to delete the account directly from on-premises AD.

Initially, I thought it would be cleaner to have the Logic App or Runbook delete or remove the account through the ISC API instead. However, the difference between the Delete and Remove operations is not entirely clear from the API documentation: by looks neither delete from real source ?

Based on your explanation, it appears that using the ISC API may not achieve the intended outcome of deleting the actual AD account.

Could you please share your thoughts on this proposed approach? In particular, are there any potential issues with using an Account Updated trigger to invoke a Logic App or Runbook that directly deletes the AD account?

4

Yes, tried out, we can capture this using the following filter:

$[?($.account.attributes.LIFECYCLE == "LCS-1")].singleValueAttributeChanges[?(@.name == "attribute01" && @.newValue == null)]

This will trigger the Logic App, followed by the Runbook, to delete the corresponding record.

It would also be a great feature if the framework provided more flexibility to delete records based on a combination of attributes, rather than relying solely on the lifecycle state (long-term inactive).

However, we will proceed with the above approach for now.