Add metadata in config to indicate a config requires admin, non-admin, system

[SteveL-MSFT]

Summary of the new feature / enhancement

Some configurations may require admin or may require user to not be admin to apply. The actual configuration can use an AssertionGroup to a resource that checks if user is elevated/root. However, it might make sense to also have this info in the metadata property of the configuration, but this would just be documentation.

Proposed technical implementation details (optional)

• Is this metadata doc only or used by DSC for static analysis?
• Runtime check could be a resource to check user context and used with AssertionGroup, for example
• Should have well-defined tags for resources that require elevation, etc… and how would this feed into the metadata or at all?

[denelon]

WinGet package manifests have: https://github.com/microsoft/winget-cli/blob/296a53dbedffabfd14b60f43e1a7abae0200cb75/schemas/JSON/manifests/v1.6.0/manifest.installer.1.6.0.json#L512

Something similar for a DSC Resource would mean errors caused by mismatched elevation requirements could be caught before execution.

[JohnMcPMS]

A consistent request from our customers is to have a single configuration document that can be used in multiple contexts to achieve the overall desired configuration. On Windows, this means the ability to group the configuration elements to run under the SYSTEM user and an individual user (as well as that user's unrestricted token if applicable). I believe that this also means that ability to state the desired action to take when the orchestrator is not run in the desired context; for example, being able to simply ignore the entire group. They are generally accepting of the need to apply the configuration multiple times, so long as it is a single document. I believe that the major reason for this single document stance is to shift the burden of splitting the document more into the authoring side, removing the need to store/transport multiple data streams in the backend systems. Given the benefits of having a tool like this beyond these customers though, the additional requests are minimal and thus this seems like the best method to provide.

My understanding of the requirements on any such group to provide this behavior are thus:

1. The ability to specify the target user context in which the group applies a. With analogous values to: SYSTEM, User, RestrictedUser, UnrestrictedUser b. SYSTEM targets the actual SYSTEM user context on Windows. c. User targets any standard user context d. RestrictedUser targets the restricted token for a standard user when UAC is enabled e. UnrestrictedUser targets the unrestricted token for a standard user when UAC is enabled
2. The ability to specify the behavior of the group when not in the desired context a. With analogous values to: Ignore, Switch b. Ignore would result in a no-op when attempting to Set the state, and presumably a no-op when attempting to Test as well. c. Switch would run the group's sub elements in the target context is possible.

My expectation on the average use case would be:

resources:
  - name: SYSTEM group
    type: DSC/UserContextGroup
    properties:
      UserContext: SYSTEM
      WrongContextAction: Ignore
      resources:
        ...
  - name: User group
    type: DSC/UserContextGroup
    properties:
      UserContext: User
      WrongContextAction: Ignore
      resources:
        - name: Restricted user group
          type: DSC/UserContextGroup
          properties:
            UserContext: RestrictedUser
            WrongContextAction: Switch
            resources:
              ...
        - name: Unrestricted user group
          type: DSC/UserContextGroup
          properties:
            UserContext: UnrestrictedUser
            WrongContextAction: Switch
            resources:
              ...

With the goal of providing two effectively independent configuration documents via the SYSTEM and User targeting groups that would be Ignored when not in the correct context. In the User context, we then request that the group invoke some resources in the alternate context via Switch. Most likely, any automation here would run the user context portion from an unrestricted token to prevent the need to accept the elevation request. The ability to use Switch when targeting/running from SYSTEM could be unsupported/implemented later.

[SteveL-MSFT]

For now, we'll implement https://github.com/PowerShell/DSC/issues/54 to handle elevation/non-elevation, but anything more, we recommend WinGet team to implement this group resource.

[SteveL-MSFT]

For the "fail-fast" case where a config doesn't have mixed context, we should also standardize on meta-data in the configuration similar to https://github.com/PowerShell/DSC/issues/253#issuecomment-1960556072:

metadata:
  Microsoft.DSC:
    RequiredSecurityContext: Elevated

Same enum values as https://github.com/PowerShell/DSC/issues/54