Task security settings differ from the corresponding task file?!

[tardezyx]

After testing around with the TaskSecurity it has security settings which differ from the corresponding task file in C:\Windows\System32\Tasks...

I am not sure if this is a bug or intented as I have not the slightiest clue what the source of the task security settings is when it is not the corresponding task file. This is especially irritating as settings and rules which are applied/removed to/from TaskSecurity are adopted to the corresponding file but not recognized by TaskSecurity vice versa.

Steps to reproduce the behavior:

1. Perhaps you need to give yourself FullControl first:

   Task task = GetTask(taskPath);
   TaskSecurity taskSecurity = task.GetAccessControl();
   taskSecurity.AddAccessRule(new TaskAccessRule(yourSID, TaskRights.FullControl, AccessControlType.Allow));
   task.SetAccessControl(taskSecurity);

2. Use TaskSecurity to set the task protection without preserving inherited rules:

   Task task = GetTask(taskPath);
   TaskSecurity taskSecurity = task.GetAccessControl();
   taskSecurity.SetAccessRuleProtection(true, false);
   task.SetAccessControl(taskSecurity);

3. Add any other explicit rule:

   Task task = GetTask(taskPath);
   TaskSecurity taskSecurity = task.GetAccessControl();
   taskSecurity.AddAccessRule(new TaskAccessRule(userSID, TaskRights.ReadData, AccessControlType.Allow));
   task.SetAccessControl(taskSecurity);

Now, go to the corresponding file (in Windows Explorer or whatever) and remove the rule you added under step 3 manually by the standard Windows dialogues.

Then check both the protection and rules inside your code with:

• TaskSecurity.AreAccessRulesProtected -> is false although we already set it to true in step 2, why?
• TaskSecurity.GetAccessRules(true, false, typeof(System.Security.Principal.SecurityIdentifier)) -> the rule we manually removed in step 3 is still existing, why?

I expected that both, the task and the file, are synchronously managed. That means that any security setting which is added/removed to the task is also adopted to the corresponding file. That works. But any change on the file is not recognized by the TaskScheduler->TaskSecurity. So, what is the source of the TaskSecurity settings? Why does it differ from the file while it adopts everything to the file? Furthermore, as already said, the protection is set but it is not correctly stored/loaded in TaskSecurity, at all - it simply stays at false = not set.

• Host Windows version (the one running the code): Microsoft Windows 10 Enterprise LTSC 1809.17763.1 x64
• Library version: v2.10.1 with net452 (only referenced Microsoft.Win32.TaskScheduler.dll)

[dahall]

The file permissions for V1 tasks are separate from the task permissions. V1 tasks only support a subset of settings and actions and were marked obsolete by Microsoft back in Windows 7. Task permissions on V1 tasks (those that show up as files in C:\Windows\System32\Tasks) are not supported at all. The library actually eats that exception but probably shouldn't.

[tardezyx]

Oh, does that mean I should not use/check task security/permissions for those tasks at all (with your library) and instead should only adjust the file permissions directly?

[dahall]

Correct. Use file permissions for V1 tasks. Use TaskSecurity for V2 tasks.

[tardezyx]

Alright, thanks. One last question: How can I distinguish those? Whenever a corresponding file exists it is a V1 task?

I especially wonder about C:\Windows\System32\Tasks\Microsoft\Windows\WaaSMedic\PerformRemediation for which I can give myself full folder and file access and ownership but still am not able to change the task.

If I adjust the task security (with your library) of PerformRemediation I am also able to adjust the task afterwards. That means, PerformRemediation is not a V1 task but a file exists (for which the security settings are adopted). I hope you understand this confusion :)

[dahall]

V1 tasks always show up with a ".job" extension and have a different internal schema. You'll find files named the same for all tasks in Win10/11. Permissions for the task itself are actually stored in the registry.

[tardezyx]

Thanks! As your library handles the registry values and adopts any changes to the file, it is just an organisational issue if someone adjusts the task files directly.