Updating an Identity Attribute to disable Downstream systems

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

Hi Team,
We are currently facing a challenge related to our leaver process within our Entra-based HR system and would appreciate your guidance.

Background: As part of the leaver workflow, when a user is removed from the HR system (Entra), they are dropped from the target feed. The desired outcome is to automatically disable all downstream systems when this occurs.

Approach Attempted: We attempted to address this through SailPoint Identity Security Cloud (ISC) Workflows by:

  1. Using native change detection to identify when a user is deleted/removed from the HR feed.

  2. Updating the identity attribute LCS = Inactive to trigger the standard disable flow across downstream systems.

Limitation Identified: Upon investigation, we discovered that identity attributes cannot be updated directly through Workflows in ISC, which prevents us from completing the intended automation.

Request: We are looking for alternate approaches to achieve the same outcome ā€” specifically, ensuring that when a user is dropped from the HR feed, all downstream system accounts are disabled accordingly.

Any guidance, best practices, or recommended solutions would be greatly appreciated.

Thank you

2

Hi @Prash55

When a user is terminated or leaves, why is the record being deleted in Entra? Are you filtering for only active individuals in your authoritative source aggregation? I imagine you already thought of this, but the easiest route would be to ensure that the authoritative source wonā€™t delete accounts or at least wonā€™t do that until all down stream systems are already deprovisioned, possibly with a filter of only delete after 30 days.

3

@Prash55 When a user is getting terminated, is the record also gets removed from Entra or record exists ? If the record exists then based on the transform logic , you can returnt he cloudLifecycleState as Inactive and process the user as per your usecase.

4

The user is moved to SoftDelete status in Entra, as part of the aggregation process, the record is getting dropped from the feed, without any filters on ISC side! Any suggested approach to De-provision the active downstream accounts?

5

Are you using any csv file for feed and removing the userdata from the feed if it is deleted?

6

This will result in identity object being an orphan, which also means identity ceases to exist in ISC and you cannot do anything to the accounts that were correlated to the identity. Ideally, you need to have the record be present for a certain period of time since soft delete so that you can manage all LCS changes and offboarding process

7

Hi @Prash55 I take it there is an Identity Profile associated with your Entra Source and this is where you configure your LCS?
If so you could incorporate the presence or not of an Entra Account Attribute (say accountEnabled), wrapped in a firstValid, so that if the Attribute cannot be found (the Account does not exist) you can conditionally set the LCS to Inactive, if thatā€™s what you want to use to disable downstream systems.
Native Change Detection is not really applicable in Authoritative Sources.

8

@iamnithesh Is it possible to use Native Change detection and workflows together achieve this use case?

9

Hi @iamnithesh Iā€™m not sure that the Identity ceases to exist in this scenario, tbh.

10

He mentioned HR System, so Iā€™m assuming this means authoritative source. The identity will get deleted if it also does in the authoritative source.

Easiest solution here is to not delete the identity from Entra and instead disable it then do the delete after a certain period of time.

11

it does as Entra is the auth source here

12

best approach is not to delete the account from auth source until all offboarding process is completed

13

Issue here is I can turn off the Detect deleted accounts or ask Entra not to remove from the feed, which would not remove from ISC, but there is no field that indicates in ENTRA such as termdate or status fields which we can rely on to terminate a user from ISC!.

14

See Loading Account Data - SailPoint Identity Services The Identity will only get deleted if it doesnā€™t meet criteria such as having correlated accounts on other sources.

15

Hi @Prash55 There is isSoftDeleted

16

What it says is that if the identity was already correlated with an account from another source marked as ā€œAuth sourceā€ then it will not be deleted but moves to the new identity profile belonging to the new auth source.

17

It says

Deletion can be blocked if the identity:
has accounts from other sources correlated to it.

18

You can designate an attribute in Entra to be your termDate or status field. Find an attribute that isnā€™t being used, and then tell HR to update that field when someone is actived or terminated. Then trigger your lifecycleState on that Entra attribute. Then handle account disablements through a normal Identity Profile lifecycle.

19

in such case identity becomes hidden which I was referring to as an orphan identity in the beginning. Though it dangles around, there is practically nothing can be done with it

20

ISC needs data in order to process data. The omission / disappearance of the account to trigger a leaver process, in general, isnā€™t a good / robust practice to go withā€¦because lack of data has no explicit meaning as to why itā€™s missing. i.e. ā€œDisappearance of account means leaverā€ is an assumptionā€¦a happy path assumption.

For example, if for whatever reason, the service account used for aggregation is missing certain readability scope to a subset of Entra accounts (say, due to incorrect configuration changes), your aggregation would still complete successfully, but now with ā€˜missingā€™ dataā€¦and the system would trigger mass leaver on themā€¦