claudetools/.claude/memory/feedback_rmm_password_limitation.md

RMM Password Setting Limitation

Date: 2026-06-07 Context: Wolkin ZeroTier printer setup

Issue

PowerShell commands to set local user passwords via GuruRMM (running as SYSTEM context) do not work properly, even though they return success codes.

Commands that FAIL when run as SYSTEM via RMM:

Set-LocalUser -Name "julie" -Password $securePassword
net user julie Jaylen0607! /passwordreq:yes

Both commands complete with exit code 0 and show "The command completed successfully", but:

• The password doesn't actually get set correctly
• Authentication with the password fails
• net user julie shows "Password required: No" (even after trying to set it to Yes)

Working Method

Running the same net user command interactively as a local admin account (e.g., localadmin) DOES work correctly.

Root Cause

NOT a SYSTEM privilege issue - ScreenConnect also runs as SYSTEM and password operations work there.

NOT a PowerShell vs CMD issue - Tested both:

• command_type: "powershell" - FAILED
• command_type: "shell" (cmd.exe) - FAILED
• ScreenConnect CMD - WORKED

All three execute the identical command net user localadmin r3tr0gradE99!, all return exit code 0 and "The command completed successfully", but only ScreenConnect actually sets the password.

Confirmed GuruRMM agent bug - Something about how the GuruRMM agent spawns the child process differs from ScreenConnect. Possible factors:

• Process creation flags (CREATE_NO_WINDOW, DETACHED_PROCESS, etc.)
• How stdin/stdout/stderr handles are created or inherited
• Session/desktop isolation settings
• Token or privilege differences in how the process is spawned
• Windows API differences (CreateProcess vs CreateProcessAsUser vs other variants)

Investigation needed: Compare GuruRMM agent's command execution code (server/src/agent/mod.rs or Windows agent spawn logic) with how ScreenConnect spawns processes.

Workaround

For password operations on client machines:

1. Use ScreenConnect or other interactive remote access
2. Log in as a local admin (not SYSTEM)
3. Use net user <username> <password> command
4. Verify with net user <username> | findstr "Password required"

Related

• GuruRMM commands run as SYSTEM by default
• context: "user_session" runs as the logged-on user (if any), but still may not have admin rights
• No elevated: true + context: "admin" option exists yet for "run as local admin" context

Future Enhancement

Consider adding a RMM command context option to run as a specific local administrator account rather than SYSTEM, for operations that require local admin but not SYSTEM privileges.

Priority

HIGH - This affects basic Windows administration tasks (user management, password resets). Current workaround (use ScreenConnect) is acceptable but GuruRMM should be capable of the same operations ScreenConnect can do.

Next Steps

1. Review GuruRMM Windows agent code for how it spawns cmd.exe and powershell.exe processes
2. Compare with ScreenConnect's known-working process creation method
3. Test with different CreateProcess flags to identify which setting causes the password operation to fail
4. Fix in GuruRMM agent and add test case to prevent regression