Unable to add Entra Groups to 'Administrators' group via LocalUsersAndGroups Intune Policy

Question

I'm trying to add an Entra group (containing a few users) to the local Administrators group on my Intune managed device via the LocalUsersAndGroups policy (Endpoint Security > Account Protection > Local User Group Membership).

I'm able to add individual users to the Administrators group with this policy using the format AzureAD<email address>

This article mentions that Entra groups can only be added with their SID. I've been able to retrieve the SID for the group I wish to add using the Graph Explorer, but when I add that SID to the policy and deploy it to my device, local Administrator privileges are not granted for members of the Entra group even though I can see the SID listed in the Administrators group in Computer Management. The policy in Intune shows no errors either.

I'm not sure why the permissions aren't being applied. I have a few ideas, but I need some clarification:

1. My first thought was that I was using the wrong type of group in Entra, but I've had no luck with either Security groups or Mail-Enabled Security groups. Do I need to use a specific type of group for the policy to work? (i.e, will the policy only work with, for example, a Dynamic Security group?)
2. Do I need to add anything extra to the SID when I add it to the users list in the LocalUsersAndGroups policy? Should I specify the domain first, as I've done with specific users?

Thanks,

Matt

Answer 1

@Matt, Thanks for posting in Q&A. For your questions, here are my answers:

Q1: My first thought was that I was using the wrong type of group in Entra, but I've had no luck with either Security groups or Mail-Enabled Security groups. Do I need to use a specific type of group for the policy to work? (i.e, will the policy only work with, for example, a Dynamic Security group?)

A1: The policy should work with any type of Entra group, including Security groups or Mail-Enabled Security groups. The policy does not require a specific type of group to work.

Q2: Do I need to add anything extra to the SID when I add it to the users list in the LocalUsersAndGroups policy? Should I specify the domain first, as I've done with specific users?

A2: You do not need to add anything extra to the SID when adding it to the users list in the LocalUsersAndGroups policy. You should not specify the domain first when adding the SID. However, the supported formats of identifying the user selection in order of most to least preferred is through the SID, domain\username, or member’s username. Values from Active Directory must be used for hybrid joined devices, while values from Microsoft Entra must be used for Microsoft Entra join. Please ensure the device join type is correct to added the members.

If the device join type is correct, and I notice the SID is added into the local administrators group. That means the Intune policy is already applied. It can be that the device itself can't recognize the SID. You can open case with Windows support and Microsoft Entra support to look into the issue:

https://learn.microsoft.com/en-us/entra/fundamentals/how-to-get-support#open-a-support-request

Hope the above information can help.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Thanks for the clarification, Crystal-MSFT.

Just thought I'd follow up on this in case anyone else comes across a similar issue.

I should mention that my method for testing whether or not administrator privileges had been applied was to run the Command Prompt as Administrator and attempt to authenticate in the UAC window that appears.

It turns out that the permissions are applying (the device is recognising the group SID) - but the UAC prompt which grants elevated access does not seem to accept any members' Entra credentials (UPN + password).

Instead, the group member can only authenticate with the device PIN they setup in Windows Hello.

I'm not sure why this is, but I have a few guesses:

• Windows Hello authentication disables authentication with UPN+Password, for some reason.
• Incorrect UPN formatting - I've only been using the email address in the UAC, no 'AzureAD' prefix. Maybe this is required.
• 2FA is enforced on our user accounts (as is Windows Hello) - perhaps the UAC is unable to authenticate with just a password, but it lacks the mechanism to prompt for additional authentication. This would explain why the device PIN works - as it's technically two-factor authentication (?).

I don't have time to test these now, but they might be worth looking into. The last two points don't apply for users who were added to the local Administrator group individually (i.e., not as a member of an Entra group), so perhaps the SID or group inheritance is breaking something?

Hopefully somebody with more time/understanding can figure out exactly what's happening here. For now, I'm happy for group members to authenticate with their device PIN when they need elevated access. Although I'm not sure if this would work well in scenarios where users share devices.

I've also tested and made sure that users who are not members of the Administrator group cannot elevate their privileges using their PIN - this possibility did cross my mind when I discovered that the PIN worked but thankfully that is not the case.