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.
Tip: When using Windows 10 version 20H2 or later, use the method as described in this post.
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.
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.
- Open the Microsoft Endpoint Manager admin center portal navigate to Devices > Windows > Configuration profiles to open the Windows | Configuration profiles blade
- On the Windows | Configuration profiles blade, click Create profile to open the Create a profile blade
- 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
- On the Create profile blade, select Settings to open the Custom OMA-URI Settings blade
- 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\firstname.lastname@example.org" /> <member name = "AzureAD\email@example.com" /> <member name = "S-1-12-1-2091167666-1329275207-1706997396-915002206" /> <member name = "S-1-12-1-2447031348-1225114094-1633491097-1064162478" /> </accessgroup> </groupmembership>
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.
For more information about managing local administrators, refer to the following articles:
- How to manage the local administrators group on Azure AD joined devices – https://docs.microsoft.com/en-us/azure/active-directory/devices/assign-local-admin
- Policy CSP – RestrictedGroups – https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-restrictedgroups
56 thoughts on “Managing local administrators via Windows 10 MDM”
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).
As mentioned on Twitter, it should be possible to use a single XML for multiple restricted groups.
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
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.
I understand what you are saying, but these are existing / in use / live devices that could NOT be wiped.
Does this validate my approach?
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.
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!
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.
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!
Thank you, Jesse and thank you for letting us know the results!
PS: I just learned that starting with Windows 10, version 2004 and later, you can use a SID.
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.
data type: String
I have simplified it to just one of the built-in accounts, same issue.
What are you using as the value? Also, what is the exact error that you receive?
I’m having the same issue as Rob above. I’m using
Errors in event viewer are :
MDM PolicyManager: Merge string, Area: (RestrictedGroups), Policy: (ConfigureGroupMembership), EnrollmentID requesting merge: (18dcffd4-37d6-4bc6-87e0-4266fdbb8e49), Result:(0x800705B9) Windows was unable to parse the requested XML data….Event ID 806
MDM PolicyManager: Merge string, Area: (RestrictedGroups), Policy: (ConfigureGroupMembership), EnrollmentID requesting merge: (18dcffd4-37d6-4bc6-87e0-4266fdbb8e49), Result:(0x800705B9) Windows was unable to parse the requested XML data.. …Event ID 821
Any ideas? I’m stummped.
What does your configuration look like?
I think the brackets may be causing the config to not go through. I’ll try again. I also added a link to an image of the config. Thanks!
Another thing to look at is are the quotes. I’ve often seen that going wrong with copy-and-paste (wrong characters).
You have got to be kidding me; that was the issue. I should have caught that. Thanks!
Very good to hear, ATLRob!
Dear, very good information.
This question is not directly related to your post but I need to implement this and maybe you can help me.
I want to restrict that only one user can login to a device.
My scenario is as follows:
I have 10 user and 10 Windows 10 devices
Everyone in Azure AD as “Azure AD Join”
You could look at restricting users from logging on to the device.
Peter, thanks for your answer.
Yes, that’s my idea but how can I do it ????
I was trying through this:
Data Type: String
but I’m not sure it’s okay.
I want each user to be able to log in to a specific device
The URI looks okay, but I can’t see the value. Probably the formatting made sure it was automatically deleted from the comment.
Hello Peter … here is the value … please comment me, and urgent … Thank you very much.
My value….:”””””” “””
I think you’re using a combination of characters in your value that is blocked on my blog. Could you try a picture?
PS: When it’s really urgent I would advice to either contact Microsoft, or to hire somebody.
This CSP Policy is OS language dependent.
It works fine with english operative system.
I´ve been 3 days working on it and it did only worked when I used the spanish name of administrators group and local administrator user
Administradores and Administrador.
404 event id
Yes! That is correct, Francisco!
@Francisco / @Peter
I am dealing with the same issue ‘Administrators’ and ‘Administratoren’…
2004 will support the use of an SID for the groups and members
How would you deal with the language issue with the groups until 2004 is rolled out?
Would you run a powershell script instead?
How about automatically re-running to ensure compliance?
I would say that the best approach depends on the number of languages that you have to support.
Hi Peter, thanks for the article.
Is there any way to keep the primary user in the local administrator group?
Our requirement is:
1. keep the enrolled user as local admin (added by Autopilot)
2. add some AzureAD groups (SIDs) to local Administrators as well.
We#’re running Win10 2004 on all our devices.
When you can wait until this Monday, I’ll provide you with an example on how to achieve something like that by using proactive remediations.
Dear Peter, a pleasure to greet you, first of all I want to thank you for the excellent information you share with us.
In relation to the example that you would give on Monday for @Florian on a previous comment … I am also interested as I am implementing the same scenario. What do you recommend?
Thank you ,Pablo!
That solution is posted on my blog. Those are the posts about detecting and remediating local administrators by using proactive remediations.
Thank you Dear.
Thanks for creating this tutorial.
I’m having the issue where the group is not being pushed and the event viewer is showing that windows was not able to link between account names and security IDs
My experience is that for adding groups, using the SID is the best option.
I can see some people are using this OMA URI ./Device/Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership
But in your article, you are using the next one.
Is there any issue? or both are correct?
The result is the same. For a device-wide setting, the /Device portion may be omitted from the path (see also: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider)
I am getting this error on 7% of my machines: MDM PolicyManager: Merge of policy did not complete successfully, Policy: (ConfigureGroupMembership), Area: (RestrictedGroups), Result:(0x800705B9) Windows was unable to parse the requested XML data..
Is there something different on those machines? That exit code is to my knowledge often related to an invalid character..
Dear Peter, What if I have Windows devices in English and Spanish? My policy affects the administrators group and has the administrator user as a member, but it does not apply correctly to my devices in Spanish. Is there a way to do it so that it applies to both? I have used the SID and it works fine for the administrator group name but I still have the problem with the administrator member
You could also use the SID for the administrator group member.
This might be a dumb question. But does this apply if you want to add one user, say the user using the computer to the local admins group on just that machine ? My scenario is we have multiple offices about 140 computers. We need the users who are assigned to the machines to be added to the local group so they can install software. They don’t need full admin rights just enough to install programs. But we dont want these users added to groups on all devices just their specific devices. These are not on prem domain joined and are only azure ad joined.
In that case I would look at a different solution, like a script, to prevent you from having 140 different policies.
Used your guide and the policy has worked great. However we have a few devices that require their old local admin credentials and so I created a group for them. In the assignments I’ve selected “All Devices” but to exclude the group I mentioned earlier.
This worked well for a couple months but recently (2-3 months) the policy has started to apply to the excluded group. Would you have any idea why this is happening?
No that doesn’t sound familiar to me. Are you saying that the exclusion is not working? If so, I would suggest to contact Microsoft for support.
Essentially yes, the exclusion is no longer working. We’re going to try applying this https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-localusersandgroups instead and I’ll get in touch with Microsoft support.
That sounds like a plan. Keep in mind that the other method is only for Windows 10 20H2 and later (see also: https://www.petervanderwoude.nl/post/easier-managing-local-administrators-via-windows-10-mdm-on-windows-10-20h2-and-later/)
Seems like the policy has been tattooed on my computer since I’ve now disabled the policy and added local admin to my computer. Over the weekend it was removed again and I can still see the “RestrictedGroups” policy in domain info. Is there an easy way to remove this? Or is a rebuild required?
I haven’t used this policy for a while, but I do remember that it does refresh the adjusted users in the setting.
Hello – We have multiple Azure AD joined devices from AutoPilot deployment. We would like to add a non domain/Azure account into the local admin group (e.g.: localcomputer\account1 ). Is this possible? And if so, is it possible without the password for that account being visible in Azure (or other places if applicable)?
Do you actually want to create a new account, or just add an account to the local administrators?
We’d like to create a local account and place it in the local admin group on the PC.
There is a CSP for creating an account and adding it as a local administrator. However, that uses a plaintext password (for now). Your best option would be to script a solution for that.
(seems the post lost the xml, added spaces to try and keep it)
A little follow up, I’ve been hitting the brick wall on getting this to apply to my Dev/Test devices (20H2).
I had tried both ways (older and modern) OMA-URI with the relevant XML. Results were red errors in event log and nothing useful in the diag report.
What eventually worked for me was to drop the open and close tags that wrap around the <Accessgroup desc = " tags.
After that, the local admins was populated as expected and the diag report was correct.
Older (up to/inc 2004)
Thank you for that MarcP!