Using Delegation in Scheduled Tasks
This blog is about the ability in Windows 7 and Windows Server 2008 R2 to apply a SID to every scheduled task and use that SID to apply permissions elsewhere in the Operating System.
Services already have this feature from Vista and newer. The idea is the same; take the simple name for the service (or in that case of scheduled tasks in 7/R2 the path to the scheduled task) and compute a predictable SID based on that name. Have a look at the permissions applied to C:\Windows\System32\LogFiles\Firewall to see this in action. On the permissions of this folder, there is an ACE for a “group” called MpsSvc, which is the short name for the Windows Firewall service. In this way, even though the service is set to start as “Local Service”, not all other services which also run as this same account can see into the Firewall logs, only the firewall service itself has access.
So every scheduled task can have a SID computed for it – this new feature is described here:
https://msdn.microsoft.com/en-us/library/ee695875(v=vs.85).aspx
And the way to locate what the predicable SID for a given service name is to run:
schtasks /showsid /TN “TaskName”
With this SID, you can now assign permissions to resources. For example, you could use icacls to apply permission to a folder, below we are granting an NT TASK (SID starts with S-1-5-87) modify permission to the folder C:\SomeFolder:
icacls C:\SomeFolder /grant *S-1-5-87-xxxx-yyyy-zzzz:(M)
Now, if you go and setup your task in the GUI, and run these commands, you will see icacls report back:
No mapping between account names and security IDs was done.
What went wrong?
First you need to make sure that the scheduled task is configured for Windows 7 or Windows Server 2008 R2 and is using either “Network Service” or “Local Service”:
Then you need to make the task use the Unified Scheduling Engine so that it registers the SID with the list of “well known SIDs” for the system. But there is no check-box for this setting, and it is disabled by default. What to do?
Export your task as an XML file, locate the line which reads:
<UseUnifiedSchedulingEngine>False</UseUnifiedSchedulingEngine>
And change that “False” to “True”:
<UseUnifiedSchedulingEngine>True</UseUnifiedSchedulingEngine>
With that changed, remove your task and import the XML file you modified above.
Because the SID is a predicable calculation of the path to the task, so long as you recreate the task with the same name and in the same folder, the SID will remain the same and your icacls command will now work as expected, and only that scheduled task will have access to the file or folder to specify.
The Unified Scheduling Engine leverages the Unified Background Process Manager (UBPM), which is described further here:
Comments
Anonymous
December 30, 2011
I wish Microsoft had added this type of functionality to v1.0 of the Task Scheduler so previous versions could take advantage of it. I'm actually developing a tool that will let you delegate rights to start and stop scheduled tasks using a centralized web based management tool. It's called System Frontier (http://systemfrontier.com). Since there haven't been any comments before mine, my first guess is that most people are just handing out local admin access to solve this problem. That's definitely asking for trouble when it comes time to report on appropriate access.Anonymous
September 11, 2014
Thanks for nothing Jay.Anonymous
November 02, 2017
A service can run as its virtual account, and the system allows assigning rights and privileges to this virtual account. Task SIDs should also be virtual accounts under which the task can run with specific rights and privileges. For example, if a task runs as the "LOCAL SERVICE" well-known group, then by default it isn't allowed to create symbolic links. I shouldn't have to grant this privilege to "LOCAL SERVICE".- Anonymous
November 20, 2017
The comment has been removed
- Anonymous