Greetings one and all. For this post I’m going to review the various options available today for managing Azure AD Joined devices with admin rights.
This isn’t looking at it from the users perspective, I don’t believe there are any circumstances where a user requires admin access on a corporate device, I’m looking at this from an administrators perspective, whether that is Service Desk analysts on an Intune administrator.
There is no right or wrong answer for this one, you need to pick whichever works best for your environment, your user base and your security needs.
The options under consideration are:
- Azure AD Joined Device Administrators role (ideally with PIM)
- Cloud LAPS
- Lean LAPS
- Local Device Admins (via Security Blade)
- Custom OMA-URI policy
Azure AD Joined Device Administrators
This will be the preferred option from your security team as it’s the least risky and most auditable.
Within Azure AD Roles you have the Azure AD joined Device Local Administrator Role:
Anyone who has this role assigned gets local admin access on ALL AAD devices.
If you look on the device itself, the account is not enumerated which offers an extra layer of security and should prevent lateral movement if an account is compromised.
Ideally this would be best linked with Privileged Identity Management in AAD (as long as you are P2 licensed)
By linking the two together, you can give your admins the ability to have local admin on the machines, but on a just-in-time basis and only after requesting access (and if preferred, having it approved by someone). It is also fully audited so you can see who requested access, at what time and how long for. Once the time expires, they lose the admin rights.
If you are careful with the times allowed (don’t just allow up to 8 hours), you can be sure that the timescale where a machine has an elevated account is much narrower and therefore more secure.
The main downside of this is that it is cloud only, everything is authenticated online so if a machine loses internet connectivity for any reason, there is no way onto the device to resolve the issue.
Sometimes if using PIM, the role can take a few minutes to apply as well which may cause problems should the issue be critical (or an exec who just won’t wait!)
Even taking these into account, this is still my preferred approach, but read-on to look at the other options…
Cloud LAPS
I’m sure if you’re reading this, you are familiar with traditional on-prem LAPS, a must-have tool for domain joined machines, whether end user devices or servers. For the small effort of an AD schema change and deploying a lightweight MSI, you rapidly reduce your security risk when dealing with local admin accounts. The password rotates and the local admin can be renamed for additional peace of mind.
Sadly, however, this does not work with AAD joined machines as it requires connectivity to the domain controller at the device level, which of course, does not exist.
There is a community is a community built tool to bridge that gap. It uses a mixture of Azure resources and Proactive remediations to set a secure local admin password on the device which is then securely stored in an Azure key vault and can only be accessed via the Cloud Laps portal (also hosted within your Azure tenancy). Access to the portal is restricted via Azure AD.
There is also an excellent monitoring plugin available to go with the main implementation to give a full overview of how successfully it is running.
As the account is created directly on the device, you are not restricted to needing an internet connection for device access (but obviously you’ll need access somewhere to get the password)
It is worth noting that whilst Cloud LAPS is completely free, the Azure resources it uses will come with a cost, it’s not going to be a huge cost, but it is worth considering.
It also lacks the just-in-time access of PIM and obviously isn’t an official Microsoft solution, but it is an excellent tool and could be used alongside the Azure Role as a type of break-glass account if needed, there is no reason why you can’t have multiple options available.
Lean LAPS
Similar to Cloud LAPS, but without the Azure infrastructure behind it is Lean LAPS.
Also using Proactive Remediations, this creates an admin account on the local device which can then be viewed simply by checking the Proactive Remediations output within the Intune portal.
There is also a GUI available, similar to the LAPS GUI in the on-prem world to quickly view the password for a device.
It is simple, but effective and quicker to implement than Cloud LAPS. It doesn’t have quite the same level of security as it bypasses the key vault entirely and of course you need to watch your Intune permissions as anyone with the right level of access could quickly view the passwords without you knowing.
This is well worth considering if you are looking for a solution which is quick to deploy and works out of the box with very little configuration.
Local Device Admins
A reasonably new addition to Intune is the Local User Group Membership.
This is found within the Endpoint Security Blade under Account Protection
This is similar to the user management directly on Windows machines and lets you add users or groups directly to the machine user groups:
As it is a Security Policy, you can have multiple policies for different devices so you can target which devices receive the policy so if you have a group of machines with their own IT support, you can set them as admin on their own machines only without worrying about them having access to the wider estate.
As with the AAD Joined admins, this does require an internet connection to enumerate the account.
This is a useful one to consider if you do need a small subset of devices to have a particular admin account on it without giving someone the keys to the kingdom (your IT staff for example may require admin on their machines, but not on any others)
You can also use this to populate other account types rather than just administrators.
OMA-URI Policy
The old-fashioned way before the above was introduced was a custom OMA-URI policy to set the local admins.
It’s a bit clunky for my liking and with the addition of the above, probably isn’t worth the effort, but if you’d rather use this option, I’ll refer you to this excellent post on configuring it from Ru Campbell:
As I said at the start, there is no right or wrong answer for this one, pick which works best for you, or even combine more than one to get the outcome you need (just don’t give the users admin access!)
