locked
What account are workflow activities run as? RRS feed

  • Question

  • I am trying to write a workflow activity that uses remote powershell. I have already successfully written an activity that uses local powershell. I have also successfully used this remote powershell code elsewhere, so I know it works in principal.

    The error I get is "Access denied". When I open a remote powershell session manually using the FIM service account it connects fine.

    I have found some mention in forums that you will get an "Access denied" if the code is being run by NETWORK SERVICE. Microsoft.ResourceManagement.Service.exe is running as the FIM service account, but wpw3.exe is running as NETWORK SERVICE. Which account actually runs the workflows?


    http://www.wapshere.com/missmiis
    Tuesday, August 17, 2010 7:03 AM

Answers

  • To properly answer this question, we need to first clear up some terminology

    A piece of code (any code, including activities) "run-as" a certain user. That means it's run under particular user context. You can impersonate someone else if you know their credentials or have a delegate kerb token. Notice you can't just impersonate anyone, i don't think even domain admin has that power. You can check the running user by doing watching "$user" in Visual Studio when you are debugging.

    In FIM, workflow are running as the FIMService service account (unless you impersonate someone else in your code).

    Setting the ActorId does not run-as the activity as someone else. Take the ReadResourceActivity as an example, if you set the ActorId to "Anthony", the code running as FIMService service a/c will try to check if "Anthony" has permission to read that object and return appropriately.

     

     

    So for Carol's original question:

    Your WF should be run as FIMService service account. I would suggest you troubleshoot your issue by writing a sample app that makes the same remote PS call, and run that app as the FIMService service account. If you have trouble getting that to work, the PS forum might fit better for your issue

    • Proposed as answer by nTony Ho Wednesday, August 18, 2010 7:31 AM
    • Marked as answer by Carol Wapshere Wednesday, August 18, 2010 12:06 PM
    Wednesday, August 18, 2010 3:12 AM

All replies

  • Well I changed the Sharepoint app pool to run under a domain account, as described in the installation doc. But I still get an "Access denied" error when trying to open my remote powershell session from the workflow code.
    http://www.wapshere.com/missmiis
    Tuesday, August 17, 2010 2:54 PM
  • Can you modify the PS source to print out the current user?

    I.E

     

    [environment]::UserName
    

    Tuesday, August 17, 2010 3:42 PM
  • We have WF that queries AD and we ACL access to the directory as the FIM Web Service account so I would start there.  Internally the WF runs based on the ActorID present which typicaly defaults to "Inherit" but I think this is purely an internal operation within the FIM Portal.  So, from an MPR perspective, you need to understand which Actor your WF is running as and build your MPR's to suit.  Once you're past the MPR layer, WF running against external sources should run as the FIM WS account.

    The built-in Function Evaluator is hard coded to run as the internal FIM Service account well-known GUID which is not actually the same as the service account powering the web service (confusing I know).  You can also hardcode or pick one of the well-known GUID's to run your WF under. See my post here:

    http://www.identitychaos.com/2010/08/fim-2010-well-known-guids.html


    Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]
    Tuesday, August 17, 2010 3:51 PM
  • Yeah, that's more of a Kerberos thing and shouldn't affect the way the WF are running.
    Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]
    Tuesday, August 17, 2010 3:53 PM
  • Thanks for the environment.username tip. The WF is running as my FIM service account, so I really don't get why I'm getting this access denied message. :-|
    http://www.wapshere.com/missmiis
    Tuesday, August 17, 2010 6:29 PM
  • Carol,

     

    Looking at my MPRs and the creator attribute value, it seems to run in the context of who made the request. I logged in as account A, made a change to B, which triggers the MPR. I looked at the request that I had just made, it showed the creator being account A. So it seems like the actorID attribute that Brad mentions is the requestor by default. It seems like if you wanted the FIM Service to be the creator, you would have had to log in to the portal using that account or changed the actorID property in the custom workflow. I hope this helps.

    Wednesday, August 18, 2010 2:48 AM
  • To properly answer this question, we need to first clear up some terminology

    A piece of code (any code, including activities) "run-as" a certain user. That means it's run under particular user context. You can impersonate someone else if you know their credentials or have a delegate kerb token. Notice you can't just impersonate anyone, i don't think even domain admin has that power. You can check the running user by doing watching "$user" in Visual Studio when you are debugging.

    In FIM, workflow are running as the FIMService service account (unless you impersonate someone else in your code).

    Setting the ActorId does not run-as the activity as someone else. Take the ReadResourceActivity as an example, if you set the ActorId to "Anthony", the code running as FIMService service a/c will try to check if "Anthony" has permission to read that object and return appropriately.

     

     

    So for Carol's original question:

    Your WF should be run as FIMService service account. I would suggest you troubleshoot your issue by writing a sample app that makes the same remote PS call, and run that app as the FIMService service account. If you have trouble getting that to work, the PS forum might fit better for your issue

    • Proposed as answer by nTony Ho Wednesday, August 18, 2010 7:31 AM
    • Marked as answer by Carol Wapshere Wednesday, August 18, 2010 12:06 PM
    Wednesday, August 18, 2010 3:12 AM
  • Thanks for the tip Tony. I made a console app and copied in all the code, changing the Me.parameters into constants. It works when I run it as administrator and then I get Access Denied when I use the fim service account. SO while I haven't tracked down the reason yet, at least it's a lot simpler to troubleshoot without Sharepoint and FIM service in the way!

     


    http://www.wapshere.com/missmiis
    Wednesday, August 18, 2010 7:01 AM
  • hi Carol

    I am not definitely NOT too good at remote PS. I am shooting blind here but that's something what i will try: "create a brand new domain user and use that account for PS remoting". The reason might want to try this is that it's possible that the FIMService service a/c is so locked down that the it might not have necessary permission to do so. The few other things u can try is to add the account to the DOMAIN ADMIN group... (notice u need to logoff and logon for that)

    Wednesday, August 18, 2010 7:34 AM
  • Well there you go, just one of those stupid things. I was testing with "localhost". That works fine through a regular powershell session, but apparently doesn't work so well through code. Once I started connecting to another server it connected fine.
    http://www.wapshere.com/missmiis
    Wednesday, August 18, 2010 10:49 AM