You've got a Windows machine joined to Microsoft Entra ID (what used to be called Azure AD), and you need a particular cloud account to be a local administrator on that PC — to install software, run elevated tools, or just support the user. On a traditional domain you'd drop them into the Administrators group and move on. With Entra ID it's almost as simple, but the account name format trips people up, and the obvious PowerShell command often throws an error.

Here's the reliable way to do it, plus the three other methods depending on whether you're touching one machine or a whole fleet.

TL;DR: From an elevated Command Prompt, run net localgroup administrators "AzureAD\This email address is being protected from spambots. You need JavaScript enabled to view it." /add. The magic is the AzureAD\ prefix in front of the user's full UPN. For more than a handful of machines, do it centrally with an Intune Account protection policy or assign the Azure AD Joined Device Local Administrator role instead.

---

Before you start

• The device must be Entra joined (or Entra hybrid joined). Check with dsregcmd /status — look for AzureAdJoined : YES.
• You need to already be a local admin on the machine to add someone else.
• Have the target user's full UPN ready — the whole This email address is being protected from spambots. You need JavaScript enabled to view it., not just the short name.

---

Method 1: One machine, one command (the quick way)

Open Command Prompt as administrator and run:

net localgroup administrators "AzureAD\This email address is being protected from spambots. You need JavaScript enabled to view it." /add

That's it. The account is now a member of the local Administrators group. Two things make this work where people usually get stuck:

• The AzureAD\ prefix tells Windows to resolve the name against Entra ID rather than the local SAM database or an on-prem domain.
• The full UPN after the backslash — AzureAD\This email address is being protected from spambots. You need JavaScript enabled to view it., not AzureAD\jsmith.

Note: On current Windows builds the account does not need to have signed in first — Windows resolves it against Entra. On older builds you may need the user to sign in to the device once so the account is known locally.

---

Method 2: PowerShell (and the error you'll probably hit)

The natural PowerShell equivalent is:

Add-LocalGroupMember -Group "Administrators" -Member "AzureAD\This email address is being protected from spambots. You need JavaScript enabled to view it."

On many systems this works — but on some it fails with “A member could not be added to or removed from the local group because the member does not exist” or a principal-not-found error, because the cmdlet can't always resolve an Entra principal by name. Two dependable workarounds:

a) Fall back to net localgroup (Method 1) — it resolves Entra names more reliably than the cmdlet.

b) Add by SID instead of name. If you have the user's object ID, you can derive the SID, or grab it after they've signed in:

# List members including SIDs to find the account
Get-LocalGroupMember -Group "Administrators"

# Add by SID (resolves even when the name won't)
Add-LocalGroupMember -Group "Administrators" -Member "S-1-12-1-XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX"

---

Method 3: Assign it in the Entra admin center (role-based)

If you want an account to be a local admin on every Entra-joined device automatically — e.g. your IT staff — don't touch machines one at a time. Use the built-in directory role:

1. Go to the Microsoft Entra admin center → Roles and administrators.
2. Open Azure AD Joined Device Local Administrator (it may appear as “Device Administrators”).
3. Add assignments and select the user(s).

Members of that role — along with anyone holding Global Administrator — are made local administrators on all Entra-joined Windows devices in the tenant. Great for admins; deliberately blunt, so don't use it for one-off exceptions.

Heads up: role changes propagate to a device when it refreshes its Entra token — it isn't always instant. A sign-out/sign-in or a reboot forces the update.

---

Method 4: Do it at scale with Intune (the managed way)

For a fleet where different people need admin on different machines, the clean approach is Intune (Microsoft Endpoint Manager):

1. Devices → Configuration → Account protection, or Endpoint security → Account protection.
2. Create a Local user group membership policy.
3. Choose the Administrators group, action Add (Update), and add the Entra users or groups by UPN or object ID.
4. Assign the policy to the right device groups.

This is repeatable, auditable, and reversible — and it pairs naturally with Windows LAPS so the built-in local Administrator password is rotated and escrowed in Entra as a break-glass fallback.

---

Verify it worked

From an elevated prompt on the device:

net localgroup administrators

You should see AzureAD\This email address is being protected from spambots. You need JavaScript enabled to view it. in the member list. Or with PowerShell:

Get-LocalGroupMember -Group "Administrators"

To remove the account later, swap /add for /delete:

net localgroup administrators "AzureAD\This email address is being protected from spambots. You need JavaScript enabled to view it." /delete

---

Common gotchas

• “The specified account name is not a member” on removal usually means the name format differs from how it was added — check the exact string in net localgroup administrators and match it.
• Not elevated. The command must run in an administrator Command Prompt/PowerShell, or you'll get access denied.
• Wrong join type. The AzureAD\ prefix is for Entra-joined devices. On a hybrid-joined device that also sees an on-prem domain, an on-prem account uses DOMAIN\user instead.
• Short name instead of UPN. AzureAD\jsmith won't resolve — it needs the full AzureAD\This email address is being protected from spambots. You need JavaScript enabled to view it..
• Expecting role changes instantly. Methods 3 and 4 depend on the device syncing with Entra/Intune; reboot or re-sign-in to hurry it along.

---

The takeaway

For a single machine, one elevated command with the AzureAD\UPN format does the job in seconds. For anything more than that, resist the urge to walk to each desk — assign the Azure AD Joined Device Local Administrator role for staff who need admin everywhere, or push a targeted Account protection policy from Intune for everyone else. It's less work up front and far easier to audit and undo later.

If you're standing up Entra ID, Intune, or Windows LAPS and want local-admin rights done right from the start — least privilege, centrally managed, with a break-glass account — that's the kind of setup we do for clients every week. Reach out if you'd like a hand.

---

Command and portal names reflect current Windows and Microsoft Entra admin center builds; Microsoft occasionally relabels these (Azure AD → Entra ID, Endpoint Manager → Intune). Always confirm a change on a test device before rolling it out broadly.