Restricting the local log on to specific users

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).

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
  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.

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.

31 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

  2. 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.

      • 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?

  3. 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.

  4. 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?

  5. 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?

  6. 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?


Leave a Comment

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