Is it possible to spawn processes as different users? RRS feed

  • Question

  • Hi all,

    I have taken a new job and I have a hunch that one of my first tasks will be to figure out how to develop a method of spawning processes as multiple users, like you can do with Unix (by running a program as root that will su to a user, requiring no password to be entered).

    For example, Joe Schmoe runs an engineering tool that can run an analysis job remotely on a different machine as him.  Jill Schmoe does the same thing and it runs as her.  The process that runs on that remote machine will need to run as an administrator account, and have the ability to switch to both Joe and Jill, or whoever else is a valid network user.  I need to develop this and I'm thinking it's not going to be easy.

    I'm new to Windows development, so I figured I'd shoot this question to you fine folks before I really start digging.  So far, Google hasn't returned much that seems helpful.  Thanks a lot in advance.

    Monday, October 29, 2007 12:48 AM

All replies




    Please find the method Start on Process class at the location http://msdn2.microsoft.com/en-us/library/sxf2saat.aspx


    Please mark the reply as answer if helpfull.





    Monday, October 29, 2007 3:30 PM
  • Gaurav,

    Thanks for your reply, but that method requires the password to be specified.  What I'm looking for is a way to bypass the requirement to know the password, which sounds insecure, but can be implemented properly in a secure environment.  On Unix, the "root" user can switch to any user without a password prompt.  If a normal user tries to "su" to another user, it prompts for the user's password.  This isn't true for root.  This allows a daemon that is running as "root" to spawn jobs as any valid network user that is located in the local passwd file, or NIS.  I need to know if there is a way that the "system" user on Windows, or some other user, has the ability, or can be granted the ability, to run processes as any user in this fashion.  I would be ok with this being some type of privilege specified in Windows, or doing it programatically.

    Monday, October 29, 2007 3:44 PM
  • A little, at first glance, it appeared to be a method of securing applications to have access (or not have) to certain system resources.  I'll look a little deeper into it, but I'm not sure that what I'm looking for will be found in this.
    Monday, October 29, 2007 6:10 PM
  • It's been a long time since I've written code for Unix but I believe that is not secure and I hope you can't find an answer on Windows! Part of a secure system is auditing who-did-what, IMO what you are asking for circumvents this very important audit. However....to avoid that you could:
    1. If Joe & Jill were to provide their passwords (careful about holding passwords) you could configure a service (or COM+) application per user. Rubbish solution if you have a number of users.
    2. The remote services requires the user to invoke it, i.e. the remote service can then impersonate the calling user. http://support.microsoft.com/kb/306158.

    I realise that isn't what you asked for and perhaps there is a better method, I would ask if it is really necesssary to have the specific user or can you use roles together with the users name?

    Tuesday, October 30, 2007 7:25 AM
  • Hi, think about it this way.  You have a Windows compute farm.  You have hundreds of users that are working at their local desktop PC, submitting jobs to the farm.  The farm is managed by a server that will direct the job to an available machine in the farm.  You obviously do not, and can not, have all of those users' jobs ran by the same account that is running the farm server software.  The jobs are executed in project directories that are owned by the submitter, and they will be creating files that need to be owned by the job submitter as well.  So, the farm server software needs to make sure that each job is running as the user who submitted it.

    On Unix, the farm server software runs as root, which has the ability to switch to the job submitter without a password prompt.  In terms of security, yes, it can be dangerous if not handled appropriately.  Companies who run Unix usually have policies written around who has access to the root login.  I certainly don't want this to become a Unix versus Windows argument in terms of which is more secure.  I just want to bring something to Windows users that is not there today that just happens to be something that is available to Unix users today.

    Is there perhaps some method of taking the existing credentials that were obtained on the local desktop PC and pass them over to the compute farm server?  Excuse me if that's a dumb thought, I'm 100% new at Windows application development.

    Tuesday, October 30, 2007 5:24 PM
  • I see what you're trying to do but I don't believe there is way of doing it exactly the same without either impersonation, service accounts or storing passwords. I do something similiar within the application I'm currently working on, but it uses it's own security model. I've been trying to see if Active Directory or kerberos Ticket could help but I can't see it. The best non-impersonation solution I can see is to use Scheduled Tasks, one per user - this still requires you gain their password though Sad


    Tuesday, October 30, 2007 6:00 PM
  • Janbur,


    I would have to agree with pkr2000 looking at the evolution of the thread would be to use impersonation or service accounts and if you want to log who initatied the job in the DB for audit purposes include the user that started the process.




    Tuesday, October 30, 2007 6:17 PM
  • I would like to thank all who replied to this post.  After hearing everyone's feedback and researching it until my eyes crossed, I have reached a point where I'm accepting that this cannot be done in this manner on Windows.  I'm going to go back to the drawing board and consider using a secure storage mechanism for the password and passing that to the authentication mechanism when needed.  Again, thanks a lot.

    Tuesday, October 30, 2007 8:17 PM
  • Before you do that, I'd like to know WHY do you want to execute a process remotely? Do you already have an application that you wan to run on behalf of your users or do you start designing it now? You can create a server application using WCF and have it impersonate the calling user's credentials quite easily. If you can't use .NET 3.0 you can do the same using Enterprise Services. The concept is the same as hosting your application in J2EE.


    Wednesday, October 31, 2007 12:52 PM
  • The user isn't instigating the request so impersontation, without holding passwords, is difficult - if not impossible. Also creating services for every user would be impractical. The crux of the problem is that you want to assume that an admin has access to everything and therefore should be able to assume the identity of another user without needing to know their password. It is a useful property, but one that I don't believe is supported by Windows.


    Wednesday, October 31, 2007 1:59 PM
  • Having the admin assume the identity of any user is a big security risk. Requiring administrator priviledges for an application is another big security risk.


    You say that the user is not instigating the request. How is the request created? Are you trying to execute batch jobs on a specific schedule? If so, you may be able to create batch jobs on the remote computer's Scheduler service. The batch jobs will execute using the credentials provided when the job was created. The downside is that each of the user accounts will have to be granted the Log On As Batch priviledge - and that you will have to create a schedule for each user.



    Wednesday, October 31, 2007 5:14 PM
  • re: Admin rights, it's more subtle than that. It isn't that the Admin has the rights to do the task per se, it's that the admin has the rights to invoke a process as another user or rather on another users behalf. Granted (pardon the pun) IMO it is still a security risk but that's what this question is really about, and Windows doesn't support doing it (I believe). However, I can certainly see why you'd want to do it and, as I've previously said, I do use the same approach within an applications security model.


    re: User Creation: The user would "subscribe" to a service, supply only their user name (not password). The admin (being all powerful) would invoke the process as that user, no-one would ever need to know the users password - but it isn't supported.


    re: Scheduled Tasks, If you read back through the post you can see we've covered that, it's not about running batch process. You don't really want 10,000 scheduled tasks, one for each user would you, plus it still requires that the user provides their credentials in order to create the task?




    Wednesday, October 31, 2007 5:23 PM
  • pkr2000 has the idea exactly.  My task is to work on a Windows port of a Unix application that performs user impersonation in a manner that does not involve manually typing in passwords (ie the Unix root account switches to the user behind the scenes without any interaction whatsoever).  So, being this is a port, I cannot easily go into a huge migration into the .NET environment.  I need to take the existing C++ code that is written for Unix and work with that.  I have found a couple of utilities that I might be able to make use of for some of this.  For example, lsrunas is like the Windows runas command, except you can pass the password to it as a command line argument.  The Windows runas command always prompts the user for it, and there's no way to redirect it into the prompt.  So, if I securely store the password in a database, encrypted, and decrypt it behind the scenes for the call to lsrunas, I think I can make the system work similar to how the Unix one works, just with a different impersonation mechanism.
    Thursday, November 1, 2007 3:53 PM
  • If you're going to store the passwords then I'd recommend using the LogOnAs (have I got the right name?) Win32 API (in the URL I gave). It's easy to use and should do the job for you.


    Thursday, November 1, 2007 5:22 PM
  • Cool, thanks!  I'll check that out in the API to see if it's something that I can utilize.

    Friday, November 2, 2007 6:07 PM
  • Oops not quite the correct name..
    Declare Function LogonUserA Lib "advapi32.dll" (ByVal lpszUsername As String, _
    ByVal lpszDomain As String, _
    ByVal lpszPassword As String, _
    ByVal dwLogonType As Integer, _
    ByVal dwLogonProvider As Integer, _
    ByRef phToken As IntPtr) As Integer

    Saturday, November 3, 2007 9:08 AM