Rights required to run scheduled tasks in Windows 2003
This one has bit me a few times, so I'm documenting it for next time...
In Windows Server 2003 the cmd.exe file is more locked down than previously. Any scheduled task that needs to use it (to run a batch file, for example) needs to run as an account that has rights to read and execute cmd.exe (by default in c:\windows\system32\cmd.exe). This is in addition to any NTFS rights your particular program may need, share permissions when accessing files across the network, and the "Logon as a service" right in the security policy editor (run gpedit.msc -> computer configuration -> windows settings -> security settings -> local policies -> user rights assignment -> Log on as a service). The account should also have the "Log on as a batch job" right, but that should automatically be configured when you configure your task to run as your specified account.
This same idea applies if you are trying to use IIS to launch some process on the server (through a web page, for example) that runs a batch file or needs to use cmd.exe in some way - only when IIS is involved then the account that the application pool associated with your web site is running as needs read and execute rights to cmd.exe.
One of the easiest ways I have found to test that scheduled tasks have sufficient rights is to use the runas command with whatever program you are trying to schedule. For example: runas /user:myAccount "c:\test\myscript.bat"
This way you are running the process interactively and can see any errors that happen - it gets particularly tricky when running processes that use network resources, in which case it is generally best to use an AD account rather than local accounts.
You can either give your specific account rights to cmd.exe, or you can grant those rights to the implicit "Batch" group. The latter will cause any scheduled task to have rights to cmd.exe, regardless of what user it runs under. Obviously the former is more secure. For more information, see http://support.microsoft.com/kb/867466/en-us
In Windows Server 2003 the cmd.exe file is more locked down than previously. Any scheduled task that needs to use it (to run a batch file, for example) needs to run as an account that has rights to read and execute cmd.exe (by default in c:\windows\system32\cmd.exe). This is in addition to any NTFS rights your particular program may need, share permissions when accessing files across the network, and the "Logon as a service" right in the security policy editor (run gpedit.msc -> computer configuration -> windows settings -> security settings -> local policies -> user rights assignment -> Log on as a service). The account should also have the "Log on as a batch job" right, but that should automatically be configured when you configure your task to run as your specified account.
This same idea applies if you are trying to use IIS to launch some process on the server (through a web page, for example) that runs a batch file or needs to use cmd.exe in some way - only when IIS is involved then the account that the application pool associated with your web site is running as needs read and execute rights to cmd.exe.
One of the easiest ways I have found to test that scheduled tasks have sufficient rights is to use the runas command with whatever program you are trying to schedule. For example: runas /user:myAccount "c:\test\myscript.bat"
This way you are running the process interactively and can see any errors that happen - it gets particularly tricky when running processes that use network resources, in which case it is generally best to use an AD account rather than local accounts.
You can either give your specific account rights to cmd.exe, or you can grant those rights to the implicit "Batch" group. The latter will cause any scheduled task to have rights to cmd.exe, regardless of what user it runs under. Obviously the former is more secure. For more information, see http://support.microsoft.com/kb/867466/en-us
posted by Josh at 10:43 AM
0 comments
