Remote jobs on Windows needing "Run As" rights

1. Windows RunAs version uses some undocumented back-doors to lunch processes on behave of other users. The documented way requires that the user, who is lunching the process, must have "Act as part of the operation system" privilege and the user, on behave of which the process is launched, must have "Logon as a batch job" privilege.

2. As the message states the problem is in insufficient privileges, most likely your user account (interactive, which you use to open the console window) doesn't have "Act as part of the operation system" privilege.

3. Many people assume that local admin or domain admin users have all possible privileges. This assumption is wrong, they don't have all privileges, but they can enable such privileges if required. Neither "Act as part of the operation system" or "Logon as a batch job" are enabled for anybody by default.

Hope this helps.

PS. Windows version of RunAs cannot be used in unattended mode, because it is designed to display interactive password prompt.

As I said the accounts, both the domain account (me) and the scheduler account (local to the machine) have both rights on this machine (Act as part of the operatign system, logon as batch job). I have restarted the machine and the runas program still reports the error. Funny enough, if I run the Windows version of runas with the domain admin, I get the same error, because it has not been given the explicit rights, like you said; the domain admin does not have this implicit right.

But, as I said, I have explicitly given both rights to both me and the "scheduler" account and your version of runas.exe still reports the error. Is there any additional logging or debugging I can turn on for the runas.exe program to see what is going wrong where?

Are you giving these permissions locally?

Please note that your domain permissions override your local permissions. So, if you got local permissions, theses permission have no impact as long as you logon to the system as a domain user.

I'd like to suggest trying 2 local accounts with local permissions or 2 domain accounts with domain permissions. Either way it should work.

Okay, using VMware, I created a domain and added two XP machines to it ("master" and "agent"). I created a domain account and a local account on the "agent" XP machine. I gave the domain account both rights (act as part of the OS and logon as batch job) at both the domain and local level and for the local account I gave it both local rights. I get the exact same error using runas.exe on the agent machine logged in as either account and using either account as parameters to the program. I've rebooted everything, including the domain controller to make sure I have the rights assigned to the domain account.

Is there anything else I can check?

This is first indirect reference that you are trying to run the job remotely. The previous conversation was based on the assumption that you are trying to run a simple local job using other user's account.

Can you clarify how you are entering user name/password for the remote job? I mean which account you are entering local or domain and in which format?

Okay, yes, you're right...I was getting ahead of myself. I tried it locally, as we had previously talked about, and get exactly the same error, on "agent" computer (where I'm running the master and using authentication to the machine). As I said I ran "runas.exe" at the command line and got the same messages as well.

Since you are testing this in a virtual machine, i guess it would be no harm for you to post a screenshot of the SET command output in the command console following by RunAs with the parameters you are entering. This will allow us to see what you see on your screen and confirm that we are talking about the same thing. Can you post such screenshot?

Sure thing. I have also included the two property windows from the Local Security settings to show you what it is set to...the domain account has been given the rights at the domain level as you can see.

Just in case if anyone else experiences this issue... It appears that the following 2 privileges are also required for the account running the scheduler

1. Create a token object
2. Replace a process level token