Azure AD groups in Windows local groups not working properly

Question

Hi, we are trying to move our computer management from Windows 10 / on-premise AD / Group Policy to the brave new world of Windows 11 / Azure AD / Intune. Our sticking point right now is that Azure AD groups added to local Windows groups does not work properly or consistently. The only thing that seems to work correctly is directly adding Azure AD users to local groups rather than AAD groups to local groups but that solution does not scale.

In our current solution we very granularly control who is an admin and who is allowed to log on to each computer. We have two AD groups for every client computer, based on their computer name. Say the computer is named "BLAH123" then we have a group named "BLAH123-Admins" and one named "BLAH123-groups".

Using a startup script we modify the local groups as such

• Local Administrators
  • BLAH123-Admins
• Local Users
  • BLAH123-Admins
  • BLAH123-Users

(If you don't add both Admins and Users to local users then when you log in you get a User Profile Service fail or explorer.exe never loads, you just get a black screen. It's weird but to log on as an admin you also need to be a user).

INTERACTIVE, AUTHENTICATED USERS, and everything else is removed from the local users group. This means if you are not in the BLAH123-Admins or BLAH123-Users groups then you can not log in to the computer.

This solution works well for us and has for Windows 7 and 10. I am now trying to replicate this on an Azure AD joined Win 11 22H2 system. It is not hybrid AD joined.

It works in some situations but not others. I can add the AAD groups to the local admin and users groups by grabbing the object ID, converting to SID, and adding the SID via

Add-LocalGroupMember -Group administrators -Member S-1-12-1-1514245322-etc

Problem 1, Azure AD group doesn't grant "user" rights

If I replicate the above config using AAD and attempt to log in as someone either in BLAH123-Admins or BLAH123-Users I get the "user profile cannot be loaded" error. This happens if someone has the ability to log on but is not a user.
If I then add INTERACTIVE to local users then I can log on with that same user just fine. Here's where it gets weird. If I remove INTERACTIVE then I can still log on. Everything is fine.
If I reboot everything is still fine.
But some hours later we are back to the same problem, user profile cannot be loaded.

The AAD group is not consistently granting user rights.

Problem 2, Azure AD group doesn't grant logon rights

I thought perhaps there was something peculiar going on with the built-in groups so I created a new local group called "LogonUsers" then I changed the local Group Policy "Allow log on locally" by removing "Users" and adding "LogonUsers". Then I left INTERACTIVE in local Users and added my AAD groups to local "LogonUsers" instead.

This worked the first few times I logged in but after a few reboots it did not. A user in an AAD group in LogonUsers would get the "sign in method you are trying to use isn't allowed" error.

Adding the AAD user to "LogonUsers" allowed me to login even though that AAD user was in an AAD group that's in "LogonUsers". Removing that AAD user broke logon again.
The AAD group is not consistently granting logon rights.

Problem 3, Azure AD group doesn't grant admin rights

I went back to the default for the "Allow log on locally" policy and allowed Users again. I left INTERACTIVE in local users.

Then I logged in as a non-admin AAD user. That worked.

Then I added that AAD user to the AAD group that is a member of local admins. I was trying to essentially promote that account from user to admin on that computer.

I logged in fine but I was not an admin. Reboots didn't help. Waited an hour, didn't help.

If I directly added the AAD user to the local admins group that worked. If I deleted the user profile from the local computer and logged in that would work. But I couldn't just add someone to the "BLAH123-Admins" group who had previously logged on to that system and make them an admin.

How is this supposed to work?

In all of the above scenarios if I directly add in the AAD user, rather than an AAD group containing that user to the local group in question then everything works fine. Is this expected behavior?
How do people limit who can log on to devices?
I haven't tried setting these groups via an Intune Configuration Profile yet but that's not very granular. We can't have a config profile manually configured for every client device.

Answer 1

Hi Steven Gilman

for your 3 errors, you can try:

Verify Group Membership: Ensure that the users you expect to have the "user, admin, or login" rights are indeed members of the Azure AD group. Check the group membership to confirm that the appropriate users are added.

Check Group Membership Type: Azure AD groups can have two types of memberships: assigned and dynamic. Assigned groups have manually added members, while dynamic groups use rules to automatically add and remove members based on defined criteria. Verify that the group in question is of the correct type and that the membership is correctly configured.

Confirm Group Scope: Check the group scope to ensure it aligns with your requirements. Azure AD groups can be assigned as a member of other groups or given direct assignments to resources. Verify that the group has the necessary scope to grant "user, admin, or login" rights to the desired resources.

Review Resource Permissions: Check the permissions and access control settings for the specific resource where you expect the "user, admin, or login" rights to be granted. Ensure that the Azure AD group is properly assigned with the appropriate permissions or roles at the resource level.

Check Role Assignments: Azure resources often use role-based access control (RBAC) to manage permissions. Confirm that the Azure AD group is assigned the correct roles or permissions within the resource's RBAC settings. Make sure the roles assigned to the group grant the desired "user, admin, or login" rights.

Evaluate Conditional Access Policies: Conditional Access policies in Azure AD can restrict or grant access based on specific conditions. Review any conditional access policies that may apply to the users or groups in question. Ensure that the policies are properly configured and not blocking the "user, admin, or login" rights.

Verify Azure AD Connect Sync: If you are using Azure AD Connect to synchronize on-premises AD groups to Azure AD, ensure that the synchronization is running properly and the group memberships are being synchronized correctly. Check the synchronization logs and confirm that the relevant group memberships are up to date.

1. Monitor Azure AD Activity Logs: Check the Azure AD activity logs for any relevant audit or authentication logs related to the Azure AD group and the attempted access. The logs may provide insights into any errors, failures, or other issues that are preventing the "user, admin, or login" rights from being granted.

---

• The group might not have the correct permissions. To check this, go to the Azure portal and select "Groups". Then, select the group that you want to check and click on the "Permissions" tab. Make sure that the group has the appropriate permissions for the resources that you want it to access.
• The group might not be assigned to the correct role. To check this, go to the Azure portal and select "Roles". Then, select the role that you want to assign the group to and click on the "Members" tab. Make sure that the group is listed in the member's section.
• The group might not be enabled. To check this, go to the Azure portal and select "Groups". Then, select the group that you want to check and click on the "Overview" tab. Make sure that the "Enabled" checkbox is checked.

If you've checked all of these things and the group is still not granting user, admin, or login rights, you can contact Microsoft support for help.

Here are some additional troubleshooting tips:

• Make sure that the group is a security group and not a distribution group.
• Make sure that the group is in the same Azure AD tenant as the resources that you want it to access.
• Try adding the group to a different role.
• Try enabling the group.