By default, when someone receives a new Windows endpoint, Windows adds the enrolling/registering user’s account to the local Administrator of the computer being set up. This is good for personal use endpoints but may not be good for corporate devices as users can do anything with the devices. In this article, we explain how to remove admin rights from devices, through two methods using both Autopilot and Intune.
Devices Provisioned with Autopilot
The first method is to use Autopilot to provision your machine. In the autopilot deployment profile, there is an option to control if the user should be assigned administrator or standard user rights during the out-of-box experience (OOBE). All you need is to make sure this option is set to standard, as shown in Figure 1, if you want users setting up the endpoint do not assign with local administrator rights.
One of the drawbacks to this approach is that it only works during Autopilot provisioning, which requires you to reset the laptop to get into Autopilot mode. Windows will have the SID representing the two Entra roles to the local Administrator group of all Windows endpoints during the join process:
- Microsoft Entra Joined Device Local Administrator
- Global Administrator
The assignment of the roles is the time the machine joins regardless of which method to use, and hence, even the Autopilot machine will have these two roles assigned to the local Administrators group of each Windows endpoint. These roles are here to provide an ability for cloud administrators to control which cloud users will have local administrator rights by using the Entra admin center to add users to the role, as shown in Figure 2 (with an orange box). This feature requires users to have an Entra P1 or P2 license.
The green box in Figure 2 highlights that the Entra admin center includes an option to control adding a Global Administrator role to the local administrator group and controls if users who registered the Windows endpoint will be assigned as a local administrator. However, at the time of writing, these two settings are in preview, and their behavior may change. These two settings only apply at the time the endpoint registers to Entra ID.
Yet this does not resolve the issue of who gets the permission at the endpoint level after the endpoint completes registration to Entra ID or control which users should not be part of the local Administrators. That’s where using Intune comes into play.
Controlling Local Administrator Rights with Intune
As mentioned in the previous section, the assignment of users to the local Administrators group happens during OOBE or at the time the endpoint is joined to Entra ID. This creates an issue as someone could change the membership with harmful intent. Hence, regardless of using Autopilot to provision Windows endpoints, we should consider deploying the following approaches to control the local administrator group. This is not just to change the membership, but more for performing regular audits and remediations in case someone assigns additional users to the local administrator group by accident.
There are two ways to control the membership of the local Administrators group with Intune. The approach mentioned works for any group in which you want to control the membership.
Control with Intune Configuration Profiles
Two options are available for controlling membership of the local Administrators group, which effectively controls who will get full permission on the managed Windows endpoint. The two options are using Restricted Group settings or an Endpoint Security Profile.
Intune Configuration Profile – RestrictedGroup CSP
RestrictedGroup CSP setting is similar to the Restricted Group setting that we often use when using GPO to manage endpoints. When the policy gets applied, it will replace the target group’s membership with the membership list defined in the policy. There are no interfaces to define the group membership and require us to define an XML file representing the group membership. We will have to define a Custom CSP configuration profile and apply it to the endpoints, as shown in Figure 3.
Example: Setting XML for the RestrictedGroup CSP.
OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership Data Type: String Content: <groupmembership> <accessgroup desc = "Administrators"> <member name = "admin"/> <member name = "AzureAD\admin@xxx.onmicrosoft.com"/> </accessgroup> </groupmembership>
The above setting will add a local account named admin to the Administrators group and also add Entra ID user admin@xxx.onmicrosoft.com as a member of the group. Make sure to add AzureAD\ as a prefix to all cloud user accounts, or you can choose to specify SID.
Microsoft mentioned in its documentation that we should use the LocalUsersandGroups CSP instead of the Restricted group CSP. Don’t worry, the policy still works, and I often use it when I help clients migrate on-premises GPO to the Intune configuration profile. But, if you start with a new policy, it is best to use the Account Protection policy.
Intune Configuration Profile – Account Protection Policy
It is also possible to configure the local group membership with the Account Protection policy. The setting is moved to the Endpoint Security section of the Intune Admin Center. Behind the scenes, it uses the LocalUsersAndGroups CSP mentioned above. The beauty of using this policy, instead of RestrictedGroup CSP is that it has a cleaner UI, as shown in Figure 4. It also can be used to define the specific action (Add/Remove/Replace) for each entry defined, whereas RestrictedGroup CSP is a replacement for the whole membership list. Use the policy that applies to your situation, even if Microsoft prefers us to use the LocalUsersAndGroups CSP setting instead of RestrictedGroups CSP.
The Account Protection Policy is capable of controlling other built-in groups, like the Remote Desktop Users group. We can then use the same policy to control who can use Remote Desktop to the assigned endpoints.
Things to Consider When Using Intune to Control Local Admin
Although it is nice to have multiple options for applying controls to the local Administrators group, there are some restrictions to consider:
- Do not assign both RestrictedGroups and LocalUsersAndGroups CSP to the same machine – Microsoft mentioned specifically this should not be done as it may create an unexpected result
- The two Intune policies are not “real-time” policies – this means the policy gets applied during the first application or configuration refresh. There may be a time delay for the policy to become effective. For example, the extra member will only get removed after the configuration refreshes.
- The two Intune policies do not allow the removal of the built-in administrator accounts from the Administrators group – You should consider implementing Microsoft LAPS, as mentioned in this article, and deploy a policy to rename the built-in administrator account name.
Conclusion
I would recommend mixing both the Autopilot Deployment Profile and the Intune configuration profile when controlling the local administrator group. This reduces the chance that the local Administrators group’s membership gets updated after the endpoint is provisioned. Also, these recommendations should always be configured when setting up a new tenant and periodically reviewed to ensure they are up-to-date.
