In this blog, I will examine the new Entra local administrator settings, which prevent users from becoming local administrators on their devices during the Entra ID Join.
I will focus on how these two new Entra ID settings could interfere with the user account type settings you configured in your Autopilot profile.
1. Introduction
Quite unexpectedly, two new Entra Local administrator settings appeared in Entra. You can change these two new settings to configure the local administrator settings in Entra ID under: Devices –> All Devices –> Device Settings
With the first local administrator setting, we can now define if the global admin role will be added to the administrators’ group. If this role is added to the administrator’s group, everyone who holds that role in your organization will become a local admin on the device. Luckily with this setting, we can now block that from happening during the Entra Join.
With the second new local administrator setting that also arrived, we can now define who may become a local administrator on the device during a regular Microsoft Entra Join. Before we could configure this setting, the user who was performing the device registration would always become a local admin on the device by default. The only way until now to prevent this from happening was using Autopilot.
If we want to prevent this from happening, we could configure a similar setting in the Autopilot profile. In the Autopilot profile, we have the option to define if the user account that was enrolling the device would become a standard user or an administrator during the out-of-box experience.
With the new second setting showing up in Entra, we don’t need to use Autopilot anymore?(don’t take this literally… just use Autopilot!). This new local administrator setting is configured to ALL by default.
My advice? Configure it to “None”. Having the registered user become a local admin on your device is a bad idea.
It’s all cool, right? But what happens if we configure the user to be a standard user in the Autopilot profile and the setting to add the registering user to the local administrator group is still set to ALL?
Before you go any further, it could come in handy to first read my blog about how the device registration policy works during Autopilot and how Autopilot will prevent the user from becoming a local administrator
When a device enrolls via Windows Autopilot, the user should not become a local admin if the Autopilot profile sets the account type to “standard.” However, if the device doesn’t receive the correct Autopilot profile, it may undergo a regular Azure AD Join, making the user a local admin. During Autopilot enrollment, the Enrollment Status Page and device registration process determine the user’s role. The device registration response includes SIDs that dictate group memberships. The CloudAssignedOobeConfig, stored on disk and in the registry, helps define whether the user is a local admin. This configuration is checked during device boot. The getOobeSettingsOverrideAsync function fetches these settings to influence the Cloud Domain Join process. The DSREG.Dll file includes the ReturnClientSid attribute, which, if present, makes the user an admin. Blocking personal device enrollments in Microsoft Intune ensures only recognized Autopilot devices are enrolled correctly. If a user ends up as a local admin, the device likely wasn’t recognized as an Autopilot device.
2. DeviceRegistrationPolicy vs Autopilot Profile
Well, if you take a look at the picture below, I will show you two scenarios.
In the first scenario, I configured the Entra local administrator setting to NONE but I configured the account type in the Autopilot profile to: Administrator
In the second scenario, I am doing exactly the opposite. I configured the entra setting to add some selected users to the local administrator group (configuring it to all will lead to the same outcome)
3. Autopilot Device Preparation / APv2
Beware: The stuff I mentioned above impacts the existing version of Autopilot. If you are running Autopilot Deviec Preparation / APv2, things are a bit different. That same setting to define who becomes a local administrator on the device is now breaking Autopilot Device Preparation!
https://call4cloud.nl/2024/06/the-battle-of-the-local-administrator-and-autopilot-device-preparation
The bottom line of that blog above is that you must set that setting to “all” if you don’t want to break your Autopilot Device Preparation experience!
4. Conclusion
The conclusion? If you are using Autopilot (v1) and configuring the user account to standard you are good to go even when the Entra setting is still configured to ALL(or selected).
When you are using Autopilot Device Preparation (v2), you need to set that setting to: “All”
In addition to this policy, please make sure you are preventing the global admin role from being added to the administrator’s group by changing the corresponding setting to NO.
Why do you recommend this ?
“Besides this policy, please make sure you are preventing the global admin role from being added to the administrator’s group by changing the corresponding setting to NO.”
Having an user that is member of the global admin in your tenant to also become local admin on all of your devices isnt best practise
(tier domain for example)
https://ramesh-seshadri.medium.com/why-important-to-use-microsoft-tier-administrative-3536bee4ef94
in most cases the local technicians are different from the tenant. So giving permission to the global admins to enter as administrator of the machines is not a good idea.
Yep… thats why i am mentioning the fact that the enabling this option isnt the best idea out there 😉
Just a thought – If you are doing a manual Entra join (ie not with Autopilot), then in the given settings the user is made a local admin, if allowed to enroll the device?
Manually joining entra, would always add the user that was performing the join to the local admins… with this setting we can now prevent that from happening… which is cool and great
How do the setting effect a “setup for work or school” where I do not want local admin or Windows 365 where we do want local admin (for IT staff)
I have an Autopilot Profile setup and assigned to my dev devices group. User accounts are set as “Standard.” I’ve also gone into Entra and modified the Device Settings to disable Global Administrators from being added as local admins and have additionally set “Registering user is added as local admin” to “none.” However, my test user is still getting local admin privileges. Any ideas on what else to check that might be causing this issue? (Note: I also don’t have any roles assigned to the test user and I also create a Windows enrollment restriction policy to block personal devices). I don’t know what else to check…
Are we talking about autopilot or autopilot device preparation (apv1 or apv2) ?
APV1. I think I may be figuring it out. Maybe. I found this article on MS DOCS which was helpful: https://learn.microsoft.com/en-us/entra/identity/devices/assign-local-admin#how-it-works. After reading that article, I went into Device Settings in Entra and clicked “Manage Additional local administrators on all Microsoft Entra joined devices” and discovered that my dev user account was still listed as a local admin there (formally, my Autopilot profile for my dev account was set to create an Admin user, but I changed it to “Standard” to test things out). I delete my dev user from the Device Administrator portal, rebooted the machine, and am now being prompted by UAC to put in Administrator username and password when trying to complete elevated tasks. However, I noticed that there’s still a single SID listed in the Administrators group (besides the default local admin account, of course). Is this the Device Administrator SID most likely (I’ve disabled Global Admins, so it can’t be that)?
I’m wondering if because I formerly had my dev account Autopilot Profile setup as an Admin account, it was still holding that information in the Device Administrator management portal in Entra, and I needed to go there and manually delete the entry? Or would it have eventually updated itself to reflect the change I made to make my dev user account just a Standard user eventually?