The previous post in this Entra ID Security pathway covered two of the three ways a user can become a local administrator on an Entra-joined device: the Global Admin auto-elevation toggle, and the ‘Registering user as local admin’ setting. This post covers the third — the Entra Joined Device Local Administrator role (sometimes labelled Device Administrator in the UI), assigned via the Manage additional local administrators link in Device Settings.
This is the right tool for one specific job: giving your IT helpdesk team local admin rights across every Entra-joined device in the tenant, without having to make them Global Administrators. Use it carefully — the scope is tenant-wide and there’s no way to narrow it.
Where this fits — the three local-admin doors side by side
| Method | Who it makes admin | Scope | Where to configure |
|---|---|---|---|
| Global Admin as local admin (toggle) | Every Global Admin in the tenant | All Entra-joined devices, automatic | Device Settings > Local Admin Settings |
| Registering user as local admin | The specific user who joined this device | Only the device they joined | Device Settings > Local Admin Settings |
| Additional local admins (this post) | Specific users / groups you assign | ALL Entra-joined devices in the tenant | Entra Roles > Device Administrator |
The first two were covered previously. This post is row three.
What the Device Administrator role actually does
When a Windows device joins Entra ID, the join process embeds a special SID into the device’s local Administrators group — the SID for the Entra Joined Device Local Administrator role. From that moment on, anyone whose Entra account is a member of that role is treated as a local admin on that device, even though their individual SID isn’t listed.
So when you add Kibria (your helpdesk lead) to the role via the Additional Local Admins setting, Kibria immediately gains local admin rights on every Entra-joined device in the tenant — both devices already joined and devices joined later. The membership lookup happens at sign-in via the role-SID lineage, not via per-device propagation.
The hard limitation
This role is tenant-wide only. You cannot scope it to specific devices, a device group, an OU, or a region. Assign Kibria and Kibria is admin everywhere. If you need device-specific local admin (e.g. helpdesk-lead-A admins finance laptops, helpdesk-lead-B admins engineering laptops), this role is the wrong tool. Reach for an Intune Account Protection policy or Microsoft Entra LAPS instead.
Step 1 — navigate to Device Settings
- Open entra.microsoft.com as a Global Administrator.
- Identity > Devices > Overview > Device Settings (top horizontal menu).
- Scroll to the Local Administrator Settings section.
Step 2 — open Manage additional local administrators
Click the Manage additional local administrators on all Microsoft Entra joined devices link. This jumps you to the Device Administrator role assignment page. By default, the assignments list is empty — nobody is in this role unless you put them there.
Step 3 — add an assignment
- Click Add assignments at the top.
- Search for the user (e.g.
Kibria) or, better, a security group likeIT-Helpdesk-Device-Admins. - Tick the checkbox > click Add.
No Save button. The assignment commits the moment you click Add. Effective immediately on next sign-in.
Best practice: assign a group, not individuals
Create one security group (IT-Helpdesk-Device-Admins), assign the group, then manage device-admin access by group membership for the rest of the role’s life. New helpdesk hire? Add to group. Engineer leaves? Remove from group. You never come back to this page.
What the local Administrators group looks like end-to-end
After Settings 5 / 6 from the previous guide and this Setting 7, here’s the full picture for a fresh Entra-joined device:
| Account | Why they’re admin | Scope |
|---|---|---|
| Built-in Administrator | Always exists on Windows | Just this device |
| David (the joining user) | ‘Registering user as local admin’ = Selected, David is in the list | Only this device |
| Kibria (helpdesk) | Member of Device Administrator role via Additional Local Admins | Every Entra-joined device tenant-wide |
| Global Admins | Toggle was set to No | None (blocked) |
Inside Computer Management > Local Users and Groups > Administrators, the built-in account shows as a name, but Entra accounts show as raw SIDs. That’s normal — Windows can’t resolve cloud SIDs to friendly names without an extra lookup. Both still have admin rights.
Verify the assignment works — two tests
Test 1 — David (the device joiner)
- On a Windows 11 device: Settings > Accounts > Access work or school > Connect > Join this device to Microsoft Entra ID.
- Sign in as David, complete MFA, click Join, then Done.
- Restart, sign in as David, complete Windows Hello / PIN setup.
- Right-click Start > Computer Management > Local Users and Groups > Groups > Administrators. Confirm David’s SID and the Device Local Admin role SID are both listed.
- Settings > Accounts — David’s account type should read Administrator.
Test 2 — Kibria (the role-assigned admin)
- Sign out of David’s session on the same device.
- Click Other user on the lock screen.
- Sign in as Kibria using his Entra ID credentials.
- After login: Settings > Accounts — Kibria’s account type should read Administrator.
Quick CLI alternative: open Command Prompt and run net localgroup administrators. Lists every member — built-in by name, Entra accounts by SID.
Verify from the cloud side
entra.microsoft.com > Identity > Devices > Overview > Device Settings > Manage additional local administrators. The role page lists everyone currently assigned. Use this view as your source of truth for who has tenant-wide device admin.
Removing a user from the role
- Same path: Device Settings > Manage additional local administrators.
- Tick the user > Remove assignments > confirm.
- Effective for new sign-in sessions.
Active sessions retain admin rights until sign-out. When you’re removing someone for a real reason (offboarding, suspected compromise, role change), also revoke their sessions: Identity > Users > the user > Revoke sessions. Otherwise a logged-in attacker keeps admin until they reboot voluntarily.
Audit who changed the role
Every assignment and removal is logged. Identity > Monitoring > Audit Logs > filter Category = RoleManagement, Activity = Add member to role or Remove member from role. Each entry shows actor, target user, timestamp, and outcome. Review monthly as part of your privileged-access audit.
Things that bite people
Assigned but the user still shows as Standard
Sign-out and sign-in. Admin rights are evaluated at session start, not in the middle. If still wrong: confirm assignment in the cloud portal, confirm the device is genuinely Entra-Joined (not Entra-Registered) under Devices > All Devices.
Tried to scope to one device, surprised to see it tenant-wide
That’s the design. Use Intune or LAPS for device-specific assignment.
No save button = nothing happened?
The role commits on Add / Remove click. There’s no save button by design. If the page shows the assignment after the panel closes, you’re done.
Disabled account still in the role
A disabled Entra account can’t authenticate, so it can’t use the admin rights — but the SID lingers in the role. Clean it out as part of offboarding so audit reports stay accurate.
Helpdesk staff have admin on the CEO’s laptop
Yes — that’s tenant-wide. If the CEO’s device should be off-limits to helpdesk, either don’t Entra-join it, manage it via a separate tenant, or use Intune device-targeted Account Protection policies that override the role for that specific device.
Licensing
This role and the Additional Local Admins setting are available in every Entra ID tier including Free. No P1 or P2 needed.
What’s next
Tenant-wide device admin is a hammer. The next post in the Entra ID Security pathway covers the scalpel: Just-in-Time Local Administrator Access — granting elevated rights for a defined window with approval, reverting automatically when the window closes. The right pattern when you want admin to be the exception, not a standing assignment.