claudetools/.claude/memory/reference_gururmm_user_manager.md

name, description, metadata

name	description	metadata
reference_gururmm_user_manager	GuruRMM has a built-in per-agent User Manager (endpoint local/domain/AAD users) — use it, not raw PowerShell	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.