ITaskFolder::SetSecurityDescriptor — supported COM flags and exact SDDL preservation

Question

ITaskFolder::SetSecurityDescriptor — supported COM flags and exact SDDL preservation

Michael Fringer 0

Please clarify the supported Windows Task Scheduler folder-security API contract.

Environment: local Task Scheduler COM API, elevated Windows PowerShell 5.1.26100.9711. Windows edition and OS build have not been independently verified in the retained record.

One folder-creation operation supplied:

Required: O:BAG:BAD:P(A;;GA;;;BA)(A;;GA;;;SY)

Creation returned successfully. The first ITaskFolder::GetSecurityDescriptor(7) returned:

Observed: O:BAG:BAD:PAI(A;;FA;;;BA)(A;;FA;;;SY)

That first readback failed our exact-security acceptance check. Execution stopped. No SetSecurityDescriptor operation has been executed, and no semantic-equivalence exception is authorized.

Questions:

Which LONG flags values are supported by ITaskFolder::SetSecurityDescriptor for an existing folder? Please provide folder-specific COM definitions, distinct from getter information flags, task-registration flags and RPC flags.

What access rights, privileges and execution context are required to set the supplied owner, group and DACL?

Can setter/getter operations preserve the exact owner/group, protected DACL, absence of AI, Administrators-before-SYSTEM ACE order and original GA rights masks?

Does Task Scheduler necessarily transform the supplied P/GA descriptor into the observed PAI/FA descriptor? If so, which documented operation or representation rule causes this?

Is there a documented method to enforce the exact required returned descriptor? If unsupported, please identify the specific limitation.

The published method documentation describes flags without enumerating applicable values. Exact setter flags and exact round-trip enforceability therefore remain unknown to us.

Please provide Microsoft engineering clarification or an authoritative SDK/documentation reference. We are requesting contract clarification, not permission-equivalence advice or instructions to bypass exact verification.

0 comments

1 answer

Your answer

Answer 1

Hi @Michael Fringer ,

I did not find a published folder-specific flag list or an exact-descriptor round-trip guarantee for ITaskFolder::SetSecurityDescriptor. Your recorded failure followed folder creation; the setter remains untested in that record.

Regarding supported setter flags, the folder COM documentation does not enumerate the LONG flags values. I also checked the ITaskFolder declaration in Windows SDK 10.0.26100.0, in taskschd.h; it declares that parameter without a folder-setter flag enumeration. GetSecurityDescriptor(7) selects owner, group and DACL, which does not make 7 a setter flag. TASK_DONT_ADD_PRINCIPAL_ACE is documented for the registered-task setter. The RPC specification separately defines task/folder flags, but does not document their mapping to this COM parameter.
Regarding access and execution context, ITaskService::Connect uses the current token when no user is specified. The RPC specification requires write access to the target. General Windows security-information rules specify WRITE_DAC for setting a DACL, WRITE_OWNER for owner/group, and READ_CONTROL for reading those components. Owner assignment has additional SID and privilege conditions; for example, SetNamedSecurityInfo documents owner-token eligibility, SeRestorePrivilege, and the ownership-taking privilege. These general rules do not supply the complete access-check contract for the folder COM setter. Elevation alone does not show that every required right or privilege is present.
Regarding preservation, your readback retains owner BA, group BA and the BA-before-SY ACE order, and still contains P. It adds AI, representing SE_DACL_AUTO_INHERITED, and changes the rights tokens from GA to FA. See Security Descriptor String Format and ACE Strings. That readback fails your stated exact requirement. It cannot establish a preservation guarantee for future setter/getter calls.
Regarding whether the transformation is mandatory, I found no Task Scheduler documentation requiring this particular P/GA to PAI/FA transformation. The SDDL definitions describe the fields, but do not identify an operation that must introduce these changes. The creation observation alone also cannot identify the internal cause.
Regarding enforcement, I found no documented folder-setter option that guarantees absence of AI, retention of the original generic masks, and exact preservation of all the other requested fields. The getter protocol describes retrieving security information and encoding it as SDDL, without an exact-input preservation guarantee. The specific documentation gap is therefore both the folder COM flag definition and its preservation limits. A definitive support statement still requires clarification of those two points.

For an attributable clarification, submit these five questions through documentation feedback on the folder setter page or your Microsoft support channel. Include the existing descriptors and an independently verified Windows edition/build. This asks for the missing contract without relaxing your exact-security acceptance check.

If you have any further questions, feel free to ask or leave a comment, and if you found my explanation above was truly helpful or informative to you, I would greatly appreciate it if you could follow this guidance so others with the same issue could benefit as well.

Thank you.

Michael Fringer 0 Reputation points

2026-11-02T14:24:44.96+00:00

Thank you for the detailed response. It helps clarify the documented limitations and confirms that our observed readback does not satisfy the exact security-descriptor requirement.

However, the underlying issue remains unresolved. We still lack a supported folder-specific setter flag definition and a documented means of preserving or enforcing the exact required descriptor.

I appreciate the clarification and will retain the issue as unresolved pending an authoritative answer on those points.
Gatlin Le (WICLOUD CORPORATION) 1,385 Reputation points Microsoft External Staff Moderator

2026-11-03T02:30:04.9033333+00:00

Hi @Michael Fringer ,

My earlier response identified gaps in the published documentation, but it did not establish the supported folder-specific setter flags or a supported way to enforce your exact descriptor.

One distinction is important here: the absence of published documentation does not establish that the requirement itself is unsupported. The current ITaskFolder::SetSecurityDescriptor documentation describes flags only as "a value that specifies how the security descriptor is set"; it does not enumerate the applicable values or document an exact-preservation guarantee. I do not have an authoritative reference that closes either gap.

For an authoritative contract clarification, if you have Microsoft support coverage, you can use Windows Developer Support and reference this thread. The request should specifically ask for the supported LONG flags values for ITaskFolder::SetSecurityDescriptor, the required access rights, privileges, and execution context, and whether any supported call sequence can make GetSecurityDescriptor(7) return exactly O:BAG:BAD:P(A;;GA;;;BA)(A;;GA;;;SY).

If exact preservation is not supported, the clarification should identify which required descriptor properties cannot be preserved and the applicable product or API limitation.

The existing creation and readback results can accompany that request, together with an independently verified Windows edition and OS build. I would also keep explicit that SetSecurityDescriptor has not been called in the recorded test, so the creation/readback result is not treated as evidence of setter behavior.

This keeps the requested clarification tied to your exact acceptance requirement rather than substituting permission equivalence for it.

Thank you.
Gatlin Le (WICLOUD CORPORATION) 1,385 Reputation points Microsoft External Staff Moderator

2026-11-05T02:16:30.9966667+00:00

Hi @Michael Fringer ,

I wonder if there is any update on this post. If you have any question, feel free to reach out. I'm happy to support you.

Thank you.
Gatlin Le (WICLOUD CORPORATION) 1,385 Reputation points Microsoft External Staff Moderator

2026-11-09T02:31:26.19+00:00

Hi @Michael Fringer ,

As I haven’t heard back from you for a while, I’ll leave this thread here for now. If you still need assistance later, feel free to ask or leave comments so I can continue supporting you.

If the information I shared earlier was helpful, your community interactions can help make relevant solutions easier for others to discover in the future.

Thank you for your understanding.