Many situations have use cases for kiosk-type devices that need more functionality than a single-app kiosk. For those use cases, we steer towards shared devices or multi-app kiosks (now configured using assigned access). Back in the Windows 10 days, there was an actual multi-app kiosk profile template that we could use in Intune, but Microsoft never transitioned that over to Windows 11. For that, we need to use an Assigned Access XML profile. Assigned Access or Multi-App kiosks are ideal for shared devices with a specific use case. For example, break room computers, computers on a cart or an exam room, etc.
There are already several blogs and some good documentation on MS Learn on using Assigned Access, so I won’t go into the details on the configuration. If you’re interested in that, see the links below:
- Effortlessly Set Up Kiosk Mode in Windows 11 Today
- Deep Dive into Windows 11 Kiosks Part 1: Assigned Access
- Create an Assigned Access configuration file | Microsoft Learn
In assigned access situations, it’s often advantageous to have devices automatically sign in. Single App kiosks and Assigned Access profiles can do that, and most clients like this. In the assigned access profile, we simply use the <AutoLogonAccount> in our XML (Create an Assigned Access configuration file | Microsoft Learn):
Configs>
<Config>
<AutoLogonAccount rs5:DisplayName="KioskUser"/>
<DefaultProfile Id="{GUID}"/>
</Config>
</Configs>Using the AutoLogonAccount will generate a local user on the targeted devices using the DisplayName specified in the XML. Technically, this is using the kioskUser0 local account, but changing the FullName on that local identity so it displays nicer on the logon screen. If we look at the local user details on an assigned access device, we can see this:
OK – so this all seems pretty simple. I’ve had to do this for a couple of clients in the last few months, and in general, everything worked as intended after ironing out some of the required DesktopAppPath’s in the assigned access XML. However, I just implemented this for a client, and could not get the auto logon to function. Everything else would apply except for the auto logon. It would sit at the logon screen, and if we try signing in with our Auto Logon account, it wants us to change the password:
After doing some more research, the most likely issue was that there were EAS password restrictions on the device. The EAS policies are found under HKLM\SYSTEM\CurrentControlSet\Control\EAS\Policies, but that key wasn’t even present on my devices.
Microsoft also references this in the assigned access documentation for more information on the automatic logon (which is the legacy method). However, it states that if the defaultPassword string is not set in the registry, auto logon won’t function. In the case of Assigned Access, that’s not true since the string is not present on my other devices, which are working properly. We can see, though, that the other auto logon registry values are set to use the kioskUser0 account, so this is still referenced.
After digging into this some more, I found this Protecting the Automatic Logon Password – Win32 apps | Microsoft Learn, which is how assigned access works with the autologon account. This utilizes the LSA Store function to store the password for the autologon account, eliminating the need to set the DefaultPassword string in the registry. However, if the password cannot be found in the LSA Private Store, then it will fall back to the defaultPassword string if it exists.
OK – now that we have a better understanding of how this all happens on the back end when an auto-logon account is configured with the assigned access profile, back to my issue, where this wasn’t working. After double-checking my Assigned Access XML and finding no errors, and also deploying it in my test tenant and confirming it worked properly, I knew there was a configuration in my source tenant that was conflicting with this. After doing some comparing, I found this settings catalog policy setting:
And if we look at the registry for the affected device, we can see that password settings are applied to require a device password and minimum password length
If we look back at the warning from Microsoft:
In this case, EAS password restrictions are not active in their default registry location, but a machine password policy is still being applied. The machine’s password policy takes precedence and is still applied for an auto-logon account, even if it’s configured to use the LSA Store like it is for single app kiosks and assigned access profiles. This was causing the newly created account to be flagged to change the password, and breaking the auto-logon.
Filtering out the kiosk devices from that policy removes the DeviceLock registry key we saw above and the auto-login resumes working properly.