sudo-type tool for windows



Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

We have a domain account that we use to do our automated builds. This
account is what our IT calls an "Application" account; it's similar in
concept to a "Service" account. We want individual developers to be able to
invoke the batch file that starts the build process. In order to succeed,
the process has to run on a particular machine (Windows XP Pro) with the
credentials of the Application account. For obvious reasons, we don't want
multiple people logging in with a common account name and password. Indeed,
we cannot share the password of the Application account. How can we
accomplish what we need to do?

In Unix, we could run a setuid script. Does an analogous capability exist
in Windows?

We created a Scheduled Task that runs with the Application account
credentials. The Scheduled Task runs at its appointed times without problem.
But, even if we grant Read & Execute privilege to the group to which all
developers belong, developers with admin privileges cannot successfully run
the Schedule Task (using the Run option on the tasks's context menu).

RUNAS.EXE requires an interactively-typed password, doesn't it? Is there
any way to redirect the input of RUNAS so that we can put it in a batch file,
to which developers won't have read access?

I've heard PSEXEC from can take an account name and
password on the command line. Is this a reliable tool?

Does MS SFU (Services for Unix) add any such capability to XP with NTFS? I
know Cygwin doesn't support su, or sudo, so presumably doesn't support
setuid, either.

I'd really rather not store a password in a file, even if the file has no
read access to non-administrators. Passwords change, and then you have a
maintenance headache, because undoubtedly, once we arrive at a solution,
there will be lots of instances where we employ that solution.

Any other ideas?

Thanks for your help.



Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

This feels lame--but how about having your scheduled task run say,
every minute, but have the script itself make some external check to
see whether it should actually do the build? I'm thinking stash a file
in a magic directory, script sees the file, does the build & then
deletes the file?

There are APIs that will raise events when a directory/file changes--if
you wanted to get fancy you could use that to make the process more
naturally reactive. I'm thinking .net's FileSystemWatcher object (tho
I believe that wraps analagous win32 functions, so I imagine they're
reachable otherwise). Probably to do that though, you're looking at
writing a windows service.

Okay, forget it--this is lame. Someone else will give you good advice,
I feel sure...

Good luck.