Intune Log on Rights

I locked myself out of a test machine last week.

Not in a fun way. Not in a "forgot my password" way. In a "the sign-in method you're trying to use isn't allowed" way, where no account on the device could log in at all. Not the admin. Not the test user. Nobody.

Ok. Probably just something to do with Windows Hello. No worries. Lemme just login with the password.

😒

Thanks for giving me the benefit of the doubt but I DID not mean to do this on purpose. I've deployed this exact policy before in production environments. I know how it works. And I still managed to brick the logon on my test device.

I had to wipe the machine. Completely.

What happened? I forgot the #!&%?! USERS group.

The trap with AADJ devices

On AADJ-only devices, local group memberships are still evaluated for user rights assignments. Your Entra ID groups don't just float freely. They need to be nested inside one of the local BUILTIN groups on the machine:

  • Administrators
  • Users
  • Guests
  • Power Users
  • Remote Desktop Users
  • Remote Management Users

If you're restricting who can log on locally and you don't include the Users group, congratulations. You've locked out every standard user on the device. Including yourself, if you're not a local admin.

NAMELY USERS.

I knew this. I've done this before. I still forgot it.

Why this policy is dangerous

The Allow Local Log On user rights policy (the old CSP path was ./Device/Vendor/MSFT/Policy/Config/UserRights/AllowLocalLogOn) is probably the single most dangerous policy for end-user productivity you can push through Intune.

You can't just remove it. That's the part that gets people. Deleting the policy from Intune doesn't undo what it did. The user rights assignment sticks on the device. You have to deploy a corrected policy that overwrites the values. If you've already locked everyone out, you can't even log in to verify the fix applied. You're wiping.

And Intune won't warn you. It just applies the policy. If you scoped it to "All Devices" instead of a test group... I hope you like reimaging at scale.

How I set it up (the right way, this time)

Settings Catalog in Intune is how you do this now. One sentence on what it is: it's the replacement for custom OMA-URI profiles, and it's way less error-prone because you pick settings from a list instead of typing CSP paths from memory.

Create a profile: Intune > Devices > Configuration profiles > + Create profile > Windows 10 and later > Settings catalog.

Search for "User Rights" in the settings picker, select Allow Local Log On.

Quick note: the search in Intune is still terrible. No fuzzy matching, no suggestions. You need to know the exact category name or get lucky.

This is where the Settings Catalog is actually nice. Adding multiple SIDs is simple. I added the BUILTIN\Administrators group (always keep this), plus the SIDs for my Azure Administrators group and a marketing department user group to restrict logon.

And this time, I made damn sure the Users group was in there too.

Or as it looks on the client (logged in as AlexW. Of course).

If you're still using custom OMA-URI profiles for this (the old way), same logic applies. The Settings Catalog just makes it harder to fat-finger the syntax.

The checklist (because I clearly needed one)

Before you deploy an AllowLocalLogOn policy to anything that isn't a test device you can afford to wipe:

  • Include the BUILTIN\Administrators group. Always.
  • Include the BUILTIN\Users group. Always. This is the one I forgot and it bricked the device.
  • Add your Entra ID groups by SID, and make sure they're nested into the right local groups on the device
  • Scope the policy to a test group first. Not "All Devices." Not even "All Windows Devices."
  • Test with a non-admin account. If you only test with your admin account, you won't catch the exact mistake I made.
  • Remember: deleting the policy doesn't undo it. You have to overwrite with a corrected policy. Plan for that before you need it.

I broke this so you don't have to. Don't forget the Users group.