Assigning Local Log on User Rights via Intune Settings Catalog

on

As helpful as wizards like Intune Security Baselines are useful for greenfields and inexperienced admins, those needing a little umph in their setups (especially those admins used to on-premise GroupPolicy Administrative Templates) found Intune’s offerings lacking – forced to use CSP policies and custom OMA-URIs like in the example above.



The settings catalogue aims to bridge this discrepancy and is a potential one-stop-shop for Windows settings that can be customized. This tool streamlines the process of creating a policy and viewing all accessible settings and more configurations always being introduced.

At least that’s Microsoft’s hope.

The example we using to demonstrate this cool “new” feature

How does Windows know which users are allowed to login a device? Or in other words, how are the rights of the user determined? Sorry. I couldn’t resist. This is determined by UserRights, which are are applied at to a device on either the local level or via the domain. User rights permissions govern access to computer and domain resources, for example, who is allowed to log on to a device and how they do so.

Up until now, Intune has lacked a built-in method for customizing BUILTIN groups and User Rights much to the annoyance to the WinSysAdmins that have been governing User Rights via Group Policies for almost two decades.

Experienced Intune administrators are no strangers to creating custom CSP policies and I’d wager that most of them have at some point taken advantage of Windows’ BUILTIN groups for adding their AzureAD users. If you wanted to restrict local logons to certain users, you could add an AzureAD user like this using:

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/UserRights/AllowLocalLogOn

What if I told you there was an even easier way? Something that is now built into Intune and doesn’t require custom profiles? No more having to guess syntax, or strings, or values, etc. Don’t believe me? Then you haven’t been keeping with the times and need to check out how  create a policy using settings catalog in Microsoft Intune | Microsoft Docs!

 

And How do I use it?

Head over to Intune > Devices > Configuration profiles > + Create profile > Select the Windows 10 and later platform > And Settings catalog (preview) as the profile type

After giving your profile a name; click on + Add settings > Look for the User Rights category > Selected Allow Local Log On > and Select all these settings.

Alternatively, you can search for the setting you want:

But just be aware that Intune is as dumb as ever and there is not even a semblance of machine learning for better or for worse. So just keep that in mind.

This next part is what I like about the Settings Catalog. It makes adding multiple values a lot easier. For me at least. I’ve kept the default BUILTIN Administrators group in this example for a comparison I intend to make later in the post. More importantly; I’ve added the SIDs for my  Azure Administrators group and a group with the users the marketing department to further restrict who can log into the device.


Important note: The method this policy is maybe one the most dangerous policies for end user productivity to apply in a production environment if you’re not. You CANNOT just remove it without overwriting the values. The first time I applied this policy, I ended up having to wipe my test machine completely as I was not able to fix it. Maybe it’s been “fixed” but of laziness, I’m not going to try and replicate that error. So just make damn sure you’re both A) doing it right the first time around and B) YOU DO NOT APPLY THIS UNTESTED POLICY TO ALL DEVICES.

For example… this is what happened when I applied the policy and tried logging in with my favorite demo user.

Oh ok. It’s 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. Despite having done this before in a production environment, I seem to have made a mistake somewhere.

Mhm.

Well, lemons and lemonade. At least this will be some good troubleshooting content for this blog post 😅. In fact, so much content that it ended up being long enough that I needed to make a post just for it! So CLICK HERE (as soon as I finish writing it up. Even though I’m an idiot, it’s actually a pretty interesting read. In my opinion 😉) to read it!

Otherwise the tl;dr of it was… since the last time I did this, I’d forgotten than with an AADJ ONLY device, there are specific local groups whose memberships are evaluated for user rights assignments. So you still need to target a group that you’ll need to nest your group inside of one of these specific local groups. Namely these groups:

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

NAMELY USERS

I forgot the #!&%?! USERS group

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