How to fix broken permissions for Windows scheduled task?

Question

I've got a custom scheduled task set up in Windows Task Scheduler, but somehow the access control permissions for it have gotten broken. Even though I'm logged in as admin, I can't change the user account the task is running under, or delete the task, or disable it. I am getting "Permission Denied" errors instead.

The machine is running Windows 10 Pro 1803. It is a workgroup machine, not in a domain.

The task is one I created myself (it just launches a PowerShell script twice a day, nothing fancy), so it shouldn't be subject to any anti-tamper mechanisms like the Windows Update-related tasks.

I have tried the following:

• Launch 'Scheduled Tasks' from the Start Menu, by right-clicking and selecting "Run As Administrator". I get The user account does not have permission to delete this task.
• Delete the task by running the PowerShell command Unregister-ScheduledTask -TaskName 'My custom task', from an Administrator-level PowerShell prompt. This returns Access is denied.
• Launching the MMC snap in using .\psexec -i -d -s mmc taskschd.msc. If I understand correctly, this should be launching the Task Scheduler console snap-in as SYSTEM. I can't delete the task using this, either - I get the same error message as when running using the normal user account, launching the snap-in as Administrator.

Can anyone give me some pointers as to why this might be happening, and how I can fix it?

Where are the task definitions stored? File system, or registry, or elsewhere? It seems like I might need to fix some corrupted security info.

Solution

All tasks definitions stored in both

• Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\*

and

• Filesystem: C:\Windows\System32\Tasks\*

Security Descriptors exists both on files in filesystem and stored in the registry for each task:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\<TaskName>\SD

This registry value is in the binary form and it seems that there is no decent UI for it.

• You could get retrive it via Powershell and Task Scheduler API (https://docs.microsoft.com/en-us/windows/win32/api/_taskschd/index):

  $ts = New-Object -ComObject "Schedule.Service"
  $ts.Connect("localhost")
  $task = $ts.GetFolder("").GetTask("<TaskName>")
  Write-Host $task.GetSecurityDescriptor(0xF)
  

  • This method return security descriptor in SDDL format

BUT:

• I've got into the same problem and it seems that the problem is not directly related to task permissions, but to hardlinks on tasks created during Windows 10 upgrade
  • Check folder C:\$WINDOWS.~BT\NewOS\Windows\System32\Tasks_Migrated\ whether it contains hardlinks to task's files in C:\Windows\System32\Tasks
  • I've removed all hardlinks from C:\$WINDOWS.~BT\NewOS\Windows\System32\Tasks_Migrated\ and after that Unregister-ScheduledTask work as expected.

UPDATE:

I've finally investigated a problem with "broken" tasks permissions in Windows 10. It has nothing common with permissions at all and looks like an unexpected outcome of security patch.

11/06/2019 Microsoft released a patch for CVE-2019-1069. This patch fixed a vulnerability of the Task Scheduler and to exploit it an adversary need to create a hardlink to a file associated with some task.

• If this patch installed you can't change/enable/disable/delete Task with Task Scheduler API (schtasks, powershell -ScheduledTask, COM "Schedule.Service") if associated task file in C:\Windows\System32\Tasks\ have any hardlink.
• Windows Feature update during installation do "Tasks migration" procedure and create hardlinks to all tasks in the folder C:\$WINDOWS.~BT\NewOS\Windows\System32\Tasks_Migrated\ and this could be a reason why tasks cannot be deleted.
• Deleting all hardlinks solves the problem.

Comments

[Dominykas Mostauskis]

Here's a thread about finding hardlinks for a given file. By the way, Tasks_Migrated was in C:\WINDOWS\System32\ in my case. Either way, this didn't solve my problem.

[Andir]

Sorry, forgot to mention an easy way to check hardlinks with fsutil hardlink list <filepath>.

[LeeM]

by the way, if anyone wants to return the SDDL for the task in a readable format, you can use ConvertFrom-SddlString. Instead of write-host, do: ConvertFrom-SddlString -Sddl ($task.GetSecurityDescriptor(0xF)) -Type RegistryRights

[will824]

Unfortunately none of the proposed solutions worked for me, except the advice of running CMD as system user using MS Sysinternals PsExec and then opening the TaskScheduler from that prompt, as instructed in the following post: tenforums.com/backup-restore/…