Hey guys!
I need to clarify something about lifecycle state behavior:
We have an active LCS, with the “Enable Accounts” set to “All sources”.
If we disable an account (through API, UI, or directly in the source system) for an identity that is in this LCS, will ICS try to re-enable it again? Even if the identity doesn’t have any updates for the LCS attribute, can we guarantee that ISC will leave those accounts disabled?
It will not - the lifecycle state change is the provisioning event that triggers the account update
Yes, under your specific configuration (“Enable Accounts” set to “All sources” in an active LCS), you cannot guarantee that ISC will leave the accounts disabled. The system is likely to re-enable them.
When an identity is in an active Lifecycle State (LCS), that state’s provisioning configuration represents the desired end state for the accounts.
Desired State: LCS is Active → Accounts must be Enabled.
Manual Action: Account is manually set to Disabled.
Since the Identity’s cloudLifecycleState attribute hasn’t changed, an immediate re-enablement is not triggered. However, the re-enablement is likely to occur during any of the following periodic events:
Identity Refresh: ISC periodically checks to ensure that an identity’s access and accounts align with their current LCS and assigned roles.
Full Aggregation: If the source account status is not properly configured (see Solution 1 below), the aggregation assumes the account is active and syncs that status back to ISC.
Policy Enforcement: Any process that enforces policies tied to the Active LCS will see the discrepancy and issue a provisioning action to correct the “drift,” thus sending an Enable operation to the source.
1. Solutions to Guarantee Accounts Remain Disabled
To prevent the active LCS from overriding your manual disablement, you must introduce a mechanism that tells ISC, “Despite the user being Active, this account’s desired state is Disabled.”
A. The Recommended Governance Solution: Use a “Suspended” LCS
This is the standard SailPoint approach for managing temporary or out-of-band disablements:
Create a New LCS: Define a new LCS, such as Suspended or Leave of Absence.
Configure Disablement: In this new LCS, configure the provisioning policy to set “Disable Accounts” for “All Sources” (or specific sources).
Change the Identity’s State: When an account is manually disabled (via API, UI, or on the source), you must also change the Identity’s cloudLifecycleState to Suspended (using the Admin UI or a Set Lifecycle State API call).
Suspended → Desired state is Disabled. There is no discrepancy, and the account remains disabled. When the user returns, you simply change their LCS back to Active.For highly complex or custom logic, you can use a custom rule:
Active LCS, ISC expects the accounts to be enabled. To keep them disabled, you must either move the user to a Disabled LCS OR ensure the source is configured to correctly sync the account’s disabled status back to ISC.hey gokul, do you know where this is explained on the documentation?
we tested some cases, but some of them re-enable the accounts and others don’t
Have you tried “Process Identity” for the accounts that are not re-enabled?
I could not find any specific mention in the SailPoint documentation. I have noticed it while testing and just thought of adding it here.
Also, as per the response from Harbor Pilot:
The “Enable Accounts” setting in a Lifecycle State (LCS) interacts with disabled accounts by determining which source accounts should be enabled when an identity enters that lifecycle state. When “Enable Accounts” is set to “All sources” for a particular LCS, Identity Security Cloud (ISC) will attempt to enable all source accounts associated with identities in that lifecycle state.
However, it’s important to note that this setting does not automatically re-enable previously disabled accounts. The “Enable Accounts” configuration is applied during scheduled refreshes or when an identity’s lifecycle state changes. ISC evaluates the lifecycle states to determine whether their assigned identities have the access defined in the lifecycle states’ access profiles. If an account was previously disabled manually or through another process, the “Enable Accounts” setting in the LCS will not override that disabled status automatically. Administrators would need to take additional steps to re-enable such accounts, such as manually enabling the account or triggering a specific process to re-evaluate and update the account status.
It’s also worth noting that the ability to enable, disable, or delete accounts depends on the capabilities of the specific source. SailPoint recommends reviewing the sources that support Enable, Disable, and Delete operations before configuring these settings in lifecycle states to ensure the desired actions can be carried out on the target systems.
Hello,
It will not do that.
Lets say if your LCS state is active and you are enabling your source named as “Source1“ in Active LCS state.
Somehow, you get this account in target source disabled, in next aggregation, the respective target account will move to Disabled state and SailPoint ISC will not try to automatically re-enable the account as LCS state remains AS-IS.
But, lets say, in case, you move identity to Disable state and then, re-activate it, then only, your respective target system will move to ENABLE state.
Else, it will remain in DISABLE state only till your LCS state is changed for identity.
Regards,
Rohit Wekhande.