Fixing self-service when restricting the local log on

This week is a quick follow-up on the post of last week. That post was focussed on restricting the local log on to Windows devices. Part of that post was also the broken self-service password reset and self-service PIN reset functionalities. When using the most restrictive option of a whitelist, for configuring the users that are allowed to log on locally, that will break those functionalities. This week will be all about a follow-up on that behavior. When it’s required to restrict the local log on Windows devices, and users should still be able to use the different self-service functionalities, this post will provide a solid starting point. Of course, that’s not applicable to every scenario. Only scenarios in which there are actual users logging on with an Azure AD account, and self-service functionalities are available. This post will provide some more details about the challenge and the possible solution. This post will end with the configuration steps – of which some might look familiar – and 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.

Describing the challenge and a possible solution

The challenge with restricting the local log on, on Windows devices, starts when using a whitelist that doesn’t contain the local Users group. That’s because the self-service password reset and the self-service PIN reset functionalities, rely on a low-privilege temporary account named defaultuser1. That account is temporarily created when the user wants to perform a password reset, or a PIN reset, and used for the temporary log on to Windows that will facilitate the reset functionality. However, that action will fail when the local Users group is no longer allowed to log on locally. In that case, the user will receive the message that something went wrong (error: 0xc000015b), or the user will automatically return to the logon screen. Besides that, there will be a message about the failed log on registered in the Security log in the Event Viewer with Event ID 4625. That message basically provides the same error message as the user might see on the logon screen.

To address this challenge, there must be a method to still allow that temporary defaultuser1 account to log on locally. Only providing that account with the allow local log on right is not an option, as that account doesn’t exist when it’s not used. As an alternative, the Local account (S-1-5-113) is the closest alternative. That SID is added to the access token of a local account at the time of logon. So, it’s not a group that you can add a user to, it’s actually much easier, as it’s not specific to a user or group. That will help for providing the local log on right to the defaultuser1 account, as it’s possible to use that Local account SID.

Important: Keep in mind that using the Local account SID is applicable to all local user accounts on Windows.

Configuring the allow local log on setting

The configuration is similar to last week. Same policy setting. Just a slightly different configuration. So, simply rely on the Allow log on locally (AllowLocalLogOn) policy setting that is available in the UserRights section in the Policy CSP. That policy setting can be configured by using the Settings Catalog. After being familiar with the available policy setting and the configuration profile, the configuration of that policy setting 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 and adding the Local account.

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

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

5. 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 – including Local account and click Next

6. On the Scope tags page, configure the required scope tags and click Next
7. On the Assignments page, configure the assignment and click Next
8. 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.

When looking at automating this configuration, in case more flexibility is required, the MDM WMI Bridge Provider can be used. That provides access to the Policy CSP, via PowerShell. Configuring the required policy setting can be achieved by using the class MDM_Policy_Config01_UserRights02 with the instance UserRights and the property AllowLocalLogOn.

Experiencing the user rights configuration

After configuring Local account with the allow log on locally right, experiencing the behavior is pretty straightforward. From the Windows logon screen, the user will be able to use the self-service password reset and self-service PIN reset functionalities. So, that’s not that exiting to look at. Probably the most interesting to show, would be the Security log in the Event Viewer with Event ID 4624. That will now show a successful new logon for the defaultuser1 account (as shown below in Figure 3).

More information

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

• UserRights Policy CSP – Windows Client Management | Microsoft Learn
• Self-service password reset for Windows devices – Microsoft Entra | Microsoft Learn
• Well-known SIDs – Win32 apps | Microsoft Learn