A best practice to reduce your attack surface on Windows 10/11 devices is to not have any local device administrators. You can achieve this using things like Autopilot, however if devices are added manually to Azure AD by a user then that user becomes a local device administrator by default. You can manually go in and remove them from the local administrators group on the device but Endpoint Manager allows you to do this with a policy.
Navigate to https://endpoint.microsoft.com and login as a tenant administrator. Select Endpoint security from the left menu, then Account protection. Select to Create Policy. Select the option for Windows 10 and later as the platform and then Local user group membership for the profile as shown above. The select Create at the bottom of create the policy.
After you have given the policy a name you should see the options displayed above allowing to select which local group you want to work with.
At the moment, these are the groups you can work with. Here we’ll select Administrators.
and these are actions. Here we’ll select Remove (Update).
All you then need to do is select the users or groups from your Azure AD you wish this actioned on. Beware here, if you want select users removed then you will need to add those users individually not via a group like All users for example. The policy, at least in my experience, doesn’t enumerate a group to include all the users inside that group. Thus, if you select the group All users say, only that exact group will be actioned, not all the users who maybe part of that group. In short, the actions only apply to the unique object ID of the items you select here, not items that maybe contained within them.
You then continue with the policy creation process and assign the policy. With this, you’ll generally want to apply it to devices but you can do users or specific groups if desired as with any Endpoint policy.
Of course, you should test the impact of removing things like local device administration before you implement it widely across your whole environment. You may also want to consider some form of ‘break glass’ account if need be. That too can be done via a policy if you need to.
Once you have completed and save the policy it will be applied to your environment.
To verify the policy has been applied to a device, run the Computer Management utility as shown above. Expand Local Uses and Groups on the left and select Groups below this. Then on the right select Administrators and ensure the desired users don’t appear here.
Endpoint security policies in Endpoint Manager make it easy to configure the main local groups on your Windows 10 devices to help you be more secure.
CIAOPS 
Its very helpful article.
LikeLike
Hello everyone,
I’ve set my policy to Remove the user who joined the device in Azure AD from the admin group so that they don’t have local admin permissions and in Intune I see the policy status as OK, even when I go to view the admin group in my devices, I no longer see the user I deleted with my policy, i.e. the user who enrolled the device should no longer have local admin permissions, is that correct? However, it still has the permissions and they are only changed when I log out or restart the device. Is this normal behavior? Will it only work after reboot or logout?
LikeLike
Once the policy is applied to the device it takes a reboot or logout event typically. It all depends as to how you have assigned that policy – by device or by user.
LikeLike
Hello, thank you very much for your answer. My policy is assigned to a user group, not devices, however it doesn’t take effect until I reboot or log out.
LikeLike
Once it is applied I assume it stays applied. Remember, policies are not applied immediately and can take quite a while to apply. Rebooting and logging out tend to make this happen quicker. Try forcing a refresh of the policy manually using the Settings | User Accounts | Access work or school | Info | Sync
LikeLike
I can’t get this to work. I assigned my policy from Intune and in a few minutes it already appeared as applied correctly, even when I checked the local administrators group on my device, I noticed that the policy applied correctly but when testing the user’s permissions, he is still an administrator on the device. I assigned the directive and tested it after two days and the user’s permissions do not change.
LikeLike
In the end you’ll need to troubleshoot back through policy to ensure applied to device and it is set correctly. It should work as I had no issues. Call MS if you need to but my guess is that it is a config issue you’ve overlooked.
LikeLike
Thank you very much for the help. One last question, do you recommend applying this policy to a group of users or devices?
LikeLike
Generally devices as users don’t shared machines. If they do, users.
LikeLike
Guessing there’s been no update to add “All Users” to the remove group as you mentioned it doesn’t enumerate the members. What’s your thoughts on this for new staff members, other than selecting them manually each time if they don’t have Autopilot and are used to joining devices themselves?
LikeLike
Use an Azure AD group to accomplish All Users if you need. That is however, generally a dangerous approach I would suggest. Best practice is you should not have or need a local admin. All except for default should be removed and default should use LAPS to rotate passwords. If the devices are company owned I see no issues with that. If they user owned devices, then u need to decide on the level of security that you are happy with. Again, all devices should joined to Azure AD and follow full best practices security. Any less you need to understand and accept the risk. That is a choice only the business can make. Me, I am always going to recommend as secure as possible no matter what as the damage is far greater than any minor inconvenience I suggest.
LikeLike
Hi Robert, yep that’s excellent advice and 100% agree with you regarding security vs inconvenience.
Have managed to implement LAPS with the Rotating Password, even renamed he default Admin user to something less obvious. Though for the AAD joined machines when the UAC window pops up it I enter the Admin Username & Password and it doesn’t work, wants an Email Address instead. I added a user to the Manage Device Local Administrators in AAD and that works, though would love to get it going with LAPS.. I’ve had a fiddle not sure what I’m doing wrong
LikeLike
Using a GA on a local device will give you admin access and have no local device admin except the default which can’t be removed. You may also want to look at the new Privileges Escalation option policies now in preview in Intune.
LikeLike
Alright, thank you will take a look at the Privileges Escalation in InTune.
Just for my own knowledge clarification, would it be better to add an Unlicensed Standard User to the Manage Local Administrators section of AAD as opposed to using a GA? The user becomes part of the Join to AAD group (from memory) and doesn’t have near as much access as a GA. Just trying to understand, and get a different perspective in case I’m missing something entirely.
It really would be nice if LAPS would work with the local admin that’s on the PC, though can’t get past that email username hurdle. However it may be intended for a different use (ie.. Hybrid potentially), haven’t read enough literature on it.
LikeLike
I suggest an unlicensed admin is not best practice. In my books the managing user should have M365 Bp as a minimum and E5 as preferred. There is no need with Azure AD joined and Intune for any local device admin at all (except for the default which cannot be deleted).
LikeLike
I think it’s probably my explanation that isn’t the best.. so maybe a scenario may help. Agreed Default GA should be BP or E5 preferably to unlock advanced features etc.. However in the below case wouldn’t want to give out GA, nor receive a few dozen calls from end-users to enter in GA creds.
XYZ Removals has a Legacy Line-Of-Business App (Removal Buster) that requires users to have Admin (elevated) access to run updates pushed out once every 4-6 weeks. When the updates run, they fail as all users are Standard Users (not Administrators) on their devices for obvious reasons. Have tried to use LAPS for this, and while policies apply nicely, it doesn’t work (requires the email of a user) Yep GA works, though the Operations Manager doesn’t want to flood the helpdesk each month, and wants to be able to do it in his own time after hours so wants to be able to have an Admin account or easy way to manage this. The only way has been able to get it to meet the above is to a secondary Unlicensed Standard User with MFA in 365 Admin Centre, then Add that User (joe.admin@xyzremovals.com.au) to Azure AD in the Manage Local Administrators on Devices section.
I just thought that something like LAPS would be able to handle this, though as you’ve said InTune Suite is probably a better fit depending on cost.
LikeLike
LAPS is for managing local admin passwords ONLY! It is not for managing permissions or access. LAPS is not designed for managing user elevations. You need to use the new Privilege Elevation capability in Intune. That service is designed for what you want. In essences LAPS only rotates local device admin passwords is all.
LikeLike