Patching Gaps in the CIS Windows 11 Benchmark - Level 1 Windows Autopilot

We started with the BitLocker and DMA (Direct Memory Access) settings in the first post in this Windows 11 CIS benchmark based series, now is the time we dig deeper into the broader Level 1 settings, this time looking at the impact to Windows Autopilot cloud native deployments.

Jonathan has more than enough experience with testing these policies and the impact to Windows Autopilot, as I made asked him to help me review the impact of them following his initial run in with the community version of the CIS Microsoft Intune templates.

So please send him your thanks, as without his turmoil of dealing with the CIS policies breaking his devices, and the constant nagging from me as to when he’s done with testing and finding solutions, there wouldn’t be the content for this post or in fact the series.

Right, onto the fruits of my our labour.

CIS Level 1 Settings

#

We already have a grasp of the settings that cause problems with Windows Autopilot, so we can start to try and find solutions to the discovered issues, all without reducing the overall security of the Windows 11 operating system too much 🤐.

There might be a surprising amount of wiggle room with some of the CIS Level 1 benchmark settings, that maybe aren’t entirely obvious at first, starting with the documented problems…

Disable Automatic Admin Logon

#

You’re correct CIS, of course you should disable the use of automatic logons for administrator accounts, and it should be implemented without hesitation.

No one should be automatically logging on to a Windows device as a administrator, unless you’re maybe defaultuser0 as part of the Windows Autopilot process right?

The above configuration, will bin out the Enrolment Status Page, reboot, and leave you with a Windows Autopilot device at a logon screen with the defaultuser0 being your only option for sign in, and pretty much nothing from Microsoft Intune applied to it:

We did already know about the AutoAdminLogon setting causing the issue with Windows Autopilot, as it is documented, but who has time to read all of these articles 😂.

But how do we stop this from breaking Autopilot exactly? Well after having a browse of the Policy CSP for this setting, it turns out that this policy is only supported on the following versions of Windows, and for us we only care about Windows 11:

• Windows 10, version 2004 (10.0.19041.1202) and later
• Windows 10, version 2009 (10.0.19042.1202) and later
• Windows 10, version 21H1 (10.0.19043.1202) and later
• Windows 11, version 21H2 (10.0.22000 and) later

So assuming you’re not running a soon to be unsupported version of Windows 11 😐, we can either ignore this setting entirely (don’t do this), or strip the setting out of the CIS profile, and create a new Custom Profile with this specific setting:

To save you creating Dynamic Security Groups for each supporting Windows version, you can assign the profile to all corporate owned devices using an existing group, or device filter and built-in group, and use Applicability Rules in the Custom Profile, to only apply the profile if the rules are met.

This means that as the setting is only causing impact to Windows Autopilot deployments, then you should be in the clear when deploying new devices, or resetting existing ones with newer Windows 11 operating system versions.

Interactive Logon Messages

#

More breaking of Windows Autopilot, this time with pre-provisioned deployments, with another known and documented feature problem. Thanks CIS 😬.

I know a logon message is important, and is included in other security baselines and not just for Windows devices either, but come on now, do we really need this?

Well yes if you want to stick with the CIS benchmark.

So once more to stripping out this setting into a separate profile, this time keeping the same configuration settings, but assigning this to all your corporate-owned devices, but excluding a group of Windows Autopilot devices configured for pre-provisioned deployments using rules based on the enrollmentProfileName associated with the device.

Don’t forget to actually configure these settings, unlike in the CIS profiles where they’re just set to Test test test 😂:

Virtualization Based Security

#

We’d encountered a rogue device restart during Windows Autopilot when configuring a BitLocker PIN, which did actually work to our advantage, but what caused them?

Yeah it’s those ones, that are specifically called out to cause device restarts.

These policies require a reboot… to work around this issue, the policies can be targeted to users instead of devices so that they apply later in the process.

Luckily for us we’ve been given a workaround, just assign the CIS (L1) Virtualization Based Technology - Windows 11 Intune 3.0.1 profile to a group of users instead of devices.

Strangely enough this isn’t mentioned in the CIS documentation anywhere, so thanks to Microsoft for looking out for us.

Disable Network Selection UI

#

We’d come across this issue one a while ago, with the below setting stopping users from connecting to a new wireless network at the logon screen. You’d think this wouldn’t be too much of an issue, even during User-Driven Windows Autopilot, but where it does become a problem though, is with pre-provisioning.

With a user deploying their own device, they’re asked to connect to a wireless network (who has network cables in their own house? Jonathan apparently 😅) before starting Windows Autopilot, so this network will now be available at logon, and no need to select a new one.

With pre-provisioned deployments, only the network that was connected to during deployment, and/or wireless or wired networks deployed to the device from Microsoft Intune are available to connect to from the logon screen.

Meaning if you build devices on-premises, and then give them to end-users to take home, with the setting above, they won’t be able to connect to a new network from the logon screen.

Saving changing this across all devices, as it only impacts Windows Autopilot devices, you can remove this setting from the benchmark profiles, and create a new policy with the below settings:

Then assign it to your corporate devices, excluding Dynamic Security Groups containing Windows Autopilot Devices where their profile allows the use of pre-provisioning as in the Interactive Logon Messages section.

This will enable these devices, and these only, to select a new network not previously connected to, before logging onto their device, which if they’ve been deployed somewhere other than the current location, means they can actually sign in 😆.

Windows Hello for Business

#

Now Windows Hello for Business isn’t strictly a Windows Autopilot thing, but if you’re deploying a Windows Hello policy to either your users, then they’re going to get prompted to configure Windows Hello when they sign in.

So we were happy to see the use of Windows Hello for Business as an authentication method, to add multi-factor authentication to Windows 11 accounts, recommend by CIS 🎉.

You haven’t configured additional settings somewhere else that will impact the use of Windows Hello have you CIS?

What’s that? You have? You’re advising that Windows Hello should be used to protect accounts, but you’re stopping the use of convenience PINs, that are required to setup Windows Hello.

Are you ok CIS?

Quick fix though, just change the above setting if and only if you’re actively using Windows Hello for Business, from Disabled to Enabled:

Be aware though, there are settings in the CIS (L1) Device Lock & WHFB - Windows 11 Intune 3.0.1 profile, that will impact the configuration of Windows Hello if you don’t have a policy in place to require PIN complexity settings.

Yeah, it’s these ones they’re talking about.

So make sure you’ve got a Windows Hello for Business policy already created and deployed to your users, with at least the below setting configured to enable Windows Hello for Business.

With the above configuration, your users will get the post logon Windows Hello experience following a successful Windows Autopilot deployment.

Summary

#

We did say that the impact of the CIS Level 1 settings on Windows Autopilot was going to be a little difficult to deal with, but we got there, with some creative assignments, mild exclusions, and a little bit of common sense.

Security and end-user experience don’t tend to wander off hand in hand into the distance to live happily ever after, but there is now a way to deal with these issues using Microsoft Intune native tooling, and a good understanding of the application of the CIS benchmark.

The next chapter in this investigation of the CIS benchmark for Windows 11 covers the impact on the wider Windows 11 operating system, and happily there aren’t as many things that break functionality. There are however, some interesting choices.