Restricting the local log on to specific users

by

This week is about restricting the local logon on Windows devices to specific users. Not because it is something particularly new, but simply because it is been an ask every now and then. Think about further locking down a kiosk device, for example. Restricting the local logon can be achieved by either only allowing specific users to log on, or by denying specific users to log on. In other words, whitelisting versus blacklisting. The allow-option is basically a whitelist and the deny-option is basically a blacklist. When looking at restricting the local logon, a whitelist is the easiest method to get quickly really restrictive, as only the users on the list are allowed to log on locally. Luckily, nowadays there is easy method for configuring such a whitelist with users that are allowed to log on locally on a Windows device. This post will provide some more details around that configuration, followed with the configuration steps. This post will end with showing the user experience.

Note: Keep in mind that this post is focussed on the local log on on Windows devices and not the remote log on.

Configuring the allow local log on setting

When looking at configuring the allow local log on configuration, the UserRights section in the Policy CSP is the place to look. That section contains many of the different policy settings of the User Rights Assignment Local Policies, including the Allow log on locally (AllowLocalLogOn) policy setting. That policy setting can be used to configure the users that are allowed to locally log on to the Windows device. Besides that, it’s also good to mention that with the latest Windows 11 Insider Preview Builds, this section of the Policy CSP, is getting more and more policy settings. Nearly all of the User Rights Assignment Local Policies are now available for configuration, including Logon as a service, Logon as a batch job, and many more. Maybe even better, all of these available policy settings – including the new policy settings that are currently still in preview – are now configurable via the Settings Catalog profile (as shown below in Figure 1).

Figure 1: Overview of the available policy settings in the User Rights section

After being familiar with the available policy settings and the configuration profile, the configuration of those policy settings is pretty straight forward. The following eight steps walk through the creation of a Settings Catalog profile that contains the required setting to configure the local logon, by using the Allow log on locally policy setting.

  1. Open the Microsoft Intune admin center portal and navigate to Devices > Windows > Configuration profiles
  2. On the Windows | Configuration profiles blade, click Create profile
  3. On the Create a profile blade, provide the following information and click Create
  • Platform: Select Windows 10 and later to create a profile for Windows 10 and Windows 11 devices
  • Profile: Select Settings catalog to select the required setting from the catalog
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a name for the profile to distinguish it from other similar profiles
  • Description: (Optional) Provide a description for the profile to further differentiate profiles
  • Platform: (Greyed out) Windows 10 and later
  1. On the Configuration settings page, as shown below in Figure 2, perform the following actions
  • Click Add settings and perform the following in Settings picker
    • Select User Rights as category
    • Select Allow Local Log On as setting
  • Specify the required users and local groups – all on separate lines – and click Next
Figure 2: Overview of the configuration of the required setting
  1. On the Scope tags page, configure the required scope tags and click Next
  2. On the Assignments page, configure the assignment and click Next
  3. On the Review + create page, verify the configuration and click Create

Note: As these settings are now configurable via the Settings Catalog, that also takes away the challenges with multiple entries. No need to manually specify a delimiter, as Microsoft Intune takes care of that.

Experiencing the user rights configuration

After configuring the users that are allowed to log on locally to the Windows device, it’s pretty straight forward to experience the behavior. Simply try to log on to that device with a user account that is not allowed to log on locally. That will provide an experience as shown below in Figure 3. The user will receive the notification that the sign-in method is not allowed. Besides that, it’s also important to be familiar with the side effects of this configuration. The most important side effect is the impact on the self-service capabilities, like self-service PIN reset and self-service password reset. That’s simply because those capabilities rely on the temporary account defaultuser1 and that account won’t be able to log in, as only the specified users are allowed to locally log on to the Windows device. That experience is shown below in Figure 4. The user will either receive the status message of 0xc000015b, or will simply be switched back to the logon screen.

Figure 3: Overview of the user experience
Figure 4: Overview of the user experience with self-service

Note: The failed log on information is registered in the Security log in the Event Viewer with Event ID 4625.

More information

For more information about the user rights configuration options, refer to the following docs.

Discover more from All about Microsoft Intune

Subscribe to get the latest posts sent to your email.

54 thoughts on “Restricting the local log on to specific users”

  1. I’d like to contribute to this.

    This method does not inherently allow you to specify an EntraID group of users that you wish to deny local logon (at least it didnt use to)
    however i’ve found that if you use “account protection” policies populate the local group “Guests” with users from an EntraID group you can use the above stated policy to in effect acheive deny local logon for an EntraID group of users. (Via denying the local group “guests” as stated in your blog)

    I use this in production, works well

    Reply
  2. Pingback: Microsoft Roadmap, messagecenter en blogs updates van 21-09-2023 - KbWorks

  4. Is there currently a way to restrict interactive log in but allow elevation log in prompts? I would like to prevent Intune Admins from logging in locally but still allow elevation for installs/CMD.

    Reply
  5. Pingback: Intune Newsletter - 22nd September 2023 - Andrew Taylor
  6. Pingback: Enabling remote access for specific users on Azure AD joined devices – All about Microsoft Intune

      • Hi Peter,

        We have deployed Self-Deploy AutoPilot profile plus Kiosk Configuration Profile for single app and then assign to dynamic device group. The Self-Deploy AutoPilot process completes without any issues and Kiosk policy is applied to the device. However, the KioskUser0 should auto logging automatically after Self-Deploy AutoPilot process completes, but its not auto logging.

        Any thought why KioskUser0 not auto logging automatically?

        Reply

  9. Hello Peter,

    We have Azure AD Joined devices in our enviornment which are migrated from source tenant to target tenant as part of carve out project. Recently we observed that post autopilot build completition when user tried to sign in to device they were prompted error as Sign in method not allowed. However, if we tried to login to device with local admins then it allows.

    Standard users not allowed to login, we do have AllowLocallyLogIn baseline policy deployed by security team but it contains Administrators and Users group both. Does on Azure AD joined devices this policy really gets validated when users trying to sign in with UPN ?

    This issue is not for all users but 10% users are facing, as a workaround when we reimported hash of thier device again and reimaged device then sign in was allowed (bit strange).

    Do you have any idea on this then please give some direction.

    Reply

  10. I tried to do the restriction as in your procedure, but I got the error 65000 in intune.
    Since then, it has been impossible to connect with ALL the accounts on the computer.
    Do you have a solution to go back?

    Reply

  11. I’ve had a similar issue. What would the correct counter policy be to reset the default logon configuration or do you have an article that details that?

    Reply

  12. Hi Peter

    I know this has been a bit since you created this article, but have you been able to automate the AllowLocalLogOn to only the primary user?

    I’ve been looking into this my self, but I don’t seem to be able to automate it via policy. The only way seems to be script based?

    Reply

  14. Hi Peter,
    First of all, thank you very much for all your help and guidance.

    I managed to block sign-in Autopilot Windows Clients for members of an AAD group (EntraID group) by adding the group to the local guest group(Endpoint security | Account protection) and then “denying local log-on” using the Configuration setting “User rights.
    Do you know how often the group membership is checked?
    My issue is that I have added a User to the AAD Group to block access, and it works fine.
    Now, I have removed it from that group again, but the SIgnIn is still denied.

    Regards, Matthias

    Reply

  15. I have encountered the same behavior. The user was previously added to the local guests via an Entra group and the local login was forbidden for guests. but even if I remove the user from the guests again, the local login is still denied. Message “The sign-in method you’re trying to use isn’t allowed”. This looks as if the setting cannot be reversed, which is somewhat unfortunate.

    Reply

  16. Hi Peter, thanks for this blog. I did configure this policy and deployed it to the Azure AD group which had 1 device. I have also added the AAD user as (AzureAD\)

    But it fails to recognize the user, I also got 65000 error in policy status.

    I’m not able to understand how to target an AAD group or an AAD user to this configuration policy so that only that user can access a particular device.

    Reply

  17. I have a hybrid environment and I would like to enable only the administrators and the primary user, how do I do this? because in the article you specify an e-mail, I can’t make a profile for each machine. I have 12k devices

    Can you help me?

    Reply

  18. Do you know of a way for this to allow Web sign in? Added WsiAccount to the allowed list, which then allows the web sign in portal to load, but then signing in, it just loops back to the sign in.

    Reply

  19. Hi Peter. I hope you’re still watching the comments here, because I’m at my wit’s end and I’m hoping you might know what’s wrong.

    I’m rolling out Intune and Autopilot to a client. This client has a handful of stations they want to use in single-app Kiosk Mode with auto logon. I’ve created the Kiosk Mode profile and it works great. However, the client also wants to ensure that only the KioskUser0 account created by the Kiosk Mode policy and the LAPS local admin account are allowed to login, with all others being designed.

    I created the Allow Local Logon policy using the version from the Settings Catalog like this article discusses and applied it only to the Entra ID group that contains the kiosk machine names. It is presently set to allow the following users to login:

    KioskUser0
    Administrators
    Local account

    I’ve also tried putting .\ in front of the local account names.

    When the machines have this policy applied, *everything* is denied login. If you try to login with any of the above accounts, you will get the “sign-in method not allowed” error. If a machine is provisioned with the Kiosk Mode policy, but without this restriction policy, everything works fine.

    I have spent hours and hours trying to figure this out. Everything is setup exactly as it should be as far as I can tell. Intune doesn’t say there are any policy conflicts, and I even completely disabled the Windows Security Baseline policy to make sure. This client isn’t big and only has about a dozen policies, and none of the others have anything to do with login restrictions.

    The client needs this setup to work, but I don’t know what else to do and I know Microsoft support will be useless on this, as they typically are. Do you have any suggestions or have you ever seen this before and figured out what it was? I’d be very appreciative for your insights.

    Cheers!

    Reply

    • Hi Gerry,
      Often a scripted solution provides a bit more stability. That being said, I would at least expect the Administrators to work. But for that I’m assuming your not using a group as member and not use a different language.
      Regards, Peter

      Reply

      • That’s what’s so weird. Enabling this policy, seemingly no matter how I configure it, just seems to break all logins. It’s baffling. The Kiosk Stations group only has devices in it and that group is assigned to the policy, but it’s not in the allowed login list. As far as I can tell, only accounts need to be added and this policy doesn’t block anything related to machine names. Is that correct?

        When you say a scripted approach is more stable, do you know of any guides that explain the best way to achieve that?

        Thanks again!

        Reply

          • Yes, this is a kiosk device, so local login to the kiosk account and the LAPS-managed local admin account are all that’s required. But neither of them can do that with the policy as I showed it in my original comment. Any thoughts on why this could be or if there’s something else that can conflict with it? The policy shows no conflicts in Intune and security baselines are disabled.

            Thanks.

          • Fun thing is that somebody reached out to me via another channel, with exactly the same. Which platform are you using? Also, have you tried if you could configure the local policy (to see if that’s working at all)?
            Regards, Peter

          • So if you can believe it, I found the answer in a comment on a year old Reddit post. The solution was to exclude the kiosk systems from the Compliance Policy, even though the policy had nothing to do with restricting logins. This is believed to be a bug on the Microsoft side that has still not been patched. It’s ridiculous, but it did the trick. We’re fine excluding this small handful of machines from the Compliance Policy.

        • I’ve found using the deny method to be more stable, assumin entraID only device (not hybrid) i would create (or reuse) a AAD group which simply contains all users which is not supposed to login, from here use account protection policy to assign that group to the local guests group on the device.

          With this down simply deny local logon for the local guests group.
          Then you should be able to leave the allow interactive logon setting to default and the local accounts should keep working while Entra accounts are blocked

          Reply

Leave a Reply to Peter van der Woude Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.