October 24, 2014 Leave a comment
As everybody knows the two FIM built-in accounts “Forefront Identity Manager Service Account” and “Built-in synchronization account” will bypass all AuthZ workflows.
So by default you are not able to do approvals for example on changes by these accounts.
In addition you cannot have AuthZ workflows on set transition, only Action workflows are allowed here.
But a customer wants to final delete accounts 180 days after deactivation.
This action should be approved by a helpdesk administrator because there are some manual and non-technical tasks to do before this should happen.
Hmmm, so with the above restrictions, what to do?
I used the FIM PowerShell Activity a lot in that customer solution, and I remember that changes done by this activity runs in the context of a normal user account (from FIMs perspective) which is the service account of the FIM web service (svcFIMService in my case).
In order to allow updates to the FIM service by this account via the Export-FIMConfig and Import-FIMConfig cmdlets I created this account in portal and grant permissions to the necessary objects.
If it does not exists, just create this account with the following attributes set:
- AccountName (sAMAccountName from FIM webservice account in AD)
- ObjectSID (from AD)
(You should manually create this account, as I got into trouble when I try to synchronize this account to FIM portal)
How to use this:
I created a workflow with the PowerShell activity which sets an attribute I created on user account, let’s say DoFinalDelete, to a value of true.
I created a MPR which fires these workflow when users transition into my set “Users with disableDate older than 180 days”.
(Btw. this disableDate is also set by a powershell workflow activity, as you can imagine)
Now I’m able to create an MPR with an AuthZ workflow to approve this change of the account svcFIMService and after that can trigger all other MPRs and workflows I want.
So in my scenario I import the DoFinalDelete attribute to MV and trigger deprovisioning on the objects in the provisioning code of my MV extension using the DeprovisionAll() method, which then triggers all the defined actions on my MA’s regarding to their deprovisioning configurations.
So once again this great piece of code “FIM PowerShell Activity” from Craig Martin and Brian Desmond is like a Swiss army knife for me. (thx guys)
You can do nearly all with PowerShell and only have to maintain one custom activity in FIM Portal, which made upgrades and migrations much easier.