So the standard setup SQL(HR)-> FIM -> AD IT wants to approve new accounts before they are created in AD, I understand the Sync process bypasses all AuthN & AuthZ workflows. We're trying to keep away from writing a custom workflow so just wanted to run this by some one to see if something like it is feesable. Sync process goes from SQL -> FIM and puts the person in a set based on an Attribute that's the "Not Approved Set" There's a MPR that runs a AuthZ workflow for the IT Approval. Upon approval the user is moved from the "Un-Approved" set to the "Approved Set" (both attribute based) and then Synced into AD. Is this secanario even possible, or will the AuthZ workflow still get bypassed because it's the FIM Sync Service running the show?

You should be able to do this with R2. You're going to need a custom activity though. I would do something like this: Create a user in the Service DB that's called like "New Account Approval Requestor"Create an AuthZ WF & MPR that requires that changes to the Approval State attribute by New Account Approval Requestor be approved by HR Have Sync put people in the Service DB as "Not Approved"On Transition In to this set, fire your custom activityIn your custom activity, drop an UpdateResourceActivity. You need to a) Update the Approval State to "Approved" b) Set your Actor ID to that new user you created c) There is a /new/ property on the activity that toggles whether or not the activity's action is susceptible to AuthZ. Make sure you set this property accordingly My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

I'm afriad that won't work. As long as the actor is the sync engine or the FIM service account it won't trigger any AuthZ workflows. The request has to originate from a different account (and if using a custom activity make sure ApplyAthorizationPolicy is set to true).

I'm afriad that won't work. As long as the actor is the sync engine or the FIM service account it won't trigger any AuthZ workflows. The request has to originate from a different account (and if using a custom activity make sure ApplyAthorizationPolicy is set to true). Are you referring to my post or the OP's?My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

OP I normally use the administrator account that gets created on install in the custom activity as it always has the same GUID (easier to migrate between environments) and normally has the required premissions already.

Brian and Mark THANK YOU!!! both!!!! Brian; with your suggestion what if: SQL (HR SYNC) runs, new users come in a un apporved, they go to the un-approve set, the Un-Approved Set MPR kicks off an Out of the box Action workfow (which should work for the sync service Actor ID) the action workflow uses the Ensync custom workflow activity to change the ActorID to say the Admin Account (per Marks suggestion so It can use the same GUID in my Dev and Prod enviroment), then moves it into the Set for the AuthZ workflow, the AuthZ workflow should run since the ActorID is changed right? or am I totally missing something here? The root of the issue is the ActorID being the FIM Sync Actor ID which bypasses AuthN and AuthZ activities correct? Sorry I'm still learning this and it's a bity of a curve. Thanks Again! Jonathan

Jonathan- I haven't used the Ensynch activity you mention, but, if it uses a custom Actor ID before updating the attribute, then this should work.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Brian thanks! I'm going to give it a shot in my dev enviroment and report back. Brian Thanks again for all your help!!

Any one know the XPATH to the ActorID?

Any one know the XPATH to the ActorID? It's the ObjectID of whatever you want to be the actor e.g. //Target/ObjectID. Double check on the spelling/case though...My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com