I just discovered, well actually another OneIdentity forum user (OneIdentity Employee) discovered, how to get ARS polices to apply to Deprovisioned accounts.
I’d thought for ages that all the policies stopped working when the account was deprovisioned. Generally this has been fine and I’ve not been bothered by it but a couple of times the SD have enabled a deprovisioned account.
The problem now is, that none of the ARS policies work on this account or so I thought and this can be a big problem especially if the account in question is a personal functional account that used to be linked to a personal employee account. As part of the leaver process all related accounts to the personal employee account are disabled and deprovisioned together and most of the attributes are cleared. Enable that account and it’s no longer linked to the HR data feed, i.e the JLT process is broken. As none of the policies apply any restriction or automation also does not work on this account and of course the deprovision option can’t be selected as it’s already been deprovisioned.
It would be a good feature if ARS prevented an account being enabled when it was in the deprovisioned state. We can of course use an ARS policy to do this but wait, ARS policies don’t work on deprovisioned accounts or do they?
it turns out that a workflow works regardless of the deprovision status and a deprovisioning policy also works on deprovisioned accounts, I always wondered why they has a provisoning and deprovisiong choice when creating a new policy. Now I know. Clearly there are overheads in watching every change to objects in AD so I’m guessing that to reduce the load they decided that in most instances why would we want to trigger an ARS policy on a deprovisioned account so they created 2 policy types. Provisioning only works on accounts where the edsvaDeprovisionStatus attribute is not present and Deprovisioning polices work on both.
This actually opens up a whole new way of thinking about the polices you want to apply and when.
I already have a script that prevents the SD enabling an account if it was disabled by the HR data feed. The quick fix then is to recreate that as a deprovisioning policy and now the SD can’t enable the account in any other way than by undo deprovision. Then all the required identity attributes will be restored, all the ARS policies apply and every one is happy, for a while at least 🙂
By the way did you also know that by default Managed Units do not contain deprovisioned users but there is a membership rule, right at the bottom of the list ‘Maintain deprovisioned Users’ that adds them back in.
I think the only things that can’t be configured to work on deprovisioned accounts are group family and dynamic groups, and I see no reason why I would want to override that rule anyway.