Add an Azure AD group to the local administrators group with Microsoft Intune

This is a follow-up post on the post about managing the local administrators group – Azure AD joined devices. In that post I already showed how the local administrators group on a Windows 10 machine can be managed with Microsoft Intune (Microsoft Endpoint Manager), but I only showed how to add Azure AD user accounts to the administrators group.

But as described on Microsoft docs, also Azure AD Groups are supported;

The member SID can be an user account or a group in AD, Azure AD, or on the local machine.

Even tough this Configuration Services Provider (CSP) policy is added in Windows 10 1809, I wasn`t able to get this to work with an AAD group during my previous tests (on Windows 10 1909). But as Microsoft is near the release of Windows 10 2004, I gave that OS version a try, and with succes!

I was able to add an Azure AD group to the local administrators group of an AAD joined device, using the SID.

This a welcome additional option on managing the local administrators group, as it simplifies managing members of the local administrators group.

In this post I show how to add an Azure Active Directory group to the local administrators group.

Some notes to take into account; this policy overwrites the default members of the Administrators group. By default the Global Administrator and Device Administrator (roles) are member of the local Administrators group. If you only want to add a group to the Administrators group and not want to remove the default groups, don`t forget to add the Global Administrator and Device Administrator to your policy. And add the local Administrator account to the policy, otherwise it fails.
As these roles are added to the local Administrator group by SID, take note of these before you overwrite these.

Get the SID of an Azure Active Directory group

The first thing we need to have is the SID of the Azure Active Directory group. This can be done via Graph API/ Explorer or by running a PowerShell command which I found on this site.

By using the Grap Explorer it`s very easy to find the Security identifier.
Query the group using the Object ID and it shows the SID.

An alternative which I actually used at first, when I wasn`t aware of the SID in Graph, was running below PowerShell command.
It converts the object ID (in the case of the AAD group) to a SID.
First connect to Azure AD using PowerShell:

After that run below command:

function Convert-ObjectIdToSid
    param([String] $ObjectId)

    $d=[UInt32[]]::new(4);[Buffer]::BlockCopy([Guid]::Parse($ObjectId).ToByteArray(),0,$d,0,16);"S-1-12-1-$d".Replace(' ','-')

Next run the conversion command. In this example I query all Azure AD groups from which the name starts with local.

Get-AzureADGroup -SearchString "Local" | ForEach { [pscustomobject] @{ Name= $_.DisplayName; Sid=Convert-ObjectIdToSid($_.ObjectId)}}

Note the SID of the group which you want to add to the local administrators group. In my case it`s the SID of the group Local_Admins_AAD.

Configure the Custom Configuration profile

  • Choose Windows 10 and later as Platform
  • Choose Custom as Profile type
  • Click Create
  • Give the configuration profile a Name
  • Enter a Description (optional)
  • Click the Settings tab
  • Click Add

In the value field we set which group membership we like to manage and define the group members.
<accessgroup desc> contains the local group SID or group name.
<member name> contains the group members to add to the local group.

In the example, I add the default members of the group to the policy; the local Administrator account, the Global Administrator and Device Administrator (with the SID). And I add the SID of my AAD group Local_Admins_AAD.

Enter below information to the Row;
Name: RestrictedGroups – ConfigureGroupMembership
OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership
Data Type: String

	<accessgroup desc = "Administrators">
		<member name = "Administrator" />
		<member name = "S-1-12-1-2934938113-1096209395-2588194479-178906382" />
		<member name = "S-1-12-1-766653809-1274192161-2093628596-1982031183" />
		<member name = "S-1-12-1-3293531080-1078674397-111521436-3834162110" />

Click OK (twice) and click Create.

Assign the profile to a security group and your ready for testing.

The end result

The end result is the default members are still member of the local Administrators group. Besides these accounts and SID, we now also see the extra SID of the Azure AD group. This provides the members of the AAD group local administrator rights.

That`s it for this blog post. Thank you for reading!

Starting with Windows 10 build 20H2 we also have a new setting LocalUsersAndGroups.


  1. Hi, thx for this post. You wrote this is only for 2004. But which build? I tested it on 19041.207 without luck. Should it work there?

      • strange, it isn’t working on my w10 machine with 10.0.19041.207. I have only applied the “Administrator” and the SID of my Local_Admin Group but not the Global Admin and Device Administrator but this should be no problem right?

        • Have not tested that setup yet. Will give it a try later, but assume that should also work.

          What I have seen is that sometimes if you sign in with an account which is member of the applied group for the first time, the administrator rights are not active. The second time you sign-in, it does work.

  2. Great post Peter.
    I tried this setting on a fresh 10.0.19041.207 build and the policy sort of works.
    The Administrator group will be modified as of my policy, where I, besides the extra group, added Administrator, the Device Administrator role’s SID and the Global Administrator Role’s SID.

    The thing is, after the policy is applied, none of the users are local admin anymore, not the device admins, not the global admins and also not the users in the extra group, so I’m really curious why this does work in your setup and not in mine.

    • I just tried this again, but instead of using the Groupname “Administrators”, I used group SID of the “Administrators” group, since that SID is always the same: S-1-5-32-544

      Now al the users of this group have local admin permissions. ?

    • I had several issues with this approach and prefer performing through script or proactive remediation tasks instead as have more control.

      $aadObjectID = “939e62da-dc86-4da7-af38-bc31feedc046” # AAD Group Object ID to assign

      function Convert-AzureADObjectIDToSID(){
      $bytes = [Guid]::Parse($objectid).ToByteArray()
      $array = New-Object ‘UInt32[]’ 4
      [Buffer]::BlockCopy($bytes, 0, $array,0,16)
      $sid = “S-1-12-1-$array”.replace(” “, “-“)
      return $sid

      $group = [ADSI]”WinNT://./Administrators,group”
      $SID = Convert-AzureADObjectIDToSID -objectid $aadObjectID
      $ismember = “False”
      @($group.Invoke(“Members”)) | ForEach-Object {
      If ($SID -match $_.GetType.Invoke().InvokeMember(“Name”, ‘GetProperty’, $null, $_, $null)) {
      $ismember = “True”
      If ($ismember -ne “True”) {
      $result = $group.Add(“AzureAD://$SID,group”)

  3. Thanks for creating such valuable post for In tune Admins, I tried this in our production, I created device configuration policies as stated in this post and pushed it to a device group contains only two devices, the policy got applied on one device and when i added a new user to the Ad Group that I added and tried to open cmd as admin unfortunately it failed saying requires elevation.

    • The policy is applied, you can see in the local group the correct SID is added as a member of the group? Restarted the device after adding the new group member?

  4. I actually assigned this policy for only for devices, one of the device received profile and i am able to see the groups in the local administrators group but when I try to do admin activity with one of the user who is a member of the Azure AD Group which got added in the policy.

    on another device, it doesn’t show up in the local administrators group itself.

    As suggested by you, i tried restarting the devices twice and even I did a manual sync both from the device and from the Intune portal but no luck.

    • And all these devices are running Windows 10 2004? Members of the AAD group are AAD accounts?
      If that`s the case, everything is in-place. I cannot think at something which causes this at the moment.

  5. Thanks for your reply!

    I think I have to update the Win Ver to 2004, the two devices are currently having 1909. I think the root cause of the issue would be the incorrect version. let me try to update both the devices to 2004 and then I will let you know.

  6. Hello Peter, thx for the great post. It was quite helpful. Just want to share that I used an alternative way to add the group to the local administrators. I run a simple powershell-script Add-LocalGroupMember -Group Administrators -Member S-.. For my situation this is beter because it preserves whatever already is in the administrator-group.

  7. Hi, thanks for your great work !

    Seems not working in 2004 build 19041.450. The SID group has been added to the local admin group by the policy but the user part of this AAD Group still doesn’t have admin rights after 3 reboots.

    • Hi Sanch,

      I did a quick test on a device with the exact same Windows build without any problems. Must say it is an existing device, where this was already tested before without any issues.

      • Hi Peter,

        Thanks for your reply. It’s working now ! I think the member of the AAD group wasn’t fully synced. Thanks again for this article!

          • Had the same issue, at first the local administrator group was showing the SID’s but it didn’t work, it takes a few hours to fully sync.

        • Hey Sanch. I’ve exactly the same issue. Azure AD Group is part of the local admin group but users don’t have admin rights. They are not elevated. Do you know what to sync exactly? I’ve created the policy today.

          • Hey Marc ! As Avista also said, as you have the Azure AD Group synced, I think you are on the right way and that it will work in a few hours. Very frustrating but we have to be patient with this kind of policies 🙂 Let us know

          • Hey Peter ! Thanks for the update I will test it between today and tomorrow for a new customer, I will let you know in the comment of the new article. GL HF to everyone !

  8. Hey Sanch. Thank you very much for your quick response! Now 3 hours later it works. I’m very happy with that new feature! Would be very interesting what exactly needs which sync. BR Marc

  9. The 3+ hour delay in the permissions being applied is due to the PRT needing to be refreshed to update your account entitlements. Once you’ve added the new group, you need to wait for your PRT to be refreshed (happens on sign-in after the token is >4 hours old) and then sign out and sign back in. This also applies to when you add and remove users from the group. So worst case scenario (from my testing) is that when you add someone to a new group they need to wait 4 hours until thier PRT can be refreshed and then sign out and sign in twice. Not great for more complex use cases.

  10. Does this overwrite if there is other users part of the local administrator already? how can I append without change what’s in the group already. and if I wanted to remove just one of the users in the group is that possible?

  11. Hello, I have 2004 and 1909 devices. After applying the policy, AzureAD group SID gets added to ‘Remote Desktop Users’ group in both version devices.
    However, the member of AzureAD group is able to access RDP for only 2004 version, it does not work for 1909 version.

    When I use same policy to add AzureAD users to ‘Remote Desktop users’ group in 1909, it works correctly.
    Policy does work in 1909, but only for AzureAD users and not for AzureAD group.

    Is there a way to get policy worked for AzureAD group in 1909 version? Our environment has dependency for 1909 that prevent us upgrading to 2004 version.

  12. Never ever managed to get this working. Policy created/assigned/synced, shows Succeeded in Device config, but no members are added to the group (Administrators)
    That is just for users, NOT groups

  13. I have added a group to Remote Desktop Users through this process and I can see the SID being added to the local Remote Desktop Users, but the RDP connection returns an error: The connection was denied because the user account is not authorized for remote login.

    If I add my user account to the Remote Desktop Users group then I can use RDP.

Leave a Reply

Your email address will not be published.