We have the need to assign the Deny Local Log On user rights to certain user accounts. On our traditional managed Windows devices we configured this by assigning this user right to an AD group by using a group policy.
On our modern managed devices (only cloud-managed), we have no group policies available and make use of Microsoft Intune. In the past, I have also been configuring the Allow Local Log On user right with Microsoft Intune, but I had no success in assigning the user right to an AD or Azure AD group. But I got in contact with an escalation engineer of Microsoft who provided me a workaround to get the job done (thanks for that!), which I’d like to share with you.
The solution in short
By default, the local group Guests is already assigned the Deny Local Log On user right. If we are able to add our Azure AD or (synced) AD group to this local group with Intune, we might have a workaround to block a certain group of users to sign in to the Windows devices.
I’ve done some testing on Azure AD joined devices, with AD and Azure AD groups and indeed, this does the job.
Assign Deny Local Log On user rights
By default, the local group Guests is already assigned the Deny Local Log On user rights, but I want to be sure the rights are in place for the accounts and groups I configure. Therefore I deploy a Settings Catalog profile to the devices which configures this.
- Sign in to the Microsoft Endpoint Manager admin center
- Browse to Devices, Windows, Configuration profiles
- Click +Create profile
- Select Windows 10 and later as Platform
- Select Settings Catalog as Profile Type
- Click Create
- Enter a Name and click Next
- Select Deny Local Log On, which is found under the User Rights section
- Add *S-1-5-32-546 in the text box (which is the well known SID of Guests)
- Click Next and finish the configuration profile
Don’t forget to assign the profile to a device group.
Add an (Azure) AD group to the Guests group
We can add an AD or Azure AD group to the local Guests group by adding the group using the security identifier (SID) or by name (Contoso\GroupName). Or with the new Local User group membership configuration, we can search Azure AD for the group (that’s of course not possible when we use a custom configuration profile).
The SID can be found by using Graph Explorer, which you can open via https://aka.ms/ge
We need to run a GET query which is:
https://graph.microsoft.com/v1.0/groups/ObjectID
Replace the ObjectID with the Object ID of the group, which holds your users you want to deny local log on. This will provide you with the SID in the response.
Switch back to the Microsoft Intune portal.
- Browse to Endpoint Security, Account protection
- Click +Create Policy
- Select Windows 10 and later as Platform
- Select Local user group membership as Profile
- Click Create
- Enter a Name for the profile
- Enter a Description (Optional)
- Click Next
- Under Local groups select Guests
- Make your choice for Group and user action (I use Replace so existing members are removed)
- Select Manual (if you also want to add the local guest account, as that needs to be added manually)
- Click Add user(s)
If you choose Add (Update), members which are already member of Guests are untouched. That way you can choose to search Azure AD for the groups. But you are not sure Guest is still a member of the local Guests group in case somebody removes it.
Enter Guest (if you also like to have the Deny local Log On right applied to that account) or better it as SID S-1-5-32-546, which I didn’t in this test, so it works on any OS language.
And add the group name or SID of the group for which you want to block sign-in to the Windows devices.
Click Select and deploy the new profile to your devices.
The end result
The end result is that group members are not able to start a process by using run as different user.
And logon to the device is blocked.
This workaround by first adding an (Azure) AD group to the local Guests group does the job.
Thanks for reading.
5 Comments
The language problem still seems to exist, any news aboit this? I have tried onpres sid, azure sid, azuread\sid, accounts , etc, etc still no success.
Error 65000
Anyone has else has this same issue?
Yeah we saw this on our international devices. “Guests” is localized according to OS lang. We had luck using the “LocalUsersandGroups CSP” – https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-localusersandgroups – and writing the XML ourselves, specifying the local group’s well-known SID in the “accessgroup desc” instead of the localized name.
It all seems a bit tricky. I think the Allow Local Logon Right trumps the Deny local login right. What we are trying to accomplish is the ability for some admins to use their admin account for elevated rights, but not allow them to login wth their admin account on the system (which would give them admin access all the time).
To achieve this we add an Azure AD group to the local Administrators group. This makes sure they can elevate themselves with their admin account. We also followed your guide to add their admin accounts to another Azure AD group which we added to the Guests group. Guests are then denied the local logon right.
However… when testing this with a account that was also a member of the local administrators group, they could still logon. If the account was not a member of the local administrators group, but was a member of the guests group, the logon was denied.
I’m wondering what would be a suitable solution for this issue. If they need elevation, they need to be part of the local Administrators group.
Hi Peter,
I have tried in my laboratory the configuration that you indicate and it has worked for me and including the guest SID ok.
If the login is done with a password, the message is the one you indicate in your article and it is more or less understandable for a user.
If you do it by PIN, here it can confuse more, it says incorrect username or pin.
Hopefully they will soon release another method where you can capture it at the Azuread level, or a process that is not so cumbersome, since you have to do it that way because if you add the SID in the user right, it is not able to read the membership of that group, in It is type of configurations and I understand that this affects more similar configurations.
It is only capable of reading builtin groups or so I thought I understood,
Thanks for the article
I like this solution but… likely this does meet dymanic group licensing requirements 🙁
“This feature requires a Microsoft Entra ID P1 license or Intune for Education for *each* unique user that is a member of one or more dynamic groups.”
https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-membership