How to Manage Local Administrators and Groups with Intune

When we think about administrative rights on Intune-enrolled Windows 10 devices, we need to consider two possible device states for that device: Azure AD joined (AADJ), or Hybrid Azure AD joined (HAADJ).  This is due to the different administrative roles available at the directory level.

For Azure AD joined devices, at the time of performing the join, the security principals of global administrator and Azure AD joined device local administrator (previously named device administrator) are added to the local Administrators group.  The user performing the join is also added as a local administrator in most cases, though Autopilot does allow you to prevent this.  In the screenshot below, you can see the local Administrators group on an Azure AD joined device.  Note the two SIDs prefixed S-1-12-1, which are the global administrator and Azure AD joined device local administrators, and the user prefixed AzureAD\, which is the user who performed a manual Azure AD join. When you see that S-1-12-1 beginning the SID, it denotes an Azure AD object.

Now, consider a few things:

• We want to minimize the number of and use of global administrators to reduce our attack surface. What if a global administrator logs into a compromised device?  Yikes!
• The Azure AD joined device local administrator user role applies to all devices and we cannot limit it to a subset of devices.  This is a good role for IT service desk staff, but not if you have different service desks for different parts of your enterprise.  Therefore, if you want a user to be a local administrator on only one or a group of devices – but not others – this is not a suitable role.
• You should still consider the problem of compromised devices for the Azure AD joined device local administrator, as it could lead to lateral movement across your AADJ estate.  Privileged Identity Management (PIM) can be used to provide just-in-time (JIT) rights to the Azure AD joined device local administrator role, which might help, but it can take up to four hours for that role to be active or inactive on the devices due to the primary refresh token (PRT) renewal interval.
• The roles are added as local administrators at the time of join and only then.  If removed on the endpoint, they are not reinstated by any automatic process.
• As noted at the start of the article, not all your devices may be AADJ.  In non-Azure AD joined scenarios, such as Hybrid Azure AD joined devices, the above roles are not automatically administrators.

Intune can be used for endpoint management on both Azure AD joined and on-premises domain-joined devices, as described in this article.  Therefore, we can use it in either of the device states to manage local administrators – or membership of any other group.  In this article, we’ll utilise a new Policy CSP introduced in Windows 10 version 20H2: LocalUsersAndGroups.

LocalUsersAndGroups supersedes another Policy CSP, RestrictedGroups, as the recommended way of configuring local groups. This new approach supports “selective add or remove”, whereas the legacy approach was a full replace action.

Control of LocalUsersAndGroups is managed by XML. We’ll work with an example that manages the local administrators, and in that example, below, you can see there are four sections of the XML to configure.

<GroupConfiguration> 
<accessgroup desc = "Administrators"> 
<group action = "U"/> 
<add member = "AzureAD\gradya@petri.com"/> 
<add member = "S-1-12-1-xxx"/>
<remove member = "AzureAD\alexw@petri.com"/> 
</accessgroup> 
</GroupConfiguration>

• accessgroup desc names the local group, or you can use the SID.
• group action either updates (“U”) or restricts (“R).
  • When you update, you add or take out members individually, leaving unspecified members ignored.
  • When you restrict, you’re replacing the membership which what you specify.
• add member and remove member names the user(s) you’ll be adding and/or removing.
  • To control more than one user, just use multiple lines.
  • If controlling Azure AD groups, you need to use the SID.
    • In AAD, the SID is the securtyIdentifier attribute exposed only through the Graph API.
  • If controlling Azure AD users, you must prefix their address with AzureAD\.

To apply the XML to a device, use a custom OMA-URI configuration profile, specifying the XML as a string value.  The specific OMA-URI you need to specify is ./Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure.

 

Looking at the Administrators membership of the same device seen earlier, the LocalUsersAndGroups policy has been applied after an Intune policy sync.  What’s interesting in this case is that the user was specified by their Azure AD object (AzureAD\gradya@petri.com), but as the user is synced using Azure AD Connect, we see the source domain; even on an Azure AD joined device.

 

How does this same XML setting now look on a hybrid Azure AD joined device, bearing in mind we listed SIDs and objects prefixed “AzureAD\”?

 

You’ll notice that the SID is added, but the named Azure AD users are not, even though they are synced using Azure AD Connect.  To do this for hybrid devices, we should instead use a policy that looks like this, referencing the local domain:

<GroupConfiguration> 
<accessgroup desc = "Administrators"> 
<group action = "U"/> 
<add member = "CONTOSO\gradya"/> 
</accessgroup> 
</GroupConfiguration>

LocalUsersAndGroups makes it reasonably straight forward to add and remove named users and groups from any local group.  The Administrators group is the most obvious one IT teams will want to control, but any group can be managed using these XML settings.  You can use it to comply with some common best practice recommendations, though for more advanced control of local administrative rights, consider options such as the Microsoft LAPS (Local Administrator Password Solution).