I have a workflow which executes once the user leave date is 1 day in the past. The idea of the workflow is to delete the active directory user account.
However, for some reason I get an error 400 Bad Request. I am not sure what further logs I can check, to see why the delete is failing.
The workflow is configured like this:
Get the identity account IDs
Use the action “Manage Access” to remove all access. The option “Access to Manage” is $.getAccess.accessItems
This step is actually already failing.
Use the action “Manage Accounts” with action “Delete Account” and input is AD account IT
This step is also failing, with 400 error.
Perhaps I am doing something wrong? In the test environment it worked fine, so it seems that there is some small difference with production environment that I don’t know.
One thing that I think is that in AD the user has child-elements of some sort. The service account has permission to do delete the AD account, when I performed a manual powershell execution. I believe for this I did Remove-ADObject -Identity $DN -Recursive
Perhaps someone has had a similar issue or knows what I have misconfigured.
Workflow help ( Workflow Actions - SailPoint Identity Services ) says “The Delete option is only applicable to accounts on flat file sources.” I don’t know if that was changed when they rolled out “Delete Accounts” as part of lifecycles. If it has, then the Workflow documentation needs to be updated.
We ran into the child-elements issue, we were unable to resolve it via ISC. In our case all of the child-elements were for ActiveSync, which hadn’t been used for years. So we wrote a script to remove those child-elements from all accounts.
Like Carl has already mentioned, the delete account option is only available for flat file sources and will throw 400 errors for any source that’s not that. There’s also a delete account endpoint via an HTTP call, but that only supports deleting the link of the account not deleting the account on the source.
As far as I know, the only way to trigger an account deletion through ISC is through the inactive (long-term) lifecycle state. Maybe you could update these users LCS to get the delete account option to function correctly?
Interesting that the delete seems to not work in the workflow. In our sandbox environment it worked before we went live - I only noticed that it isn’t working now in production after our go-live. Perhaps there is some other configuration which I’m unaware of, which actually performs the delete.
If workflows aren’t able to delete AD Accounts, what would be the best way to remove source accounts which aren’t delimited file? Or is what you describe (inactive long-term lifecyclestate) the way to delete the accounts? I assumed that this removes the account only in ISC but not in the source application. Would need to look into this more.
I would check few things since you said the Manage Access is failing in the first place. Please check whether your Workflow owner has required permission to run the getAccess action, you can compare your sandbox Workflow owner’s user level with Prod.
Cloud Rule: You can either use Before Provisioning Rule or Service Standard Before Provisioning rule which obviously comes with a disclaimer to get an approval for Prod usage.
I would prefer to use the SailPoint Delete account feature in UI.