UPDATE on 27.06.23: Please, if you run into the scenario described in this article you should use Windows LAPS instead creating a user with a static password. Yes, if need be you can use Windows LAPS to manage that custom user (and I explain below how to create that and why I don’t think its a great idea). Removing the access to the local user and putting him in the user group is still relevant and required for this scenario (see below).
UPDATED on 27.10.22: As people pointed out, I didn’t mention how to create the additional, local admin account in the first place. I added a new section called “Creating an additional local admin account”. It’s probably not what you think it will be.
Fair warning: While this solution works it might not be the best to roll this out widely. Then again, it is a pretty niche thing. This whole blog entry in total comes down to a technical solution to an organizational issue. More on that later. You have been warned!
A small introduction into the issue
So, you’ve been riding that Autopilot train for a while – or might have finally started looking at it. Congratulations! Now, Microsoft, your last consultant or maybe your boss have told you: Cool, so we can now do BYOD? Bring Your Own Device? People seem to really dig it; Gen-Z loves it (granted they’re mostly used to tablets anyway). From the customers that I’ve seen so far for mobile devices its usually allowed, as long as the device supports MAM – Mobile Application Management. But Windows? WIP without enrollment is going away and if Microsoft is putting their efforts elsewhere so should you. After All, Windows just isn’t iOS or Android.
You could use Windows 365 (or AVD)! (Remember those Gen-Z?) You’d be able to provide your business-critical apps without caring about the users end device (exceptions apply). You could also manage personal devices as your own. However, there’s a reason BYOD didn’t and doesn’t work for a lot of companies. This starts with technical issues, goes to taxation and stops at the user experience. What about COPE for mobile devices, but for Windows? Well, this might work but it will require you to somehow get the device to the user. Unless – they buy a device locally! And this is where the problems start.
The issue: Using the OOBE will make the user admin
As you tell your users to just go buy a device and get their money back through the travel expenses report, you’re wondering what to do about the devices. You want them to go through Autopilot, but you’d need the hardware hash for that. Getting the users to enroll their devices properly is already going to be a challenge. So, what if you just let them go through the Out-Of-Box-Experience and let them join after the fact?
- Using a local user to set up the device will leave that permission with that local user when joined to Intune
- Additionally, the user that enrolled the device in Azure AD will be made local administrator. It will add that user and some additional default groups only once – that’s lucky for us.
Now, hopefully you’ve read the warning at the beginning of this post. You could make this issue disappear by letting the user enroll into AAD and with that Intune once and then force the device through Autopilot. Boom, fully managed device. User can sign in with his mail address. But you’re not here for that are you.
A semi-solution
Prerequisites are quite simple:
- Endpoint Analytics enrolled device
- Proactive Remediations (It could also work using Scripts, but I prefer a tighter control about these rights)
- This requires a Windows license for the user. Keep in mind that while you can run PRs on Windows Pro devices, the user still requires that license contractually.
- Interestingly Proactive Remediations list “AAD-joined” as requirement, which I found not to be true. Quite the surprise, however, I strongly suggest to AAD-Join the devices. Hey, guess what: Autopilot will do it for you!
What we’re actually going to do is two things. First, we need to establish a local administrator other than the current user or the build in Administrator account. Considering Microsoft has already announced some “Cloud LAPS” functionality I hope this won’t be required for too long though. Second, we need to make sure the current local user that was created during OOBE will still be a standard user on the device – we achieve that with using Proactive Remediations.
Creating an additional local admin account
As people pointed out, this chapter was missing from my explanation. Other people have already written blogs about this, so I won’t go into detail here. Using the Account CSP you create a local user, that you will then use with your Account Protection and Proactive Remediation script. That’s it. Don’t be offset by the fact that using a Custom CP for this will always result in a failure, but still correctly create the account on the device(!). However, using this method poses a security risk, as that would make an account on all devices with the same password. Don’t do that, please. There are multiple ways to achieve this, and it is also an optional step. You don’t have to create an additional account, unless the device is only AAD registered (because you cannot login with an AAD account to that and you’d be stuck with the standard user).
Otherwise, you can and should use the “Azure AD joined device local administrator” role in your AAD to achieve local administration rights on the targeted client. Don’t forget to adjust your Account Protection policy (as we set it to REPLACE) accordingly. And remember, that Microsoft’s new “Windows LAPS” solution is on the way and supports AAD, so you might only need to remove the user from the local admins.
Clean up the “Administrators” Group using Account Protection
As mentioned earlier, some groups and users are added to the local admin group. To keep control over the device you can add additional administrators in a lot of ways. Custom OMA URI, Scripts or manually, but I prefer the Account Protection for this use case.
You will want an Account Protection policy with a “user selection type” set to “Manual” that covers two users, both of which are local. Since we’re going to run this in “Replace” mode we are required to at least add the “Administrator” (see the notes on ‘R’-Mode). Removing the Administrator will result in a failure for this policy so don’t skip this step. Now add another Account – the name won’t really matter but note it down somewhere. We will need it later in the PR.
In the end it should look like this. Assign this policy to the device(s) and wait until you’re certain the account has been created and is in that group. I wrote the PR in a way that it can run without this being a hard requirement but be wary that if this policy doesn’t apply there won’t be a local administrator for you to log in to. Plus, we don’t leverage the built-in Administrator account, meaning that device would be in a bad configuration state until this policy has applied. The local Administrators group should now only contain your two entries.
Proactive Remediation
Now the tricky part is to get the user created by the OOBE into the Users group. By default, the user created will only be in Administrators. How would we know, which account name the user chose to set it in an Account Protection policy? We don’t, so to solve our issue, we’ll need these two scripts and Proactive Remediation. The detection will look for any users that aren’t added to any group. The remediation script will add said users to the “Users” group. Keep in mind that it will do this for any user found this way and might be a potential security issue. Please don’t forget to change your local Administrators name to the value you configured earlier so it will be filtered out from this query. You may want to adjust this script to add the user to additional groups.
Detection Script
#Detection.ps1
#This script will detect if there are users that do not belong to a group. The $LocalAdminName and local Administrator is excluded
$LocalAdminName = "ENTERYOURADMINNAMEHERE"
$Users = Get-CimInstance win32_useraccount
$UsersLocal = $Users | Where-Object{$_.status -eq "OK" -and $_.Name -ne $LocalAdminName} | Select-Object *
$LocalGroups = Get-CimInstance win32_groupuser
foreach($User in $UsersLocal){
if($User.name -notin $LocalGroups.PartComponent.name){
Write-Output "$($User.name) is not in any group!"
Exit 1
}
else{
continue
}
}
Write-Output "No users found"
Exit 0
Remediation Script
#Remediation.ps1
#The script will add all users without group to the "Users" group - other local users will be left as is. The SVAAdmin and local Administrator is excluded
$Users = Get-CimInstance win32_useraccount
$UsersLocal = $Users | Where-Object{$_.status -eq "OK" -and $_.Name -ne "SVAAdmin"} | Select-Object *
$LocalGroups = Get-CimInstance win32_groupuser
foreach($User in $UsersLocal){
if($User.name -notin $LocalGroups.PartComponent.name){
Write-Output "$($User.name) is not in any group!"
Add-LocalGroupMember -Group "Users" -Member $User.Name -Confirm:$false
}
}
Write-Output "Users have been added"
Exit 0
Summarization
The Account Protection policy will prepare the device in a way, that the Remediation Script can do its job. The Account Protection policy is applied pretty promptly the first time (a couple minutes) and the PR will be applied at whatever schedule is set. The Policy will take some time to re-apply if you change something, you should re-assign it to the device during testing. It may take a while until you can see the changes, especially if you’re trying this out for the first time. Try adjusting the script to your needs. I found it scary, that this works even though the device isn’t even fully (AAD-) joined. If you were a user, signing up with your own device and joining it to Intune to access some company apps I’m sure you wouldn’t expect to not be admin anymore. Here’s a before and after comparison.
That’s it for today – if you have any questions or suggestions on this please leave a Tweet or DM in LinkedIn (top right menu). You can also find me in the WinAdmins Community Discord.