Manage Windows 10 Local Admin accounts with Intune

90% of the exploited vulnerabilities in Windows 10 could have been averted if the end-users were using standard accounts instead of using accounts that had local admin rights.

Anyone working in the field of Digital Workplace or Modern Management, whatever you refer to it as, would agree on the importance of denying local admin privileges to the end-users.

The above is sourced from the Microsoft Vulnerabilities Report 2021.

However, revoking local admin rights from end-user is easier said than done. But is it really?

Let us have a quick look at the different ways via which we can manage local admin accounts on modern managed Windows 10 endpoints using Intune.

Different ways to manage Windows 10 Local Admin accounts with Intune

When discussing the local administrator account on MEM/Intune managed Windows 10 endpoints, we need to consider the two join states that the device can be in.

• Azure AD Joined, and
• Hybrid Azure AD Joined

Irrespective of the join state, the user account performing the join is added to the local Administrators group on the endpoint. This is by design.

The above is true for Hybrid Join via Windows Autopilot unless you have configured the Autopilot profile to provision standard accounts.

From a security perspective, you might be frowning at the thought of providing local administrator rights to the end-users.

How can you stop your end-users from gaining local admin rights on their workstations?

As an Intune admin, you can prevent end-users from getting local admin privileges by using the Windows Autopilot device provisioning that allows you to provision the end-user account on the endpoint as a standard account.

Note that controlling local admin rights via Autopilot works for new device provisioning only.

What about existing non-autopilot provisioned Azure AD /Hybrid Azure AD joined devices?

Those devices will have the user account which performed the join added to the Local Administrators group on the endpoint. However, you can use a Powershell script deployment from Intune to remove the end-user account from the Local Administrators group on the endpoints.

Use Net localgroup administrators “AzureAD\UserUPN” /add instead of Add-LocalGroupMember -Group “Administrators” -Member “AzureAD\UserUPN” as the latter has issues when run on remote endpoints.

Is the job done with the removal of local admin rights from the end-users?

Not really.

You need to consider how an IT Helpdesk engineer is supposed to get elevated privilege on the endpoints if required for any service request, troubleshooting or break-fix scenario.

So let’s get to the main purpose of this blog post.

Method #1 – Allow local admin rights on Win 10 endpoints via Azure AD roles

For Azure AD joined devices, by design, the security principals of the Global administrator and Azure AD joined device local administrator (previously named Device administrator) gets added to the local Administrators group on the endpoint.

Thus, anyone having either the Global admin role or the Azure AD joined device local admin role can sign in on the endpoint and get local admin rights.

But for the obvious fact that the Global admin role being the most privileged role available, it should not be used for this purpose.

This leaves us with the Azure AD joined device local admin role that we can use to get our IT helpdesk team local admin rights on the managed endpoints.

As you can see from the above snap, you can assign the role directly to individual members or to a group.

The accounts assigned with the Global administrator/Azure AD joined device administrator role will get local admin rights on all the managed Windows 10 endpoints in the environment.

Method #2 – Configure additional local admin via Device settings in Azure

What we just did above can also be configured in the below way.

In the AAD portal,

• Navigate to Devices
• Select Device settings
• Click on Manage Additional local administrators on all Azure AD joined devices link.

• Click on Add assignments
• Choose required User(s) or Group(s) to add.

This functionality is a Premium functionality and only available in Azure AD tenants with at least one Azure AD Premium P1 and/or Azure AD Premium P2 license.

Both methods as above being a tenant-wide setting, you won’t be able to scope this at device level.

What if you have a requirement to manage local admin accounts at the device level?

This brings us to the next method, which allows us to have specific account(s) or group(s) to be set as member of the Local Administrators group on the endpoints.

You can configure this via Intune as custom OMA-URI config policy and thus get control over the deployment. This allows you the granularity to configure distinct administrators for different devices.

Method #3 – Configure local admin via Intune using custom OMA-URI policy

Depending on the version of Windows 10, you can make use of the two different Configuration Service Provider for this purpose.

Use Restricted Groups CSP from Windows 10 1803 till Windows 10 2004

You can create a custom OMA-URI profile in Intune using the below details

<groupmembership>
<accessgroup desc = "Administrators">
<member name = "Administrator"/>
<member name = "<SID of user account to add> "/>
</accessgroup>
</groupmembership>

When a Restricted Groups policy is enforced, any current member of a restricted group that is not on the Members list is removed, except for the built-in administrator in the built-in Administrators group. Any user on the Members list who is not currently a member of the restricted group is added. An empty Members list means that the restricted group has no members. The membership configuration is based on SIDS, therefore renaming these built-in groups does not affect retention of this special membership. Check MS documentation.

Note that RestrictedGroups/ConfigureGroupMembership policy does not have a MemberOf functionality.

Use LocalUsersandGroups CSP starting Windows 10 20H2

You can create a custom OMA-URI profile in Intune using the below details

<GroupConfiguration>
<accessgroup desc = "Administrators">
<group action = "U"/> 
<add member = "AzureAD\UserUPN"/>
<add member = "<SID of Azure AD group to add>"/>
</accessgroup>
</GroupConfiguration>

To add user accounts, you must use the following format – "AzureAD\UserUPN". To add Azure AD groups, you need to specify the Azure AD Group SID. Check the MS documentation.

Thinking about how you can get the SID value for a user/group in Azure? Check this blog post by MVP Oliver Kieselbach.

If you are configuring local admin accounts using Policy CSP – LocalUsersAndGroups, be sure to know the OS language on the endpoint.

The name defined within the <accessgroup> tag needs to be the exact name of the local group on the endpoint. This is because, in some languages, the name of the Administrator account is localized. Attempting to reference the “Administrator” account may therefore fail. Refer to this document.

Want to add a non-domain user as a local admin to a particular group of devices?

We can do that using the Accounts CSP to create a local Windows account,

And then elevate the account as a local admin on the endpoint using another OMA-URI as below.

We can also achieve the same via a PowerShell script deployment from Intune. However, I will not go into the details of this in here.

Till this, if you have followed, you have successfully configured specific user account(s) or group(s) to be added to the Local Administrators group on the managed endpoints.

But this brings me to the below question…

Is it a good practice to set local admin accounts on the modern managed Windows 10 endpoints?

Since the same account gets configured as the local admin account on multiple devices, if the account gets compromised, you actually invite yourself to the risk of a lateral movement attack.

To prevent this, a strict and aggressive password rotation policy must be adopted for those accounts.

In a hybrid scenario where you are configuring on-premise domain account(s) synced to the cloud as local admin accounts on the managed endpoints, this can be easily done via the implementation of LAPS.

However, for a cloud-only environment, Microsoft is yet to come up with a solution for this.

You can argue that Azure AD already has Privileged Identity Management (PIM), but it takes way too much time to be useable.

Most of the time when end-users reach out to the IT Helpdesk, the obvious expectation is to get immediate support!

There is a UserVoice item to add LAPS support to MEM Intune and as I am writing this post, it already has 3246 votes. If you think this adds value, please go ahead and upvote.

Don’t get much excited when you see LAPS being added to the Administrative Templates in Intune.

As I understand from the different sources and my testing, it is for hybrid scenarios where you have LAPS deployed already and instead of using GPO, you can use this Admx templates from Intune.

Thus, the wait for the full-blown cloud-native version of LAPS still continues...

For now, if you want a solution that provides similar functionality as LAPS in a cloud only environment, take a look at

• Serverless LAPS implementation by MVP Tim Hermie.
• LAPS implementation with Proactive Remediation by MVP Rudy Ooms.
• Lightweight LAPS solution for Intune by Jos Lisben

And recently, MVP Nickolaj Anderson announced that he is working on something exciting on this particular topic. You need to monitor http://msendpointmgr.com for the release of the solution to know more about it.

Further considerations (if any, there are many…)

There are a few other things as well that will need your consideration!

Consider your organization is spread across multiple regions and you need to plan a solution such that local IT support of each region has local admin rights to the workstations belonging to the specific region only. Meaning that local IT support of region A will not have local admin rights on workstations of region B and vice-versa.

How will you achieve the requirement?

Thinking of using PowerShell deployment from Intune again, something that contains commands like,

• net localgroup administrators /add “AzureAD\<UserUPN>” for cloud-only account, or
• net localgroup administrators /add “<Domain>\username” for synced account.

But this requires you have unique device groups created in Azure AD for the different regions.

For Azure AD Joined devices, you cannot easily create a dynamic group to contain devices based on region, due to the fact that AAD device object do not have the location property like an AAD User object.

You can still create assigned device groups in Azure, but this requires a lot of manual effort since you (or the team) need to manually verify each device’s location and then add it to the required group. Also, every time a new device gets provisioned, you need to repeat the above activity to maintain parity.

How about running it manually on an endpoint?

Neither a practical option nor is it possible as we have already revoked local admin privileges from the end-users and as such the endpoints do not have any local admin accounts that can be used to create an elevated PS session to run the above commands.

How about signing in with a Global Admin account and then running the PS commands?

Again, this is something that is neither practical, not really recommended, nor I have seen this being done!

Further, there may be scenarios where local admin privilege is required for an application or process to work properly. Also, some advanced users might require to have elevated privilege to complete specific task(s).

How would you adjust to the end-user requirement of needing elevated privilege for business justified reasons?

This requires a self-service model that allows end users to request for and obtain just-in-time self-elevate privilege, without compromising the security, by limiting the elevated session or process with auditing capabilities for such requests.

Though this is not natively possible via Intune, can be achieved with an investment in 3rd party Privileged Access Management solutions like AdminByRequest.

Check my blog posts on how effortlessly you can go adminless with AdminByRequest without compromising user experience.

1. Revoke Local Admin Rights with Admin By Request
2. Admin By Request version 7 Exploring What’s New?
3. Get to know Support Assist with Admin By Request

Also, as an alternative, you can check out the open-source solution MakeMeAdmin that allows standard user accounts to be elevated to administrator-level, on a temporary basis. However, deploying this to all users will definitely not be a good idea!

Wrap Up

So let’s end this with the same question that we started this blog post with…

Revoking local admin rights from end-user is easier said than done. But is it really?

I would be happy to hear your inputs. Do leave a comment.

For now, that’s all for today.