Managing local administrators via Windows 10 MDM

This week is all about managing local administrators via Windows 10 MDM by using restricted groups. There has been many requests for a post like this after I wrote this post about creating local user accounts. And I have to admit that this post has been on my backlog for a long time. Better late than never, I think. Also, I’m definitely not the first to write about this subject, but I do think that I have some new insights that can be really helpfull. In this post I’ll start with an overview of the options for configuring local administrators on Azure AD joined (and Microsoft Inune managed) devices and reasons for using restricted groups, followed by the steps for configuring restricted groups. I’ll end this post by looking at the end-user experience.

Overview

When discussing the local administrators on Azure AD joined devices, it’s often about the Global administrator role and the Device administrator role. These roles are by default local administrator on Azure AD joined devices. Users can be added to the Global administrator role like any other administrator role. Adding users to the Device administrator role, however, is a different configuration. Users can be added by configuring additional local administrators on Azure AD joined devices. These two roles have one thing in common and that is that those roles apply to all Azure AD joined devices. No exceptions. However, there might be scenarios in which it’s required to limit the local administrators on a device, or scenarios in which it’s required to differentiate the additional local administrators for different groups of devices.

Another option to manage local administrator on Microsoft Intune managed devices – which are often also Azure AD joined – is by using restricted groups. For this it’s possible to use the RestrictedGroups section in the Policy CSP. That contains a single node that can be used for adding local administrators (or for adjusting any other existing local group). When specifically looking at managing local administrators, make sure to keep the following in mind:

  • By using restricted groups, the provided local administrators will replace the existing local administrators.
  • By using restricted groups, which is a configuration node of the Policy CSP, the provided local administrators will be reapplied, within 8 hours, when changed by the user (behavior starting with Windows 10, version 1903).
  • The default local Administrator account must be part of the custom configuration, as it’s required for applying a custom configuration.
  • Every Azure AD joined device contains two SIDs (one representing the Global administrator role and one representing the Device administrator role) that are by default part of the local administrators.

Note: By default, on Azure AD joined devices, the user joining the device to Azure AD is also local administrator on the device.

Configuration

By knowing the available configuration options and the different configurations it’s time to look at the configuration steps. The five steps below walk through the configuration. Throughout those configuration steps, I’ll provide the required information regarding the OMA-URI and the XML-value that should be configured.

  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 blade
  3. On the Create a profile blade, provide the following information and click Create to open the Create profile blade
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Create profile blade, select Settings to open the Custom OMA-URI Settings blade
  2. On the Custom OMA-URI Settings blade, click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade)
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership
  • Data type: Select String
  • Value: The value should be an XML. That XML should contain a groupmembership-element and that groupmembership-element should contain an accessgroup-element. That accessgroup-element contains the local group that should be adjusted and that accessgroup-element contains member-elements that contain the users that should be added to the local group. For an example see the XML below.

Note: The RestricedGroups section can be used to add members to any local group on a device.

<groupmembership>
	<accessgroup desc = "Administrators">
		<member name = "Administrator" />
		<member name = "AzureAD\pvanderwoude@petervanderwoude.nl" />
		<member name = "AzureAD\tvanderwoude@petervanderwoude.nl" />
		<member name = "S-1-12-1-2091167666-1329275207-1706997396-915002206" />
		<member name = "S-1-12-1-2447031348-1225114094-1633491097-1064162478" />
	</accessgroup>
</groupmembership>

End-user experience

Now let’s end by having a look at the end-user experience. The best place to look is in the Properties of the Administrators group. That group should reflect the provided configuration, as shown in Figure 4.

This configuration is the most common to be used when the primary user of the device is not a local administrator. A method to provide additional support to the end-user, without the requirement of adding that specific account as a local administrator on all devices.

It’s also good to keep in mind that starting with Windows 10, version 1903, the settings of the Policy CSP actually refresh. When, for whatever reason, the configuration of the local administrators was adjusted, the configuration will refresh within 8 hours. The next device check-in will take care of that.

Another place for verifying the configuration, would be to look at MDM Diagnostic Report. That report will show an overview of the RestrictedGroups setting configuration.

More information

For more information about managing local administrators, refer to the following articles:

.

12 thoughts on “Managing local administrators via Windows 10 MDM”

  1. Hey Peter,

    Awesome article, thanks for providing us with the information. Maybe this is obvious to some but I have one question. If one would want to add multiple different restricted groups with different groups as members, would that require one new configuration profile per restricted group? Or should it work like this (with one single XML and one Device Configuration Profile)? Having multiple OMA/URIs in the same profile leads to conflict (which is logical).

  2. Hi Peter

    Many thanks for another very informative article.

    Anyway, I have set this up for a client using the restricted groups CSP.

    Can you confirm the following:

    User enrolls device and becomes local admin on the device
    RestrictedGroupsCSP deployed with and Azure AD Admin in the XML
    This then removes the user who enrolled the device from local admin group
    Should admins wish to install software NOT deployed by Intune they can elevate when the standard user is logged on

    Info appreciated

  3. Hi Stuart,
    That’s possible, but feels a bit wrong. If you don’t want the user to be local administrator, I would look at an Autopilot profile that creates a standard user.
    Regards, Peter

  4. Hi Peter

    I understand what you are saying, but these are existing / in use / live devices that could NOT be wiped.

    Does this validate my approach?

    Stuart

  5. Hi Stuart,
    Yes, I think that it makes sense in that scenario. Just keep in mind that I haven’t tested that scenario. I assume that nothing breaks, but I would advise to carefully test that.
    Regards, Peter

  6. Hey Peter,

    Awesome stuff. If I have an Endpoint Protection policy in place that renames the Administrator account, should I use that newer name in this policy? or could I even use the admin SID? Thanks!

  7. That’s actually a really good question, Jesse. I haven’t tested that specific scenario. My guess would be the SID, but that depends a bit on what the CSP is checking for. I am curious what configuration you will end with.
    Regards, Peter

  8. So on my first attempt, the policy was applied after the endpoint protection, and using the newer name worked (one was assigned to machine group, the other user group). I just re-enrolled an Azure AD join machine with both policies assigned to the autopilot device group, and that seems to have worked as well. This is also nice because you don’t have to worry about restarting or CSP refresh interval for the policy to hit.

    This is also really great because now you’re not bound to the Azure device settings guid and only being able to add individual users. Thank you again for the awesome post!

  9. Peter,

    Have created the policy (multiple times all day really) as indicated by both you and MS and every time it will not apply. DeviceManagement Event Logs indicates that Windows was unable to parse the requested XML data. Do you have any idea what this could be?

    Running the latest Win 10 build.
    OMA-URI:

    ./Device/Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership

    data type: String

    Row value:

    I have simplified it to just one of the built-in accounts, same issue.

Leave a Comment

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