Five Approaches For Local Admin Access On The Azure AD Joined PC

Local admin access on the Azure AD Joined Windows PCs can be a major security risk for organizations. This type of access allows users to install any software they want, change system settings, and potentially introduce malware or other malicious programs onto the network. During normal operation, only standard user accounts should be used on the device. This blog post will cover 5 different approaches for secure local admin access on Azure AD joined PCs, including the use of hardware tokens.

Table Of Contents

The Challenge

Overall, it is important to have a balance between ease of use and security. Limiting local admin access can reduce the risk of security breaches. At the same time, this can be challenging for some environments. That’s why we need an approach for giving users local admin access to their devices for a limited amount of time. Just in time rights in practical implementation.

Approach 1: Standard Azure AD Roles

Each Windows computer has a local Administrators group where the members are given extensive rights on the local computer. When a device is joined to Azure Active Directory, this group is updated with the following Azure Active Director security principles:

• The Azure AD Global Administrator role
• The Azure AD Joined Device Administrator role
• The user performing the Azure AD join (as long as this is not limited by the Autopilot process)

This can be seen in the following image captured on an AAD-joined device in one of my test environments:

As seen in the image above, there are two SIDs listed in the Administrators group in addition to the local Administrator account. We can’t find these identities directly in AAD. To verify the identity behind these SIDs, we need to convert them to ObjectIDs. Oliver Kieselbach has described a routine for this in his blog. By running this script, we get the ObjectIDs hiding behind the SIDs. This should target the aforementioned roles (Azure AD Global Administrator, Azure AD Joined Device Administrator).

This current demo device was joined with an AutoPilot deployment profile where the user joining the device to AAD was added as a standard user account type.

That explains why the user was not represented in the local Administrators group.

Global Administrator role

Out of the wrapping, we see that users with Global Administrator (GA) rights can sign in to an AAD-joined Windows computer and gain local Administrator rights on the device. However, this will not be a good practice! The global admin account is the most powerful in the tenant. Signing in to an end-user computer with global admin privileges can expose the account to several security risks. If the global admin account is compromised at the endpoint, an attacker can gain full control of the tenant, potentially causing significant damage and loss of data.

Protecting the global admin account is essential to maintaining the security and integrity of the system. Therefore global admins should be blocked from signing in on end-user devices. This is well-known knowledge from the Microsoft Administrative Tier model. There are several ways of achieving this. If you are interested, take a look at Assign Deny Local Log On user right to an (Azure) AD group by using Microsoft Intune by Peter Klapwijk and adopt it for your needs.

Azure AD Joined Device Administrator role

The Device Administrator role can be assigned to groups or users in AAD from the Azure Portal by navigating to Devices – Device Settings – Manage Additional local administrators on all Azure AD joined devices and adding users and/or groups.

This will however assign the privilege to all Azure AD joined devices. It is not possible to scope the device administrator role to a specific set of devices. It is generally considered a security best practice to use the least privileged access, and giving access to all devices in the tenant is breaking with this.

Approach 2: Local User Group Membership

There is a feature in Intune to configure local user group membership settings for Windows devices. This can be granularly assigned to devices and groups and will thus be a better approach than the previously mentioned device administrator role.

This setting can be found in the Intune admin center under Endpoint Security – Account Protection. Select Create Policy and choose Windows 10 or later – Local user group membership.

The policy should be given an appropriately descriptive name and description.

In the next window, we can configure the rules to manage the local group.

The actions we can use is as follows:

• Add (Update) which adds members to the group in addition to the current members in the group.
• Remove (Update) which removes certain members from the group.
• Add (Replace) which replaces all members of the group. This action will take precedence if multiple rules are targeting the same group! This action will also target the challenge of manually adding local admin accounts as mentioned later in this article.

If you are dealing with AAD-joined devices only, you can select the user/group to assign as the picture above shows. If you have Hybrid joined devices, you have to select the manual way of selecting users/groups.

Separate user accounts for this purpose are preferable. You can add an extra layer of security if you assign the rights to privileged access groups (role-assignable AAD groups) with Azure AD Privileged Identity Management (PIM). This will give just-in-time privileges.

This policy can now be assigned to device groups targeting the selection of devices scoped for local administration by the configured user accounts.

After the devices syncs with Intune, we can confirm the new configuration in the local Administrators group.

This will be a good approach for help desk users and power users, but it will still conflict with the practice of using the least privileged access since one credential can have constant privileged access to several devices.

Approach 3: LAPS

Microsoft has for a while had the Local Administrator Password Solution (LAPS) available for Active Directory based environments. The tool allows organizations to automatically set and manage unique, complex passwords for the local administrator accounts on the Windows machines. These passwords are stored in Active Directory and can be managed and monitored centrally. LAPS passwords are also automatic rotated. It also helps to mitigate the risk of lateral movement by attackers who gain access to one machine and try to use the same admin password to access other machines.

For devices joined to Azure Active Directory (AAD), there are community-based solutions giving the same functionality of LAPS.

The CloudLAPS Community Edition from MSEndpointMgr is the one with the richest functionality. Apart from other community solutions similar to this solution, CloudLAPS provides access to retrieve the local administrator passwords through a web-based portal. Delegated access to the web portal is supported through the means of native Azure AD enterprise application management. Password retrieval through the web portal is automatically logged in a Log Analytics workspace for auditing purposes.

In November 2022 Microsoft released a preview of their own Windows LAPS solution for Azure Active Directory. This version currently has a limited set of supported operating systems and has not yet been released for GA.

Approach 4: Passwordless with Hardware token

All of the above solutions are dealing with adding user identities to the local Administrator group of the device. These user identities are typically secured by a password. Users gaining access to the current credentials will have privileged access to the device, thus the need for the LAPS solution.

During a customer project, I was challenged with certain devices that could be disconnected from the network for long periods. How can we secure local administrator access to these offline devices while at the same time limiting the scope of devices and time of access since LAPS will require the devices to be online?

This particular challenge was related to a sea vessel, and the scope could be defined to all (or a group of) managed devices on the ship. This can be managed by local user group membership as targeted in approach 2. This way the access can be assigned to a defined device admin account pr. vessel.

Since the vessel could be out of reach for the internet for long periods, I needed to find an alternative scope for LAPS. We must ensure that no one gets accidental admin access for long periods as a result of username and password becoming known.

This led me down the path of using a hardware-based token like the ones from Yubikey. This will represent a physical key that will allow for login without the use of a password – the passwordless approach! These will also work regardless of internet connection. A responsible person on board will control the use of the key.

Phishing resistant authentication –
sounds perfect for a fishing boat!

– Simon

Enable FIDO2 Security key method in the tenant

To use this technology, we first need to make sure FIDO2 security keys are enabled in the tenant.

There are more settings available in the Configure tab for FIDO2 security keys. I will not deal with these in this post.

Enable FIDO2 Security key usage on the endpoint

Secondly, we need to make sure security keys are allowed to use for sign-ins on the endpoint.

To target specific device groups to enable the credential provider, we can use the following device configuration profile.

The settings should now be synced out to the devices.

Onboard a FIDO2 key to a user

To pilot this setting I will use a Yubikey 5 series key.

I will now add a security key as a sign-in method for the user added as local admin in approach 2 earlier. The mentioned user account should sign in to mysignins.microsoft.com and add Security Key as a new sign-in method found in the Security Info section.

Now the user will be guided through the wizard for adding the security key.

Next the security key should be installed in the device to get it enrolled for the user.

The key is now added as a sign-in device for the account which have local admin access rights on the devices used on the vessel (as configured in chapter “Approach 2: Local User Group Membership”) .

It is recommend to add a backup key as well in case the primary key is lost or corrupted. Having spare keys is a best practice which ensures we still won’t be locked out of our important accounts

Use FIDO2 to sign in to a device

Now we should be ready to test the sign-in experience. Please note: If you haven’t used your security key to sign in to the device while online, you can’t use it to sign in or unlock it while the device is offline. For the case of the vessel, this means we should sign in to every managed device on board using the FIDO2 key while the devices are online.

I can’t use the security key for “Run As” authentication. I need to log in to the device using the security key. At the Windows logon page, I will select Other User – Sign-in options. This is where I will find the FIDO security key option.

Next, I will need to type the PIN for the FIDO security key and touch the key to show my presence before I will be logged in to the device.

Please note if you have a security key containing multiple Azure AD accounts, the last account added to the security key will be the one used for logging in to the device!

I can now test and verify that this way of signing in with a security key on the device is working even if the device is offline.

The user account used for local admin on the Vessel will now have a physical key for signing in and nobody needs to know the password (the user can even be initiated by a Temporary Access Pass to register the passwordless authentication method). We only need to make sure the account has been signed in with the FIDO2 security key once while online.

Approach 5: Endpoint Privilege Management

Microsoft has announced a new Microsoft Intune Endpoint Privilege Management solution in early 2023. With this tool, we will no longer need to make local admin privileges for users on their devices. Instead, the users can be dynamically elevated to admin privileges for specific tasks approved by the admin in the company policies.

The privilege management policies will define when elevation can be performed, if they need approval etc. This will allow users to complete tasks such as adding apps, printers, peripherals, etc without the need to contact 1st line helpdesk.

This will address the principle of least privilege, lover the TCO, and help improve the productivity while at the same time enhance the overall security posture.

Protect devices from non-approved Admin accounts

It is worth mentioning that users can enroll other accounts to the local Admin role on the device if they gain privileged access to the system from one of the above solutions.

The following command is an example of giving admin privileges to a user on a windows device:

net localgroup administrators azuread\<users email address> /add

This will be visible like this on the device.

This should be monitored in the tenant.

Monitor Local Admin Access On The Azure AD Joined Windows PC

We can monitor the usage of local admin accounts on our devices by running Kusto queries on the Log Analytics data. In the simplest form, this query will give insights into the usage of local admin accounts:

DeviceLogonEvents
| where IsLocalAdmin == 1
| project TimeGenerated, DeviceName, AccountDomain, AccountName, LogonType, ActionType
| sort by TimeGenerated desc 

The data can be rendered as graphics and included in reports as well.

DeviceLogonEvents
| where IsLocalAdmin == 1
| summarize count() by DeviceName
| order by count_
| render barchart 

The data can be presented with a focus on the account name instead of the device.

DeviceLogonEvents
| where IsLocalAdmin == 1
| summarize count() by AccountName
| order by count_
| render piechart 

This is an example of Accountname mapped on devicename to find users logging on as local admin on several devices.

DeviceLogonEvents
| where IsLocalAdmin == 1
| summarize count() by AccountName, DeviceName
| order by count_
| render barchart  

These Kusto queries (KQL) can easily be adapted for hunting your specific environment.

Related Documentation

• How to manage local administrators on Azure AD joined devices – Microsoft Entra
• Manage account protection settings with endpoint security policies in Microsoft Intune
• Get started with Windows LAPS and Azure Active Directory
• CloudLAPS Community Edition – MSEndpointMgr
• Reduce your overall TCO with a new Microsoft Intune plan
• Passwordless security key sign-in – Azure Active Directory – Microsoft Entra
• Passwordless security key sign-in Windows – Azure Active Directory – Microsoft Entra