Easier managing local administrators via Windows 10 MDM on Windows 10 20H2 and later

This week back to the Windows platform. This week is again about managing local administrators on Windows 10 devices. Even in a modern world, there can still be a need for managing the local administrators on a Windows 10 devices and often that still requires more flexibility than provided with the default Azure AD functionality. I’ve also discussed managing local administrators already multiple times – either by using a Windows 10 MDM policy setting or by using proactive remediations – and this time it’s about a new method that became available in Windows 10, version 20H2 and later. That method is a new Windows 10 MDM policy setting. In this post, I’ll provide an introduction to that new policy setting and I’ll show how to use that new policy setting. I’ll end this post by having a look at the configuration result.

Introduction to the policy setting

Starting with Windows 10, version 20H2, a new policy setting is introduced that adds more options for managing the memberships of local groups. Those management options are the option to add, remove, or replace members of local groups on a managed device. That new policy setting is named LocalUsersAndGroups and is available within the Policy CSP. Before, the RestrictedGroups policy setting could be used for managing the membership of local groups. However, that policy setting only enables the option to replace members of local groups. This new policy setting provides more management options and is also the new recommended policy setting for managing the memberships of local groups. It provides a relatively easy method for adjusting members of local group without the need to overwrite all the existing members. That was often a reason to use custom scripting.

Important: The LocalUsersAndGroups policy setting and the RestrictedGroups policy setting should not be used together, as the behavior will be unpredictable. Both policy settings will be applied in no particular order.

The configuration node, of the LocalUsersAndGroups policy setting, in the Policy CSP is LocalUsersAndGroups/Configure and the configuration should contain a XML definition like the following.

<GroupConfiguration>
    <accessgroup desc = "">
        <group action = ""/>
            <add member = ""/>
            <remove member = ""/> 
    </accessgroup>
</GroupConfiguration>                            

Within the example XML definition above, the different elements are used to specify the following information.

  • <accessgroup desc> – This element specifies the name or SID of the local group that should be configured
  • <group action> – This element specifies the action that should be taken on the on the local group that should be configured. Those actions can be update (U) or restrict (R) and can be used to achieve the following:
    • U – This action can be used to add or remove members of the local group that should be configured
    • R – This action can be used to replace current members of the local group that should be configured 
  • <add member> – This element specifies the name or SID of the member that should be added to the local group
  • <remove member> – This element specifies the name or SID of the member that should be removed from the local group. This element is not processed when the restrict action is used.

Tip: When specifying domain accounts or groups, use the fully qualified account or group name. When specifying Azure AD groups, use the group SID and when specifying Azure AD users, use AzureAD\{UPN}.

Configuration of the policy setting

The LocalUsersAndGroups policy setting can be configured by using a custom device configuration profile. That profile requires two important properties, the OMA-URI and the value. The OMA-URI is already known and the value requires an XML definition that might require some more explanation.

Construct the LocalUsersAndGroups XML

The best method to show the additional functionality of the LocalUsersAndGroups policy setting versus the RestrictedGroups policy settomg, is by using that policy setting for adding or removing members to a local group. In this post that policy setting is used for adding an Azure AD user and group to the local administrators group on a managed device. To achieve that, the different elements should be configured with the required values. Most of those values are pretty self explainable, with the explanation in the introduction, with the exception of the values of the Azure AD user and group. For those values the following information and format is required.

  • Azure AD user – The Azure AD user is relatively simple, as that’s basically just adding a prefix to the UPN of the user account. For the example user that would be AzureAD\tvanderwoude@petervanderwoude.nl
  • Azure AD group – The Azure AD group is a bit more challenging, as that requires the SID of the group. The SID of the group can be found by using Graph Explorer, querying the /groups endpoint, searching the response for the required group and looking at the securityIdentifier property. For the example group that would be S-1-12-1-934997727-1097630882-1590523563-2481977683

Together with the more self explainable elements, the values of the Azure AD user and group can be used to create the following XML definition. That content of that XML definition can be used as the value of the OMA-URI.

<GroupConfiguration>
    <accessgroup desc = "Administrators">
        <group action = "U"/>
            <add member = "AzureAD\tvanderwoude@petervanderwoude.nl"/>
            <add member = "S-1-12-1-934997727-1097630882-1590523563-2481977683"/> 
    </accessgroup>
</GroupConfiguration>                            

Tip: If needed, it’s possible to use the SID (S-1-5-32-544) instead of the group name (Administrators).

Distribute the LocalUsersAndGroups XML

The best method for applying the configuration on Windows devices, is by using a custom device configuration profile. That profile can be used for configuring the OMA-URI with the constructed value. The following nine steps can be used for creating that profile and assigning it to the required users or devices.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the custom device configuration profile
  • Description: (Optional) Provide a valid description for the custom device configuration profile
  1. On the Configuration settings page, click Add to open the Add Row page. On the Add Row page, provide the following information and click Add (and click Next back on the Configuration settings page)
  • Name: Provide a valid name for the OMA-URI setting
  • Description: (Optional) Provide a valid description for the OMA-URI setting
  • OMA-URI: ./Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure
  • Data type: Select String
  • Value: Provide the created XML definition
  1. On the Scope tags page, configure the required scope tags click Next
  2. On the Assignments page, configure the assignment to the required users and/or devices and click Next
  3. On the Applicability rules page, configure the applicability rules (think about the existence of this policy setting for only the ProBusinessEnterprise and Education edition and the existence of this policy setting for only the 202H2 version and later) and click Next
  4. On the Review + create page, verify the configuration and click Create

Note: From an administrator perspective the status of the configuration in the Microsoft Endpoint Management admin center should eventually show as Succeeded for the managed devices.

Configuration result

Once the custom device configuration profile has been applied, it’s time to have a look at the results of the configuration on a device with Windows 10, version 20H2 or later. The easiest method to view the results of the configuration, is by having a look in the Event Viewer together with a look at the members of the local administrators group. The Event Viewer will show the applied configuration and its results (as shown on the left in Figure 2). The members of the local administrators group will show the newly added members (as shown on the right in Figure 2).

Besides looking at the configuration result, it’s good to know that the custom device configuration device profile will be reapplied automatically, within 8 hours, when the configuration was changed by the user (behavior starting with Windows 10, version 1903).

Note: The other members of the local administrators group are the default administrator, the primary user and the SIDs that are representing the Global administrator role and the Device administrator role.

More information

For more information about managing local administrators on Windows devices, refer to the following docs.

31 thoughts on “Easier managing local administrators via Windows 10 MDM on Windows 10 20H2 and later”

  1. Useful post, thank you.
    If this only works for 20H2 devices, it could be a long time before that is the only version out there in some organisations. My preferred method currently is to use group policy preferences. This is very flexible and easy to use. Hopefully the method you outline here will be just as easy eventually.

    Reply
    • Hi Gary,
      This is indeed specific to Windows 10 version 20H2 and later. Also, keep in mind that this is also focussed on using MDM for managing the configuration. This is not applicable when you are still using GPO’s for configuring your devices.
      Regards, Peter

      Reply
  2. So in my testing, I could not use the R method replace to dump out the built-in Administrator account (even though it is disabled on my workstations). Otherwise works fine for my uses!

    Reply
  3. When using this on Windows 10 Business devices (20H2) the configuration is rejected by licensing. The eventlog shows this error:

    MDM PolicyManager: Policy is rejected by licensing, Policy: (Configure), Area: (LocalUsersAndGroups), Result:(0x82B00006) Unknown Win32 Error code: 0x82b00006.

    Both tried it with a user licensed with Microsoft 365 Business Premium and a user licensed with Enterprise Mobility + Security E3.

    Any experience with that error? As far as I know this should work on Windows 10 Pro, Education, Enterprise and Business.

    Reply
  4. Same problem as Martijn,
    MDM PolicyManager: Policy is rejected by licensing, Policy: (Configure), Area: (LocalUsersAndGroups)

    Strangely it works on one tenant with EMS E3 but not on a different tenant with M365 Business Premium.

    Reply
  5. Hi thanks for this! For this administrator route I don’t seem to be able to bypass polices I set for users. I have put users in a security group which I have set policies to block certain things like personalisation but they also seem to be blocked for the admins using this custom policy. How would I create a admin account which I log into which doesn’t pick up any of the user polices I have added to others that use the device. Having a admin that bypasses these things is good for troubleshooting in my opinion and especially for those who work in schools. Currently our local admin or domain admin can log into devices without any policies with the current set up of AD on prem but would love if this can be done with AAD/intune too as we are looking to make the move to use intune. Im probably being a novice and this can be achieved quite easily I just dont know how. Any ideas?

    Reply
  6. I have the same issue has Martijn. I suspect it is related to the Windows 10 Business SKU as this works fine on 2 other machines with Windows 10 Pro. Even though, according to documentation Win10 Business is supported.

    I’ve had the support ticket raised with Microsoft for this but they appear just as confused.

    Reply
  7. Hi Peter,
    Quick question for you – I’m trying to decipher how (and if) I can translate this into the new Endpoint Manager Settings Catalogue.

    Any ideas?
    Regards, David

    Reply
  8. I also have the ‘Policy is rejected by licensing’ error.
    It seems that the policy is applied when a 20H2 version is first configured. Changes afterwards to the policy are rejected with the licensing error.
    Versions that are not 20H2 and are later updated to 20H2 when already enrolled in Intune (in my case 2004 to 20H2) never get this policy working.
    It seems like a bug somewhere in Intune or Windows 10.

    Reply
  9. I think the information of Microsoft is wrong and you need Windows 10 Enterprise to apply this policy. I tried on a Windows 10 Pro 20H2 machine and the event logs said “Policy is rejected by licensing”.

    Reply
  10. I was able to recreate this in my environment for both Administrator and Hyper-V Administrator local groups. The policy is applying successfully (and I can see the Azure AD SIDs added once the policy applied- just like Peter’s screenshots). However, I am not seeing the permissions update. e.g. standard user is not elevated to admin even though its in the AAD group membership.

    Has anyone else tested this recently? My PC is WinVer 20h2. I did see this working in 2004.

    Reply
      • Hi Peter, I did some more testing to confirm my use case. I referenced your previous article “Managing local administrators via Windows 10 MDM” and was able to effectively add AAD users to local admin group (prior to WinVer 20h2). I also used this approach for the HyperV administrators, which is another requirement for my environment (one AAD group needs HyperV access and NOT full administrator). My hope for 20h2 is to use group assignment for both of these Windows 10 device roles. I was able to get administrator group working, but I am not seeing permissions update for the user that I have assigned to the HyperV role. I will raise a MS premiere ticket for this.

        Reply
        • Thank you for the explanation, Ryan. When you are using the group SID as a member and the permissions are not applying, then a support case is the best route for now. I’m curious about the response.
          Regards, Peter

          Reply
  11. I’m having an issue with this CSP in my testing on 20H2 devices. I’ve created the policy to add a group to the Administrators and I see the policy applying and adding the AAD group SID. When I attempt to elevate with administrator privileges it won’t accept the account credentials for users in the AAD group. If I add individual user accounts(azuread\user), it works as expected. We really would like to get the AAD user groups working.

    Has anyone been able to get this working in their environment?

    Reply
  12. Hi Peter,

    I have logged a case with Microsoft 2-weeks ago and today have received the following message

    I would like to inform you that this issue was reported to us few days back and we engaged the product team to look into it. After reviewing the details, this has been defined as OS bug and the ETA from the OSG bug owner is 90 days to fix. I would request you to wait for sometime and then try this policy on Windows 10 Business devices once this bug gets fixed from the Windows side.

    I will continue to monitor and reply back as I hear something.

    Regards
    David

    Reply
  13. What OMA-URI do i need to use?

    ./Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

    or

    ./Device/Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

    Now im using the first one but im receiving the following error message:

    0x87d1fde8
    Remediation failed

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.