Intune: Different ways of setting a Local Admin account, but is it a good idea?

Security has always been and will always be an important subject and with the increasing number of recent security attacks, I felt compelled to cover the topic of setting local admin accounts on endpoints.

Before the landscape of Modern workplace even came into picture, setting a local admin account (aka break glass account) has been a common practice. Now that more and more organizations are adopting Modern Workplace framework, this requirement has just evolved. I must point out that even though setting a local admin account is extremely useful and the fact that it allows administrators to perform elevated admin tasks, from a security standpoint it is not such a good idea. But more on that later. Let's see what are the different ways to set the local admin account using Intune.

In case of a Domain Account -

When you connect a Windows device with Azure AD using Azure AD join, Azure AD adds the following security principals to the local administrators group on the device:

- The Azure AD global administrator role
- The Azure AD device administrator role
- The user performing the Azure AD join

However, if you want to add any other domain account outside the ones mentioned above, then you can do so using following methods.

Additional Local Administrators

In the Azure portal, you can manage the device administrator role on the Devices page. To open the Devices page:

1. Sign in to your Azure portal as a global administrator.
2. Search for and select Azure Active Directory.
3. In the Manage section, click Devices.
4. On the Devices page, click Device settings.

To modify the device administrator role, configure Additional local administrators on Azure AD joined devices.

Please note that this feature requires Azure AD Premium Tenant. Also, local administrators in here will get added to all the devices that get joined to Azure AD. There is no way to scope this at a device level.

Which brings us to the next couple of methods that leverage different CSPs.

Restricted Groups CSP starting Windows 10 2004

When a Restricted Groups policy is enforced, any current member of a restricted group that is not on the Members list is removed, except for the built-in administrator in the built-in Administrators group. Any user on the Members list who is not currently a member of the restricted group is added. An empty Members list means that the restricted group has no members. Therefore, it is important to add the default accounts in the custom configuration. I have highlighted them below. 

1. Navigate to the Microsoft Endpoint Manager admin center portal. 
2. Head over to Devices > Windows > Configuration profiles.
3. Click Create profile to open the Create a profile blade and select Platform as Windows 10 and later.
4. Select templates and chose Custom. Fill in the name and other necessary details and click on settings.
5. Here we are going to be using the following values -

Name - Local Admin

Description - Set Local Admin

OMA-URI - ./Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership

Data Type - String

Value - 

<groupmembership>
<accessgroup desc = "Administrators">
<member name = "Administrator" />
<member name = "S-1-12-1-1163434852-1197172539-44796078-500235900" />
<member name = "S-1-12-1-3146799803-1163991935-2384276401-1043884363" />
                <member name = "AzureAD\LocalAdmin1@sampledomain.com" />
                 <member name = "AzureAD\LocalAdmin2@sampledomain.com" />
</accessgroup>
</groupmembership>

6. We are only going to run this on devices running Windows 10 2004 so use the following applicability rule.

Rule - Assign profile if

Property - OS version

Value - 10.0.19041.0 to 10.0.19041.985

7. Deploy to a user\device based group.

LocalUsersandGroups CSP starting Windows 10 20H2

Starting from Windows 10, version 20H2, it is recommended to use the LocalUsersandGroups policy as RestrictedGroups policy replaces all of the existing users & groups with the new members and it does not allow selective add or remove.

Please note that The LocalUsersAndGroups policy setting and the RestrictedGroups policy setting should not be used together, as the behavior will be unpredictable. Both policy settings will be applied in no particular order.

The different elements used are -

<accessgroup desc> – This element specifies the name or SID of the local group that should be configured.

<group action> – This element specifies the action that should be taken on the on the local group that should be configured. Those actions can be update (U) or restrict (R) and can be used to achieve the following:

U – This action can be used to add or remove members of the local group that should be configured.
R – This action can be used to replace current members of the local group that should be configured. 

<add member> – This element specifies the name or SID of the member that should be added to the local group.

<remove member> – This element specifies the name or SID of the member that should be removed from the local group. This element is not processed when the restrict action is used.

For adding or removing Azure AD groups using this policy, you must use the group's SID. Azure AD group SIDs can be obtained using Graph API for Groups. The SID is present in the securityIdentifier attribute.

1. Navigate to the Microsoft Endpoint Manager admin center portal. 
2. Head over to Devices > Windows > Configuration profiles.
3. Click Create profile to open the Create a profile blade and select Platform as Windows 10 and later.
4. Select templates and chose Custom. Fill in the name and other necessary details and click on settings.
5. Here we are going to be using the following values -

Name - Local Admin

Description - Set Local Admin

OMA-URI - ./Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

Data Type - String

Value - 

<GroupConfiguration>
    <accessgroup desc = "Administrators">
        <group action = "U"/>
            <add member = "AzureAD\LocalAdmin1@sampledomain.com"/>
            <add member = "AzureAD\LocalAdmin2@sampledomain.com"/>
    </accessgroup>
</GroupConfiguration>

6. We are only going to run this on devices running Windows 10 20H2 so use the following applicability rule.

Rule - Assign profile if

Property - OS version

Value - 10.0.19042.0 to 10.0.19042.985

7. Deploy to a user\device based group.

Note from the field: I encountered an issue where the UPN of the accounts were not getting mapped to fetch the relevant SID. If this happens then you will see an event id 1202 in eventvwr stating - "No mapping between account names and security IDs". Even though I found out later that the issue was related to the fact that the accounts were disabled in AD, you do have the option to use the SID values instead. Why this works you ask? This is because when specifying a SID in the <add member> or <remove member>, member SIDs are added without attempting to resolve them.

In case you do decide to use SID values, then you can head over to the post by Oliver Kieselbach who has covered the process of converting the user object id to SID perfectly and also visa-versa. I used his script and credits to him for sharing it with the community.

In case of a non-domain account -

Accounts CSP to create a local Windows account

1. Navigate to the Microsoft Endpoint Manager admin center portal. 
2. Head over to Devices > Windows > Configuration profiles.
3. Click Create profile to open the Create a profile blade and select Platform as Windows 10 and later.
4. Select templates and chose Custom. Fill in the name and other necessary details and click on settings.
5. We are going to be creating 2 OMA-URI settings here so refer to values below -

OMA-URI 1

Name - Local Admin

Description - Set Local Admin

OMA-URI - ./Device/Vendor/MSFT/Accounts/Users/rahuljindallocaladmin/LocalUserGroup

Data Type - Interger

Value - 2

OMA-URI 2

Name - Local Admin Password

Description - Set Local Admin Password

OMA-URI - ./Device/Vendor/MSFT/Accounts/Users/rahuljindallocaladmin/Password

Data Type - String

Value - P@55w0rd

6. Deploy to a user\device based group.

Powershell Script to add Local Windows account

Note: Configuring Password for local admin account using PS is not a good security practice as the credentials will be visible in plain text.

Here is the PS script that you can use to create a local Windows account.

$LocalUser = "rahuljindaladmin"
$Password = ConvertTo-SecureString "P@55w0rd" -AsPlainText -Force
Function Create_LocalWindowsAccount
{
    New-LocalUser $LocalUser -Password $Password -FullName "Local Admin" -Description "Local Administrator account."
    Add-LocalGroupMember -Group "Administrators" -Member $LocalUser
    Set-LocalUser -Name $LocalUser -PasswordNeverExpires:$true
}
{
Create_LocalWindowsAccount
}

1. Sign-in to the Microsoft Endpoint Manager admin center portal. 
2. Browse to Devices – Windows – PowerShell Scripts
3. Click on Add
4. Give a Name
5. Select the script
6. Set Run this script using the logged on credentials as No
7. Set Enforce script signature check to No
8. Set Run script in 64 bit PowerShell Host as Yes
9. Deploy to the user\device based group.

Now coming to the point as to why setting a local account is not such a great idea; since the same account will get configured on multiple devices (depends on which method you use) and if the account gets compromised, then you risk your devices of being exposed to all kind of hacking scenarios. If there is a business need to set a local admin account, then a strict and aggressive password rotation policy should be adopted at the very least.