---
name: reference_gururmm_user_manager
description: GuruRMM has a built-in per-agent User Manager (endpoint local/domain/AAD users) — use it, not raw PowerShell
metadata:
  type: reference
---

GuruRMM has a **built-in per-agent User Manager tab** (Users + Groups) for managing the
*endpoint's* Windows accounts — do NOT hand-roll `Set-ADAccountPassword`/`net user` via `/rmm`
PowerShell for routine user ops.

- UI: agent detail → **User Manager** tab (`dashboard/src/components/UserManagerTab.tsx`).
- API: `GET /api/agents/{id}/users` (inventory: users, groups, `domain_join_type`, `domain_name`,
  `m365_tenant_id`, **`is_dc`**, `last_collected`), `POST /api/agents/{id}/users/refresh`,
  `POST /api/agents/{id}/users/action` body `{username, action, value?, new_password?, group_name?}`.
- Actions: `reset_password`, `set_enabled` (enable/disable), `set_password_never_expires`,
  `add_to_group`, `remove_from_group`.
- **Scope gate:** local accounts always manageable; **domain accounts manageable only when the agent
  IS a DC** (`is_dc` true) — on a non-DC member they show "Managed in AD" (read-only). AAD accounts
  show "Managed in Azure" (read-only). So to reset a domain user, target a DC agent.
- Advantage over raw PowerShell: structured action keeps the password out of the RMM command
  history (raw `Set-ADAccountPassword` leaks the plaintext into `command_text`).

(Distinct from SPEC-027 / `usersApi` = GuruRMM's OWN dashboard login accounts — different thing.)
Correction logged 2026-06-29 after I wrongly claimed no built-in action existed. See [[reference_resource_map]].