I’d like to provide some context regarding our Lifecycle State (LCS) configuration.
We have defined a Lifecycle State called “Deprovisioned”, where the requirement is to remove all target accounts while retaining a single target account in a disabled state.
What would be the recommended approach for implementing this?
In our current design, birthright roles are assigned with the required access profiles and entitlements. The Identity Profile is used primarily to manage account enablement, disablement, and deletion across the various lifecycle states. As a result, the Access Profiles section within the Identity Profile has been left empty.
This approach has worked as expected until an identity transitions to the Deprovisioned lifecycle state. At that point, the account that should remain disabled is instead re-enabled. Additionally, the associated role is removed, while the access profile remains assigned. What makes this more confusing is that the Deprovisioned lifecycle state is included in the role assignment criteria. Also, this lifecycle state is configured with the status Inactive (long-term).
Given this behaviour, I’m unsure whether the configuration is aligned with best practices, or whether the Inactive (long-term) status introduces different processing behaviour that I may be overlooking.
I would appreciate any guidance on the recommended design pattern or best practice for handling this type of deprovisioning scenario.
re-enabling the access is the expected behaviour when deprovision lifecycle state is included in the role assignment criteria. I recommend check why the deprovision state is included in the role assignment criteria.
The reason the role assignment included in Deprovisioned LCS is because this account should should exist in Deprovisioned LCS but should be disabled, however it get enabled after a while violating the config in Identity profile for this LCS which is configured as Disabled.
This is a non-AD based Learning Connector (D2L), with all HTTP operations, including enable and disable, configured and functioning correctly. In fact, the connector behaves as expected for all other Lifecycle States (LCS), which are either Active or Inactive (Short-Term) Identity states.
The discrepancy only appears when the identity transitions to the Deprovisioned LCS, which is configured as Inactive (Long-Term). In this state, I have specified that the D2L account should be disabled (while accounts on other sources are deleted). The access profile was originally granted through a Birthright Role, so there is no corresponding Access Profile configured within the Lifecycle State tab.
The following behaviour is observed when the user enters this LCS:
The role is removed, even though its membership criteria include the Deprovisioned LCS. However, the associated Access Profile is not removed, despite being granted through the role.
The D2L account is initially disabled but is automatically re-enabled a few hours later.
Event logs show entitlement removal activity, which appears to be triggered by the role removal.
My objective is simply to keep the D2L account in a disabled state while the identity remains in the Inactive (Long-Term) Lifecycle State. Based on the observed behaviour, it appears that the Inactive (Long-Term) state is performing additional processing beyond what is expected.
I hope this provides some useful context and helps clarify the issue.
Yes it got update, enable, disable HTTP operations defined.
In fact it is perfectly working fine with another LCS, the only difference that LCS with this deprovisioned LCS is the Identity State. In deprovisioned LCS the Identity State is Inactive(long term), where as in the other it is inactive (short term).
Does inactive (long term), try to remove the roles regardless eventhough role qualifies the role criteria?
I believe I have now resolved the issue and am able to retain a single account while also ensuring that the account remains disabled, which was the key requirement for deprovisioned LCS which is longterm-inactive.
If I am not mistaken, the statement below appears to be related to the issue I was experiencing:
“Source accounts are not disabled or deleted if the source includes an access profile listed in the Access Profiles tab.”
To resolve the issue, I made the following changes:
I ensured that no access profiles were assigned directly in the Lifecycle State Access Profiles tab. Instead, only the required entitlements and access profiles were granted through roles.
For the role associated with the Deprovisioned Lifecycle State, the membership criteria contained an AND condition, even though only a single group was being evaluated. I changed this condition to OR.
After making these changes and running a scheduled identity refresh, all Lifecycle States began functioning as expected, including the Deprovisioned Lifecycle State.
I wanted to share this in case it helps explain the behaviour or assists anyone encountering a similar issue.