Comments on: Assign Deny Local Log On user right to an (Azure) AD group by using Microsoft Intune

By: Chris Johnson

Chris Johnson — Tue, 24 Jun 2025 12:05:17 +0000

This works with windows 11 24H2 June 2025 but be aware there is a delay when adding users to the groups of a few hours.

By: Joshua Bines

Joshua Bines — Tue, 28 Nov 2023 17:36:42 +0000

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

By: majerly

majerly — Sun, 16 Apr 2023 19:51:33 +0000

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

By: Marcel Moerings

Marcel Moerings — Mon, 30 Jan 2023 20:31:36 +0000

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.

By: chris moore

chris moore — Sat, 04 Jun 2022 10:56:44 +0000

In reply to Manuuu.

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.

By: Manuuu

Manuuu — Fri, 03 Jun 2022 13:16:16 +0000

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?