3

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.

2
  • 4
    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? Sep 24, 2012 at 22:25
  • 2
    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. Sep 25, 2012 at 10:03

3 Answers 3

3

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.

1
  • 1
    That's already what I do. This is not perfect but it works. Oct 2, 2012 at 21:24
6

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

1
  • 2
    Actually it is possible using constrained delegation. But not in an unconstrained fashion, that would enable running any arbitrary code.
    – Greg Askew
    Sep 25, 2012 at 14:49
1

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.)

1
  • 1
    Thanks for the ulimitnt link, but impossible to use -Rsid option on Windows 2003 (not tested elsewhere) : an error is displayed. Sep 27, 2012 at 21:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .