Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On a Windows server which is in a domain, I have a script I run from scheduled tasks.

I want this script to be run under a mydomain\peter user account. It is simple to do it with scheduled tasks, if you know Peter's password. And once done, the script stops when Peter decides to (or has to) change his password.

On Linux, a cron job can be run with whatever user account without having to know the corresponding password. And root can run anything on behalf on another user (with su and sudo).

Any way to do this with Windows?

My need is for a old Windows 2003 server, but I can manage to run it from another computer.

share|improve this question
The obvious question is "why does the script need to run as Peter anyway?" What can Peter do that the local system account can't? – Harry Johnston Sep 24 '12 at 22:25
Running a program with least privilege is often the right thing to do. This script has to delete files. Running it as Peter allow to be sure it will not destroy the server in case of error. – Gregory MOUSSAT Sep 25 '12 at 10:03
up vote 3 down vote accepted

This is exactly the use-case for service-accounts, though. Why not set up a domain user service account for this scheduled task?

It's probably what you should be doing anyway, rather than running scheduled tasks or scripts as a real user. You can disable password expiry on the account so that the job doesn't fail whenever Pete has to change his password, for another benefit.

share|improve this answer
That's already what I do. This is not perfect but it works. – Gregory MOUSSAT Oct 2 '12 at 21:24

This is not supported on Windows. For accountability reasons you're not supposed to impersonate other users, not even as an administrator.

share|improve this answer
Actually it is possible using constrained delegation. But not in an unconstrained fashion, that would enable running any arbitrary code. – Greg Askew Sep 25 '12 at 14:49

OK, since you only want to reduce your access rights (rather than actually running as Peter per se) you may have some options.

In Windows 7 (and Windows Server 2008 R2) the task scheduler supports this directly (via the "Do not store password" option) but I don't think there is any built-in equivalent for Windows Server 2003. Running the task this way on a different machine probably won't help because you don't get network access.

It can be done in software, though, even on Windows 2003, via the CreateRestrictedToken Win32 function. A Google search found a piece of software called ulimitnt which appears be able to do what you want (via the -RSid option). Note that I've never used this program so I can't vouch for its reliability.

Using this approach, the script only has access to files that grant access to both local system and to Peter. (Note that the local system account implicitly belongs to the Administrators group, so if Administrators has access that will be sufficient.)

share|improve this answer
Thanks for the ulimitnt link, but impossible to use -Rsid option on Windows 2003 (not tested elsewhere) : an error is displayed. – Gregory MOUSSAT Sep 27 '12 at 21:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.