Monday, January 24, 2022

The Return of the Autopilot Local Account Massacre

Must read

avatar
Rudy Oomshttps://call4cloud.nl/
Rudy is a Modern workplace architect and currently working for a company in the Netherlands, called Deltacom Steenbergen. He has been working in IT since he was 16 years old. Within these years, he gained a lot of experience in different kinds of expertise. I guess like most of you, he started working with active directory environments. In June 2021 he received the MVP status in the category Enterprise Mobility for the first time. The multi-tenant PowerShell scripted Deltacom-Cloud environment is one of his creations.

This blog will be about “something” old we need to beware of. It has something to do with Autopilot and performing a lockdown on the device to make sure your end-user isn’t going to create a local account on your Autopilot enrolled device.

Some weeks ago a customer called us that his new device wasn’t working. I am going to explain what happened.

I will divide this blog into multiple parts.

  1. Locking down the “Change Account” options
  2. The Real issue
  3. How to Solve it, in the good old days
  4. How to solve it now?
  5. The PowerShell Script

Please note that I need the create a nice introduction, so this first part is nothing new but only necessary to start my story.

I guess the picture below, says it all. Way way back, when your 4K HH was uploaded into the EKPub allow list of Intune/Azure Ad, it was still possible for the end-user to click on the “Change Account” to start creating a local account instead of enrolling the device into Azure Ad and Intune.

Of course, we don’t want that! Luckily Microsoft came up with a solution. Let’s take a look at what Microsoft tells us about this fine option

“Options to change account and start over with a different account appear, respectively, during initial device setup on the company sign-in page, and on the domain error page. To hide these options, you must configure company branding in Azure Active Directory (requires Windows 10, 1809 or later, or Windows 11).”

Okay, Hell yeah that sounds great! let’s lock it all down by configuring the “Hide Account Options” in your Autopilot Profile

Okay..editing an existing Autopilot Profile to change this setting is still not fixed after some years but… who cares 🙂 . Hopefully, everyone who is creating a new Autopilot profile will make sure this setting is configured to “Hide

Now let’s how it looks when we are enrolling a new device.

Of course, the option to click on “Change Account” is gone! Blog done!, let’s have a drink, right?

Trade Coffee GIFs - Get the best GIF on GIPHY

Guess again!” This blog will show you more than how to remove the change account option. So let’s take a look at the real issue.

Like I was telling you at the beginning of this blog, a customer called us that his new device wasn’t working.

So we wanted to perform a Take control session to take a look at what was happening but the device wasn’t enrolled in our RMM tool. That’s odd because every device that performed an Autopilot would have that tool installed.

Okay, no big deal as the customer could open TeamViewer (as we normally allow it in the Applocker Policy)

After logging in on the device we noticed that the device was missing a lot. It was not Azure Ad Joined/ Not MDM enrolled nothing. How did that happen?

After talking to some colleagues, there was also a miscommunication about what kind of license the user was going to use. At first, the user wasn’t going to use a device only the Exchange Online features so he didn’t need an Ms365 Business premium license. But after a while, the customer decided he needed a notebook after all and gave him one.

Please note that this particular device wasn’t Autopilot pre-provisioned

So the employee turned on the device and wanted to log in but as he doesn’t have the proper license, he wasn’t allowed to enroll the device.

So after a couple of tries, he tried a different User Principal Name. Why? Because he had the idea maybe he needed to enter one of the company’s other domains. And that’s when he was prompted with this nice screen

Afbeelding met tekst  Automatisch gegenereerde beschrijving

He was given the stupid option to “set up Windows with a local account”. Why the heck should a Device enrolled into Autopilot prompt you to create a local account. To be sure we weren’t going crazy we tested the same on multiple Windows Builds)

*Windows 10 (2004/20h2/21H1/21H2/Pro/EnterPrise/Education)

“set up Windows with a local account” is possible!

Afbeelding met tekst  Automatisch gegenereerde beschrijving

*Windows 11

Luckily in Windows 11, it’s working as it should! and NO option to “set up Windows with a local account”

Afbeelding met tekst  Automatisch gegenereerde beschrijving

When using Bing, and searching for this topic, you will end up with some options to make sure, your device is locked down into your Office 365 Tenant and the user needs to sign in with a valid UPN from that same tenant.

So let’s take a look at some options

1. Configuring the “require users to connect to network during device setup”

Okay, this option speaks for itself. As you will need to have a network connection at the device setup. So let’s enable it. You could do so by creating a new device restriction in Intune and configuring the “require users to connect to the network during device setup”.

r/Intune - Autopilot prevent users creating local account via OOBE

But to do so you will need to make sure this Device Restriction was deployed to your device before you enroll it. So the only option you have is to perform an Autopilot pre-pre provisioning / White Glove.

I had to break it to you but that option isn’t going to solve the issue we have, let‘s move further.

2. Assigning the Device to a User

Okay, Okay this option sounds great because you are assigning the Autopilot Device to a specific user. It WAS very simple to do

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Now, let’s take a look at what it looked like when you assigned the device to a specific user. As shown below, you didn’t have the option to select a different email domain anymore!

So the possibility to log in with a wrong UPN and end up with that stupid local account creation question was gone! But again, I hate to bring bad news because that option isn’t’ available anymore after the MC288489 Update that came along with the big change*MC289488.

* MC289488. Adding in a step to delete the device record as part of the device re-use process

With this MC288489 update, some stuff changed.

“Users enter their credentials at initial sign-in during enrollment. We no longer allow pre-population of the Azure Active Directory (Azure AD) User Principal Name (UPN).”

So the only option to lock down the device is shot down?

Shooting gun gif images

Beware to make sure this solution works, you will need to perform a white glove, just like you needed to do with the network requirement I showed you earlier.

First I need to point out another blog of mine, that is describing the whole Autopilot flow.

If you have read this blog, you probably noticed the Windows.CloudExperienceHost part. When you turn on your Autopilot device, it will end up in the Cloud Experience Host. This one will launch the InclusiveOobe Web App.

So I decided to take a look at what’s inside this nice Web App. After some digging around in the files I stumbled upon the “OOBELocalAccount-Page” file in the JS folder after watching ProcMon.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

It looks like this JS file is responsible for Local account creation during the OOBE Process. But what to do now? Let’s dig deeper to find which file calls upon this JS file. I used a text crawler to search for this OOBELocalAccount-Page.

Duh.. Of course, it is the OOBELocalAccount-Main HTML file that calls upon the JS file. You can find that file inside this folder:

C:WindowsSystemAppsMicrosoft.Windows.CloudExperienceHost_cw5n1h2txyewywebappsinclusiveOobeview

Image

After opening that JS file, I had the crazy idea to just remove that line from the HTML file. Of course, I needed to take ownership of that file first to change it. But after I removed that part I tried to click on the “set up Windows with a local account” button again. This time It didn’t ask me to create a new local user account but showed me a nice OOBELOCAL error

Image

So that one is definitely working. I also tried to remove the LocalUser Plugin from the OOBE component in the registry with the CLSID 68DB2410-63D2-4D4A-9449-FBD53FA4E7A3.

ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionOOBEComponentsPluginsLocalUser Plugin

Afbeelding met tekst  Automatisch gegenereerde beschrijving

But that didn’t work… so I stuck to my first idea. So Let’s do some basic PowerShell

So download this PowerShell script and test it out for yourselves.

#######################
#Configure variables #
######################

$Account = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList 'BUILTINAdministrators';
$ItemList = Get-Item -Path C:WindowsSystemAppsMicrosoft.Windows.CloudExperienceHost_cw5n1h2txyewywebappsinclusiveOobeviewoobelocalaccount-main.html

####################################
# Get a list of folders and files  #
#####################################

# Iterate over files/folders
foreach ($Item in $ItemList) {
    $Acl = $null; # Reset the $Acl variable to $null
    $Acl = Get-Acl -Path $Item.FullName; # Get the ACL from the item
    $Acl.SetOwner($Account); # Update the in-memory ACL
    Set-Acl -Path $Item.FullName -AclObject $Acl;  # Set the updated ACL on the target item
}

###########################################
#Change nt authoritysystem permissions   #
###########################################

$myPath = $itemlist
# get actual Acl entry
$myAcl = Get-Acl "$myPath"
$myAclEntry = "nt authoritysystem","FullControl","Allow"
$myAccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($myAclEntry)
# prepare new Acl
$myAcl.SetAccessRule($myAccessRule)
$myAcl | Set-Acl "$MyPath"
# check if added entry present
Get-Acl "$myPath" | fl

###############################################
#Change builtinadministrators permissions   #
##############################################

$myPath = $itemlist
# get actual Acl entry
$myAcl = Get-Acl "$myPath"
$myAclEntry = "builtinadministrators","FullControl","Allow"
$myAccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($myAclEntry)
# prepare new Acl
$myAcl.SetAccessRule($myAccessRule)
$myAcl | Set-Acl "$MyPath"
# check if added entry present
Get-Acl "$myPath" | fl


###############################################
#remove the option to add a local account in oobe  #
##############################################

$data = foreach($line in Get-Content $itemlist)
{
    if($line -like '*/webapps/inclusiveOobe/js/oobelocalaccount-page.js*')
    {
    }
    else
    {
        $line
    }
}
$data | Set-Content $itemlist -Force

The possibility to create a local user account during Autopilot is crazy. It’s not the fact that it could be abused but why is that option there? In the past, you had a good option to make sure the end-user couldn’t switch to another domain name, but that one is gone for good!

So I am not saying you need to use my PowerShell script, I just wanted to show how it could be blocked… Hopefully, Microsoft will come up with a way better solution.

Modern Problems Solutions GIF - Modern Problems Solutions Dave Chapelle GIFs

More articles

Leave a Reply

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

Latest articles