Running scheduled tasks as a non-administrator

This post contains information on creating and running a scheduled task on a Windows Server 2003 system with a non-administrative account, following the Principle of Least Privilege methodology.

By default, running a task as a non-administrative poses several problems, but overcoming these problems can help reduce the attack surface and adhere to the Principles of Least Privilege.

To ensure the task will run successfully:

1. Create the user account, either locally or in a domain.
2. Ensure the user is only a member of the users group and any groups required for local and remote resource access (eg. Data fileshares, application access)
3. Ensure the user has local access to the files required to run the command, eg. By default cscript.exe has ACLs requiring either administrative or system/service/batch/interactive access, but the account or NT Authority\Batch will also need access to the script file, and possibly temp and/or log directories. Note that this should be recorded in security templates, allowing for automatic reapplication of security.
4. Create the task and set the task to be run as the newly created account. Note that doing this will automatically grant the 'log on as a batch job' (SeBatchLogonRight) right to allow the task to start.
5. Ensure that the user account has at a minimum, Read, Execute and Write permissions to the schedule .job file
6. Run the task, checking the Scheduled Task log if a result other than success is returned (0x0). Note that if account auditing is enabled, the Security event log should show a Logon Event 528, of Type 4 (LOGON32_LOGON_BATCH) for the newly created account.
   

Notes:

• While developing this process, the Service principal (S-1-5-6) was tested, which was unsuccessful, as the scheduled task is started as a batch job, rather than the schedule (or any other) service.
• IMPORTANT: Ensure that the shell executable (cmd.exe, cscript.exe, powershell.exe etc.) is accessible to the 'NT Authority\Batch' security principle eg. when running the command cscript d:\admin\local\scripts\test.wsf, the 'NT Authority\Batch' security principle must have access to cscript.exe as well as the .wsf script file. Access can also be granted to an account/group rather than batch if this is too permissive.
• When a task starts, the command is created under the security context of the specified user, and the user token has the Batch SID (S-1-5-3) attached. This is a well-known security principal, commonly displayed as 'NT Authority\Batch'
  

References:

Well-known Security Identifiers:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/well_known_sids.asp

Security Identifier Types:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/well_known_sid_type.asp

SECURITY_LOGON_TYPE Enumeration:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/security_logon_type.asp

Audit Logon Events:

http://technet2.microsoft.com/WindowsServer/en/Library/e104c96f-e243-41c5-aaea-d046555a079d1033.mspx

Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.