I have several identities with cloudLifecycleState set to Active, but their Active Directory accounts are still disabled.
The AD source is configured in the Identity Profile under Specific Sources > Enable Accounts, so I was expecting ISC to trigger an enable operation when the identity became active as always.
However, no enable request seems to be generated.
Has anyone seen this behavior before? Are there any known conditions that can prevent ISC from triggering the account enable action even when the source is listed in Enable Accounts?
Were these identities in the Active lifecycle state when their AD accounts were correlated? And were the AD source accounts disabled when they were correlated? As far as the Identity Profile “settings for previous accounts”, ISC triggers the enable accounts operation when you move into the lifecycle state, not at any other time.
If you want identities in the Active lifecycle state to have their AD accounts enabled outside of the time that the lifecycle state changes, then you will need a workflow to search on something like @accountsaccounts(source.name:“Active Directory” AND disabled:true) AND attributes.cloudLifecycleState:active - that’s from memory and needs to be tested. From those results, the workflow could iterate over them and use the manage accounts action to enable the AD accounts.
A word of warning on that approach though, if you have AD accounts that someone has disabled manually, they too will be enabled. You could get around that by creating another lifecycle state - manualOverride or something like that.
Thank you so much for your answer, this makes much more sense to me now.
In our case, the lifecycle state actually changed correctly, but at that exact moment we had a AD connectivity issue, so the enable operation went into error. What surprised me is that once the connectivity was restored, ISC did not retry the enable operation automatically afterward.
How do you usually handle these kinds of scenarios on your side? Do you generally implement a workflow as you mentioned?
My only concern with that approach is, as you said, that it could also re-enable accounts that were intentionally manually disabled. Especially in a production scenario, if this issue happens at scale, you could end up having to re-enable a large number of accounts in bulk afterward, so I’d be really interested to know what best practices people usually follow for this.
Since the enable operation is only triggered on the LCS change, it does not have anything to trigger a retry. In cases where a source was unavailable, you could setup a “retry” process by creating a workflow using the Provisioning Completed trigger. Be sure to setup a filter on the trigger, something like the following: $.accountRequests[?(@.provisioningTarget == ‘Source Name Here’ && @.accountOperation == ‘Enable’ && @.provisioningResult == ‘failed’)]
The only problem with this approach is that it will try and fail repeatedly until the source comes back online. You may want to include a Wait step in the workflow to avoid excessive workflow executions. So something like this:
Hi Torry,
It is a problem with the ‘fire & forget’ trigger.
If you don’t have the workflow module on your tenant, you can always set up a powershell script on the IQserver that runs on a schedule to check if Active users have disabled accounts, then just move/enable them that way
Hi @torry_salamat ,
When did you configure this “The AD source is configured in the Identity Profile under Specific Sources > Enable Accounts, so I was expecting ISC to trigger an enable operation when the identity became active as always.”
If already user is in active state and if you made this configuration and if you are not seeing lifecycle state change event in logs, then it is possible that enable account operation may not be triggered