I don’t think anyone would take exception to me saying that it’s important to manage who is in the local Administrators group on Windows 10 devices, but what does that mean? According to the principle of least-privilege, it means that you should ensure users are logging on with a user account that has the absolute minimum permissions necessary to complete the current task and nothing more.
OK, that’s fine for end users, but what if you need elevated permissions to do your job? For example, help desk administrators will generally need admin rights on managed Windows 10 devices to do what needs to be done when responding to requests for assistance from our non-admin end users. With that scenario in mind, let’s see how we can manage the local Administrator group membership for Azure AD joined Windows 10 devices.
Who’s an admin by default?
Before we start updating local administrator accounts on managed devices, it might help to understand who is supposed to be there in the first place. By default, these accounts will be present in the local Administrators group for Azure AD joined devices:
- Azure AD Global Administrators
- Azure AD device administrators
- The account that joins the device to Azure AD
The initial user of the device before it is joined to Azure AD will be present as well if you didn’t join Azure AD as part of the OOBE experience.
Those are all fairly self-explanatory, but what’s this Azure AD device administrator? This role is available for assignment only as an additional local administrator in the Azure AD Device settings. Users with this role become local machine administrators on all Windows 10 devices that are joined to Azure Active Directory. They do not have the ability to manage devices objects in Azure Active Directory.
Do not confuse Azure AD device administrators with the Cloud Device Administrator RBAC role. That’s a completely different role used for completely different purposes.
You can find the users who have been assigned device administrator permissions (not RBAC role) in the Azure AD portal. Just go to Azure AD Portal -> Devices -> Device settings and then click the Manage Additional local administrators on all Azure AD joined devices link.
Add users to the device administrators in Azure AD and they’ll be added to your devices’ local Administrators group automatically. Device administrators are assigned to all Azure AD joined devices. You cannot scope Azure AD device administrator permissions to a specific set of devices.
Add local administrators when joining Azure AD
Let’s join a Windows 10 device to Azure AD and watch what happens. Notice first that the user adding the device becomes an administrator on the machine:
Yes, I could have just joined this device to Azure AD from OOBE, but I want you to see what happens to local admin accounts later.
As soon as you’ve joined Azure AD, the other two sets of administrators (Azure AD Global Administrators and Azure AD device administrators) are also added in addition to any previously listed local administrators. In the following screen shot, you can see:
- The default (disabled) Administrator account
- The account I used to join Azure AD (which resolves to CORP\jeff instead of AzureAD\[email protected] because that’s a synchronized account from on-premises AD)
- The original user account called EndUser-2004 that used to set up the device (without joining Azure AD at OOBE)
- And two apparently unresolved SIDs
Do you see the Global Administrators or the account that was added as an Azure AD device administrator (HelpDesk-0) listed? Me neither, but I’ll bet you the account is an admin on the machine. Don’t believe me? Watch, I’ll log in as HelpDesk-0 to see what happens.
HelpDesk-0 is an administrator on the device, but not listed by name in the local Administrators group.
Let’s circle back to those two unresolved SIDs. Those represent Azure AD groups. Really any SID you see in the local Administrators group starting with S-1-12-1 is an Azure AD group. One of those SIDs is the Azure AD Global Administrators group and the other is the Azure AD device administrators that we added HelpDesk-0 to.
Let’s assign another user (HelpDesk-1) device administrator permissions and see what happens.
If you immediately go log into an Azure AD joined Windows 10 device with the new account Voila! the recently added new device administrator account is an admin.
Remove the Azure AD device administrator assignment from a user and*poof* their admin rights are gone as soon as they log off. No admin rights for you. And, because their account name was never shown in the local Administrators group on the device, only you are the wiser.
If the account had previously logged into the device when you assign device administrator permissions, the account won’t be an admin until a new Azure AD primary refresh token is issued—AND when the user logs off and back on to get the new token. This could take up to four hours, but in my testing it never took that long.
The Azure AD global admins and device administrator accounts are added when the device joins Azure AD. They’re added once. Just one time. There’s no built-in remediation to add those SIDs back if someone with administrative privileges on the device deletes them.
Everything works smoothly to manage local administrators using Azure AD settings, but remember that these settings will be applied to every Windows 10 device that is joined to Azure AD. Every device, tenant-wide. What if you want to have different local administrators for different groups of devices? Time to head over to the MEM admin center.
Manage local administrators using Intune
To manage local administrator group memberships for on-premises Active Directories, we use the restricted groups Group Policy Object (GPO) settings. To do the same thing for Azure AD joined devices, Intune can be used to push a restricted groups configuration profile to managed Windows 10 devices leveraging the Restricted Groups Configuration Service Provider (CSP) instead.
The process described in this blog post does not apply to on-premises AD or hybrid-Azure AD joined devices.
Because I’ve got Auto-MDM enrollment configured, any Windows 10 device joined to Azure AD will automatically become enrolled into Intune management. All I have to do now is go create a custom Windows 10 device configuration profile to get the local administrator management party started.
Pretty standard stuff, just go to where you usually go in the MEM admin center portal to create a new device configuration profile and click + Create profile. Give the new Windows 10 and later device configuration profile a nice name and description and click Next.
On the Configuration settings tab, click Add to add a new row and enter the required information:
- Name: Whatever you want.
- Description: Whatever you want.
- OMA-URI: This EXACTLY: ./Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership
- Data type: You can use string if you want to copy and paste right into the policy, but I always import an XML. To do that, choose String (XML file) instead of String for the data type. It’s formatted better when you do that and it also gives you a paper trail of what policy settings you’re using without having to go edit the policy later. Just use Notepad.exe to create the file and save it with an .xml file extension.
What goes in the XML?
The XML needs to be formatted according to a pretty basic set of rules. In its simplest form, your code must have two sections within the <groupmembership></groupmembership> tags. An access group description and at least one member name line containing the built-in Administrator account. Basically, all we’re really doing here is saying who (what member names) should be in the well-known local group we’re targeting (access group):
Do you have to include the built-in Administrator in your policy? Yes. If you try to remove that account, the policy will error on the device with the following error:
MDM PolicyManager: Merge of policy did not complete successfully, Policy: (RestrictedGroups), Area: (ConfigureGroupMembership), Result:(0x8007055B) Cannot perform this operation on built-in accounts.
Interestingly enough, the device configuration profile device status will show as succeeded in the MEM admin center when this happens, but the local device Administrators group will not be updated. You’ve been warned!
Technically, you don’t need them, but you’re probably also going to want to include the Azure AD group SIDs for the Global Administrators and Azure AD device administrators. The SIDs are different for every Azure AD instance so don’t use mine, but below is what they should closely resemble:
At a minimum, that’s the basic information you should start any custom OMA-URI policy with to manage local Administrator group memberships.
Add a user by name
Now that we have the basic requirements listed in the XML, we can start adding users. HelpDesk-0 and HelpDesk-1 are already administrators on the box by virtue of the Azure AD Device Administrator permissions. Let’s add the HelpDesk-2 account by name. Just add a new “member name” row to your XML file and import it into the policy.
Have your test device pull a policy and review the event logs to see the device configuration profile magic in action.
The full path to the event log you seek is: Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider/Admin.
Hopefully you’ll see event 814 that tells you the local Administrators group has been successfully updated per your XML’s direction:
If you take a look at the local Administrators group properties, you should also see those changes reflected.
Take a close look at that screen snip. I feel like there’s something missing there. What happened to EndUser-2004 and the CORP\jeff account that I used to join the device to Azure AD? They’re gone. They weren’t explicitly listed as needing to be there so the RestrictedGroups CSP wiped them out of the local Administrators group.
This is an easy way to ensure only the people you want to have admin rights will have them, but be careful with this and make sure you understand the expected behavior before you go deleting accounts! If you’re not on the list, you don’t get in the club no matter who you know.
Add a user by SID
You can add an administrative user by name, like we just did, or by using the account’s SID. What’s a SID? A Security ID (SID) is used to manage access to various parts and pieces of Windows. It’s how permissions are applied via access tokens.
If a user has already logged into the device, you can easily see the SID from their account properties (see all that S-1-12-1-598… business in the screen shot above after AzureAD\HelpDesk-2? That’s the account’s SID. Kind of hard to copy and paste that into a policy XML though. Here’s how you can grab that SID via the Windows registry after you’ve logged in with the account:
This is an Azure AD account so you won’t see it if you run PowerShell’s Get-LocalUser cmdlet. Try it yourself and see: Get-LocalUser | Select-Object Name,SID.
Updating the XML to use the SID instead of the username for HelpDesk-2 gives us:
When the policy is applied, you’ll see event 814 again, but this time, you’ll see the user’s SID instead of account name:
And the local Administrators group updates accordingly:
![clip_image021[1]](https://secureservercdn.net/166.62.110.90/vvs.492.myftpupload.com/wp-content/uploads/2020/09/clip_image0211.png?time=1599602087 "clip_image021[1]")
Yeah…nothing really changed. That’s because the SID gets translated so you’ll still see the account’s name and SID when adding users by SID.
Add an Azure AD group
Adding a user to the local Administrators group works fine, but what if there’s a group of users that need to be added to the local Administrators group instead? You can’t do that using the Azure AD Device Administrator settings, but you can using the Restricted Groups CSP—and that means you can assign different local administrators to different groups of devices using Intune device configuration profiles. Time to do that.
All the help desk accounts that we’ve been adding reside in an Azure AD security group conveniently named HelpDesk. Let’s go add that to the policy instead of individual usernames or SIDs. Here’s the group information from its Azure AD properties:
According to the RestrictedGroups CSP documentation, you can use either a group name or SID for Windows 10 2004 or later devices:
The behavior of this policy setting differs in different Windows 10 versions. For Windows 10, version 1809 through version 1909, you can use name in <accessgroup dec> and SID in <member name>. For Windows 10, version 2004, you can use name or SID for both the elements.
I’ve got a mix of devices in my lab so I’m going to use the group’s SID instead of name. Also, when I tried using a group name with my Windows 10 2004 test devices, the policy always failed with the error, “No mapping between account names and security IDs was done.”:
Maybe I’m doing something wrong, but I’m going to stick with using group SIDs in any case. Your mileage may vary.
Onwards and upwards. Let’s go get the SID for the HelpDesk group and see if that’ll work. You won’t see the SID for your group in its Azure AD properties, but you will see its ObjectID. In my example, the HelpDesk group’s ObjectID is ffafc5b9-5d03-4b41-9617-bbf7ca3bf07e (as you can see from the screen snip above).
If you don’t feel like logging into the Azure portal to check for the group’s ObjectID, you can use PowerShell to get the ObjectID after you’ve connected to Azure AD. Just run these commands:
Connect-AzureAD <and then log in>
Get-AzureADGroup -SearchString <name of your group>
Now that we have the ObjectID, we can use Microsoft Graph to get the group’s SID. Just head on over to the Graph Explorer site at https://developer.microsoft.com/en-us/graph/graph-explorer and enter the following query (substituting your group’s ObjectID): https://graph.microsoft.com/v1.0/groups/<your group’s ObjectID>.
You should see something similar to the below returned. Scroll down in the results until you see the securityIdentifier line. That’s the group’s SID that needs to be added to your policy XML.
Now we know the SID for the HelpDesk Azure AD group is “S-1-12-1-4289709497-1262574851-4156233622-2129673162”. I’ll also put a member of the HelpDesk group back in the XML by name to see what happens when the user is part of a group we’re adding to the policy. Let’s go update the XML and see what happens.
Aaand it failed. The event log is once again throwing that pesky Result:(0x80070534) No mapping between account names and security IDs was done..
See what I did there that broke it? I put a 0 in front of the 2 in the account name for HelpDesk-2. The Azure AD user couldn’t be found so I got the (0x80070534) No mapping between account names and security IDs was done. error.
Hopefully everyone currently Googling that error code has found this post and benefitted from my Doh! moment.
Fix the name in the policy settings and once your devices re-sync, all will should go as planned.
Notice that the Azure AD group SID doesn’t translate to the display name like it did for the Azure AD user accounts. The user account is also listed by name even though it’s a member of one of the Azure AD groups assigned by SID.
Of course, we don’t need to add the user by name if we’re also adding the user group so I’d take that account name out of the policy. Using group SIDs is useful for ease of management and also because it makes it a little more difficult for people to figure out whose an admin on these boxes. Just keep track of the SIDs you use!
Just keep track of the group SIDs you use. That sounds like a pain, why not just put comments in the XML file instead? Let’s try that. Maybe you need to add several groups and comments would certainly help to clarify who’s who.
Remember that the RestrictedGroups CSP documentation says you can use a name here, but I couldn’t get it to work. Besides, that would only work on Windows 10 2004 and later anyway.
Looks nice and clean and easily identifies the groups being added, but sadly, XML comments cause the policy evaluator to puketh and the policy never gets applied. Adding to the confusion, your devices will again report back that they’ve successfully applied the policy via their device status in the device configuration profile, but nothing happens to the local Administrators group membership. Bottom line: don’t use comments in your XML.
At least that’s how it went in my testing. Let me know if you see different results because I’d really like to use comments there.
There’s one last thing you should know about assigning these policies. If someone is logged on to the machine after the policy applies and they’ve been given administrator permissions, they can remove users or groups from the local Administrators group, or add new users to it, and Intune will not reset the permissions the next time the device pulls a policy. You’ll have to make a change to the policy in order for the permissions to be re-applied.
CHANGE ISN’T ALWAYS A GOOD THING
Now that you’ve got your local administrators situation all figured out, how do you keep things the way you want them?
The RestrictedGroups policy is part of the Policy CSP which Intune leverages for a lot of policy settings. Luckily, starting with Windows 10 1903, settings configured via the Policy CSP (like the RestrictedGroups settings) will re-apply the next time a device does a scheduled check-in with the Intune service. That means if some troublesome local admin decides to add one of his buddies or remove one of those mysterious SIDs, they’ll be right back in about eight hours. It’s a really cool behavior, but remember at least for now, it’s only for Policy CSP settings. Peter van der Woude did a great job explaining all of this in a blog so I won’t duplicate it here. If you’re still curious, go check out Windows 10 MDM policy refresh from @pvanderwoude.
Just a heads’ up here. In my testing the local Administrators group settings weren’t reapplied when I did a manual sync, but they were when the regularly scheduled check-in ran. This might have just been something I was doing to confuse things in my lab, but I figured I’d let you know in case you don’t see settings revert to policy-based values immediately after an on-demand check-in.
UNDOING WHAT WE’VE DONE
So, now we know admin users can’t modify our local administrator group settings, and we can modify the policy to make changes if we want, but what if we, the admins, want to completely remove our fingerprints from the local Administrators group? No can do.
When a profile is removed or no longer assigned to a device, different things can happen, depending on the settings in the profile. The settings are based on CSPs, and each CSP can handle the profile removal differently.
You might have heard that when you unassign a policy based on the Policy CSP that the settings revert back to what they were before the policy was applied and you’ll get an event log message telling you the setting was deleted. That doesn’t always happen though so make sure you test these types of things.
Your best bet is to configure policy settings as not configured for a bit before unassigning a policy just to be safe. In the case of the RestrictedGroups settings, unfortunately there’s no rolling back. These settings are tattooed on the system until they’re changed by and admin. You can see the issue in the event logs:
You’ve seen my blog; want to follow me on Twitter too? @JeffGilb
