Last Updated on July 20, 2022 by rudyooms

This blog will be about “something” old we need to beware of. This blog has something to do with Autopilot and performing a lockdown on the device to make sure the possibility to “set up Windows with a local account” will be disabled

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. Did Microsoft Fix it Update 09-02-2022?
2. Locking down the “Change Account” options
3. The Real issue
4. How to solve it, in the good old days
5. How to solve it now?
6. The PowerShell Script
7. What this PowerShell script also solves
8. OOBEAADV10

1. Did Microsoft Fix it? UPDATE 09-02-2022

It “looks like” it’s fixed!!!!! When enrolling a new device targetted with Autopilot the possibility to “Setup Windows with a local account” is gone after entering a wrong username!!! It now only tells us: “We didn’t find that email address in your organization. Use another email address or contact your administrator”

But not let’s start celebrating yet….! Because you could still enter “User@Example.com” as username

After pressing next you will be transferred to the Login Page for your Organization

At that point, you will be prompted with the famous error: OOBEAADV10 and the fact that something went wrong, but you could just click “Skip”?

After skipping this page you still have the option to create a local account and it will ask you who is going to use this device

So I guess it’s not totally fixed yet, hopefully, this bad user@example.com option will also be blocked!

2.Locking down the “Change Account” Options

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?

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.

3.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, but only the Exchange Online features. So you could say the user 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 attempts, the user 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

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 and up

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

*Windows 11

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

4. How to solve it in the good old days

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

But to do so you will need to make sure this Device Restriction is 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 hate 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

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. Add in a step to delete the device record as part of the device re-use process during Autopilot pre-provisioning. If you don’t delete the Intune object you will end up with the “We couldn’t finish MDM enrollment. Error 0x80180014″ during the MDM enrollment

With this MC288489 update from above, some other important stuff also 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?

5.How to solve it now?

Please Note: To make sure this solution works, you will need to perform an Autopilot 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.

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:\Windows\SystemApps\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy\webapps\inclusiveOobe\view

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 something went wrong error

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.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\Components\Plugins\LocalUser Plugin

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

6. The PowerShell script

So download this PowerShell script and test it out for yourselves. Upload this PowerShell script into your Office365 tenant and make sure it is assigned to your Autopilot devices.

When it’s assigned, you can perform a white glove to make sure this PowerShell script is deployed and executed on the device.

Another possibility would be to make sure this PowerShell script is already on the device, by altering the installation media. An example would be to add a new line to the SetupComplete.cmd to make sure this PowerShell script is executed after installation.

UPDATE 08-01-2022

I wrote the first version only to make it work… but it wasn’t that nice…as a good example, when running the first version you will end up with errors in your PowerShell script monitoring. So I decided to improve it a little bit

##########################
#trying to get the file #
########################

$Account = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList 'builtin\Administrators';

try
{
	$Itemexists = test-path 'C:\Windows\SystemApps\*\webapps\inclusiveOobe\view\oobelocalaccount-main.html'
	$ItemList = Get-Item -Path C:\Windows\SystemApps\*\webapps\inclusiveOobe\view\oobelocalaccount-main.html
}
catch
{
	write-host "an error occurred"
        exit 1
}



####################################
# change owner of the file         #
#####################################


if($Itemexists)
{ 

	$Acl = $null; 
    	$Acl = Get-Acl -Path $Itemlist.FullName; 
    	$Acl.SetOwner($Account); 
    	Set-Acl -Path $Itemlist.FullName -AclObject $Acl; 
}else{ 
	Write-Host  "File not found!"
        exit 1            
}


###########################################
#Change acl permissions                  #
###########################################


try
{
	$Acl = Get-Acl -Path $Itemlist.FullName; 
        $owner = $acl.owner
}
catch
{
	write-host "owner not found"
        exit 1
}



if ($owner -eq $account)      
{
   	$myPath = $itemlist
	$myAcl = Get-Acl "$myPath"
	$myAclEntry = "nt authority\system","FullControl","Allow"
	$myAccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($myAclEntry)
	$myAcl.SetAccessRule($myAccessRule)
	$myAcl | Set-Acl "$MyPath"
	

	$myPath = $itemlist
	$myAcl = Get-Acl "$myPath"
	$myAclEntry = $account,"FullControl","Allow"
	$myAccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($myAclEntry)
	$myAcl.SetAccessRule($myAccessRule)
	$myAcl | Set-Acl "$MyPath"
	
}else{
       Write-Host "Permissions couldnt be changed"
       exit 1
}



###############################################
#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
exit 0

7. What this PowerShell script also solves

When you deploy this PowerShell script you are also fixing another famous “bypass”. Michael Mardahl somehow convinced me to add this part to this blog. I was aware of this bypass but as it didn’t match the customer story I didn’t add it…. at first, but let’s move on 🙂

So what bypass are we talking about?

When you have entered your username and password to start enrolling your device with Autopilot you will be prompted to “Please wait while we set up your device”

At that moment the only thing you need to do is to remove/disable your network connection and you will be prompted with this window below. It will show you the server error code: 80192ee2 and the message that something went wrong. Looking at the bottom you will notice the possibility to click on “Offline Account“.

Luckily when you have deployed the PowerShell script I mentioned in part 6, there is no option to create the “offline account” and you will get the famous Something Went Wrong OOBEAADV10 error after pressing the “offline account” button!

8. OOBEAADV10

I guess after the Autopilot issues last week (EDIT and again on 08-03-2020), I need to explain this OOBEAADV10 error a little bit better. I decided to move this part over to a dedicated blog

Conclusion

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.

I guess Microsoft is listening to us! “Microsoft is working on it and it is a real high top priority for their team to fix this!” UPDATE: The issue is fixed!!! for 95% 🙂

In the meantime, please vote to get some attention to this issue!

AutoPilot Intune and the Local Account · Community (microsoft.com)