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?

Instead of attempting to using Microsoft Intune native configuration, we can lean on the registry setting to configure this CIS level 1 requirement:

To ensure it doesn’t break anything, we can deploy a remediation script to set the registry value, assigning the script to users, meaning that it won’t apply until after the Autopilot process has completed.

The detection script will look for the AutoAdminLogon string value, and if it does not exist, or it is not set to 0 will report an error:

Try {
    $registry = 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon'
    $setting = 'AutoAdminLogon'
    # Checks if the key and if the string value AutoAdminLogon exists
    Try {
        $value = Get-ItemPropertyValue -Path $registry -Name $setting
    }
    Catch {
        Write-Warning "$setting not configured."
        Exit 1
    }

    # if the key and dword exist checks the value.
    if ($value -ne '0') {
        Write-Warning "$setting enabled."
        Exit 1
    }
    else {
        Write-Output "$setting disabled."
        Exit 0
    }
}
Catch {
    Write-Error $_.Exception
    Exit 2000
}

With the remediation configured to create the AutoAdminLogon if required, and set it to 0, to disable this option:

Try {
    $registry = 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon'
    $setting = 'AutoAdminLogon'
    $path = Test-Path $registry
    # checks if the key exists, if not creates the key and AutoAdminLogon string.
    if ($path -eq $false) {
        New-Item -Path $registry -Force | Out-Null
        New-ItemProperty -Path $registry -Name $setting  -Value 0 -PropertyType String -Force | Out-Null
        Write-Output "$setting disabled."
        Exit 0
    }
    else {
        # checks if the AutoAdminLogon string exists, if not creates it.
        Try {
            # if the AutoAdminLogon dword exists updates it.
            Get-ItemPropertyValue -Path $registry -Name $setting
            Set-ItemProperty -Path $registry -Name $setting -Value 0
            Write-Output "$setting disabled."
            Exit 0
        }
        Catch {
            New-ItemProperty -Path $registry -Name $setting -Value 0 -PropertyType string -Force | Out-Null
            Write-Output "$setting disabled."
            Exit 0
        }
    }
}
Catch {
    Write-Error $_.Exception
    Exit 2000
}

Deploying this to a group of users in Microsoft Intune, with settings similar to the below, with a suitable evaluation schedule:

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 for Business policy to either your users or devices, 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 for Business should be used to protect accounts, but you’re stopping the use of convenience PINs, that are required to setup Windows Hello.

As pointed out in the comments, this isn’t strictly true; although Windows Hello and Windows Hello for Business share the same “Windows Hello” family name, they aren’t actually related, sort of like a step-brother 👀 setup.

So although the above setting will stop a user from setting up a PIN in the more traditional sense, it will not stop the Windows Hello for Business configuration from applying.

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.