Call4Cloud | MMP-C | Autopilot | Device Preparation

Local Administrator, and Autopilot Settings, and Entra Settings! Oh, my!

Patch My Pc | install & update thousands of apps

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

Entra Local Administrator Settings in which we define if the registering user is added as local administrator on the device and if the global administrator role is added as local administrator on the device

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.

autopilot profile to configure the user account type is configured to standard

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.

configuring the registering user is added as local administrator on the device during microsoft entra join to all

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

To summarize the blog above before we can continue:

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)

The local administrator settings in entra. Who wins autopilot or entra?

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!

configuring the registering user is added as local administrator on the device during microsoft entra join to all

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.

7 thoughts on “Local Administrator, and Autopilot Settings, and Entra Settings! Oh, my!

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

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

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

      1. Yep… thats why i am mentioning the fact that the enabling this option isnt the best idea out there 😉

  2. 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?

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

  3. 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)

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  12  =  15

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.