By default, on Windows 10 devices which are Azure AD joined, the user performing the join is added to the Local Administrator group. Besides the user and the local administrator (which is disabled by default), two other SIDs are added without any friendly name which explain who they are. So where are those SIDs coming from?

It is possible to make the user a normal user while enrolling the device, but then you have to create a Deployment Profile and use Windows Autopilot. See: Configure Autopilot profiles or use Bulk enrollment. See: Bulk enrollment for Windows devices

Note: This post reflects the status of Azure AD local administrative privileges as of February 11th 2020. Functionality may change, even right after this post has been published.

When searching through the documentation (How to manage the local administrators group on Azure AD joined devices) you will read that these 2 SIDs represent the Azure AD Global Administrator and the Device Administrator roles.

So basically this is really handy, you can add a user in the Azure AD role and therefore the user becomes a local administrator on the Azure AD joined devices. These a global settings, meaning that if you receive the device administrator role, you will be a local administrator on all Azure AD joined devices for your tenant.

When searching for the Device Administrator role under “Roles and Administrators” in the Azure AD portal you will notice that the Device Administrator role isn’t available.

Adding device administrators is done in a different way, you’ll need to go to “Devices -> Device Settings” where you will find the option “Additional local administrators on Azure AD joined devices”. When you add a member to this option, it will receive the Device Administrators role.

Note that being able to add local administrators on the Azure AD joined devices is a Azure AD premium feature.

The Device Administrator role is available within Azure AD Privileged Identity Management (PIM), so when using PIM you can assign the role from there as well and make users either permanent members or eligible.

Challenges

Based on what is possible out of the box, from a security perspective this poses some challenges. For example, do you really want to login to another device using “Global Administrator” rights, you never know what software is running on the system (keyloggers or any other tool which can harvest credentials). If your Global Administrator account is compromised this can be considered a major security issue. Same goes for permanent Device Administrators, if their account is compromised you can basically access every Azure AD joined machine using those credentials.

There are also some challenges with the Device Administrator group, mainly because when you add a user to this role (either via the Azure AD settings or by activating the role using PIM) the change is not effective immediately on the Windows 10 client. The reason for this has to do with the PRT, which stands for Primary Refresh Token.

From the documentation:

A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10, iOS, and Android devices. It is a JSON Web Token (JWT) specially issued to Microsoft first party token brokers to enable single sign-on (SSO) across the applications used on those devices. The CloudAP plugin renews the PRT every 4 hours during Windows sign in.

Basically this means that after a user is added to the Device admins group it can take up to 4 hours for this to be active, and vice versa (when user is removed from Device admins it stays local admin for up to 4 hours).

So what are the other options you have,

Make Me Admin

Make Me Admin is a simple, open-source application for Windows that allows standard user accounts to be elevated to administrator-level, on a temporary basis.

You could configure Make Me Admin in such a way that you either allow end-users to temporarily give them local administrator rights while you help remotely. Or start Make Me Admin with Runas for your own account and specify that account as eligible for elevation using one of the many settings (not tested)

Thanks Erik Loef for making me aware of this solution.

Serverless LAPS

This solution, created by John Seerden provides a way to maintain passwords for locally created accounts. You could for example create a local account, and have the password managed by Serverless LAPS. The main point here is not to create a local account, with a common password on all of your Azure AD Joined machines. If that account gets compromised then the attacker has access to all of your Azure AD machines. (the whole reason why Microsoft created the Local Administrator Password Solution in the first place). See: Create a local user account via Windows 10 MDM by Peter van der Woude

Use another management agents besides Intune.

There are some other Management Agents which provide solutions which can temporarily create local accounts with administrative credentials. Once the necessary work by the workplace administrator on the machine is done the management tooling removes the created account.

Script to manage the built-in administrators group, on an Azure AD Joined Windows 10 device, using an AAD Security Group created by Michael Mardahl

Michael Mardahl pointed me to a solution he build to manage the administrators group using an Azure AD Security Group and some PowerShell magic. Worthwhile to check this one out.

Oliver Kieselbach pointed me to two interesting solutions mentioned below

Intune Local Administrator Password Solution (iLAPS) by Alex Ø. T. Hansen

Another solution to manage the Local Administrator password in a similar way

LAPS for Azure AD and Hybrid Joined by Synergix

Synergix provides a free community edition called Secrets Vault, they also have an Enterprise paid edition available providing way more functionality.

Centero Carillon for Access Right Management.

Centero has a nice solution for local admin rights available. When a user needs admin rights he/she can simply request them giving a justification. This process even works if the user is not online. Central reporting is provided for admins to view the requests.

Conclusion

Microsoft still has a lot of work to do when it comes to visibility into who is local admin on Azure AD joined machines, also extending PIM to also include accounts on Azure AD joined clients would be a welcome addition. Users could then  temporarily request local administrator/power user rights and this would be effective immediately if approved.

If you have found other solutions to these challenges please reach out, I will include your solution in this blogpost with credits 🙂