Users & Roles

The Users page at /users is where console user accounts are created, edited, and deleted. User accounts are the identities that sign in to the console — not the agents, not the devices, not the customers. One account per technician.

NetLock RMM's access model is per-user permissions, scoped to tenants. There is no separate Roles page and no role templates to assign — control is exercised through a permission matrix on each user account. Read this chapter before spending time looking for role management elsewhere; the access model is explicit, flat, and per-user, and understanding it up front saves confusion later.

14.1 The Users list

The Users list shows one row per user account.

Toolbar actions include Add User, Manage (open the selected user's settings), and Export Data to JSON or HTML.

Double-clicking a row, or using the Manage action, opens the user's settings page — covered in 14.3.

14.2 Creating a user

Add User opens the Add User dialog.

Fields:

• Name — required. This is the username the user will log in with.
• Password — auto-generated, 12 characters, read-only in the dialog. The dialog also exposes a Copy to Clipboard button that copies both the username and password in one action, so you can paste them into your password manager or the credential-delivery workflow of your choice.
• Role — a dropdown. In the current release this dropdown contains only Administrator; the value is stored as a free-text label on the user row and does not by itself grant or deny any permissions (see 14.4).
• Auth Mode — Password, SSO, or Password & SSO. Chooses how the user signs in.
  • Password — local password only.
  • SSO — single sign-on only; local password is unused.
  • Password & SSO — either mechanism works.

Submitting the dialog creates the account. The password is stored hashed (BCrypt) — never in plain text — and the new account is flagged for mandatory password change on first login. When the user first signs in, the console forces them to pick a new password before anything else.

Tip: Keep the dialog open until you have captured the generated password. Once the dialog closes, there is no way to retrieve that initial password from the UI. If you miss it, use the Reset Password flow (14.6) to generate a new one.

14.3 The user settings page

User Settings at /user_settings is the full editor for a single user. It is reached from the Users list via double-click or the Manage button.

The page is divided into sections:

• Account details — username, email, phone, role label, and authentication mode.
• Permissions — the matrix described in 14.4.
• Tenant scope — the table described in 14.5.
• 2FA — the switches described in 14.6.
• Actions — the Reset Password and Delete affordances described in 14.6 and 14.8.

A Save button at the top or bottom of the page commits every edit on the page in one step; unsaved changes are kept in the browser until you save or navigate away.

14.4 Roles and permissions

There is no separate Roles page in NetLock RMM. The Role column on the Users list, and the Role dropdown on the Add User dialog, hold a free-text label attached to the user. The label does not map to a predefined permission set — it is descriptive.

All actual access control is exercised through the permission matrix on User Settings, per user, one account at a time. There are no role templates to clone, no bulk "assign this role to these users" affordance, and no inherited role layers. If you want ten technicians to have the same permissions, you configure ten accounts.

The switch-plus-checkbox pattern

The permission matrix is a set of sections, each introduced by a parent switch. The parent switch turns the whole section on or off. Inside each section, a set of child checkboxes gives finer-grained control over the affordances within. When the parent switch is off, its child checkboxes are disabled — even if their values are set, they have no effect until the parent switch is back on.

This pattern is consistent across the matrix: a user who cannot open a page at all does not need the child checkboxes under that page enabled; but if you are later going to grant page access, the child values are preserved and come back to life when the parent switch flips on.

The sections

The top-level sections in the matrix, in the order they appear:

• Devices — access to the Devices list, and per-tab / per-tool child checkboxes covering General, Software, Task Manager, Antivirus, Events, Updates, Remote Shell, Remote File Browser, Remote Control, Remote EventLog Viewer, Remote Registry Editor, SNMP Tools, Shutdown, Reboot, Wake On LAN, Force Sync, Deauthorize, and Move.
• Tenants — create / manage / edit / delete for tenants, plus analogous children for Locations and Groups.
• Automations — add / edit / delete for automation rules. See Chapter 5.
• Policies — add / manage / edit / delete for policies. See Chapter 6.
• Patch Management — access to the /patch-management page. See Chapter 7.
• Collections — a section per sub-feature: Antivirus Controlled Folder Access, Application Control, Device Control, Sensors, Scripts, Jobs, Custom Fields, App Hub, Software Deployment, and File Server. Each has its own child checkboxes for add / edit / manage / delete as applicable. See Chapter 8.
• Relay Server — access to the Relay Server page and the manage / add / edit / delete children.
• Website Uptime Monitoring — page access.
• Port Scanner — page access.
• Events — page access.
• Audit — page access.
• Users — the Users list plus add / manage / edit / delete children.
• Reports — page access plus Create, Edit, Delete, Generate, Schedules, and Brand Templates children.
• Tickets — optional module; add / edit / delete / assign plus the manage-section children (departments, templates, SLAs, and so on).
• AI — AI Chat page access. See Chapter 13.
• Settings — sub-sections for every settings page. Notifications have per-channel children (Mail, Microsoft Teams, Telegram, ntfy.sh, Webhook) with add / test / edit / delete; System, Maintenance, Updates, Database, Remote Screen, IP Whitelist, SSO, Whitelabeling, Globalization, Custom Fields, Dashboards, Reports, and AI/LLM all have their own section flags.

Every checkbox in the matrix corresponds to exactly one permission flag in the product. The flag names are the strings used throughout this documentation — devices_remote_shell, policies_edit, collections_scripts_add, reports_generate, and so on. See Appendix X.2 for the complete list.

How to approach the matrix

A practical pattern: start with the parent switches off, then turn on the sections the user needs access to and tick the children. For a read-only observer, grant the parent _enabled switches and leave the add / edit / delete children off; for a hands-on operator, grant the same switches and tick the children they need to act.

Don't try to represent a role as a stored object — represent it as a checklist you apply when provisioning each account.

14.5 Tenant scoping

Below the permission matrix is the Tenants table. It lists every tenant you have access to, with one checkbox per row. Ticking a tenant grants this user access to the devices, policies, events, and everything else scoped under that tenant.

Columns on the Tenants table: Name, Description, Author, Date, and Company.

The selection is stored as a list of tenant identifiers on the user account. A user with tenants A and B ticked will see devices, events, policies, jobs, and so on belonging to A and B; everything in tenant C is invisible to that user, regardless of whether their permission matrix grants devices_authorized_enabled or similar page access.

Permissions and tenant scope compound. To see devices in tenant A, a user needs both the devices_authorized_enabled flag (permission to open the Devices page) and tenant A ticked in the scope table (permission to see anything in that tenant).

14.6 Two-factor authentication and password reset

2FA switches

Two switches under the 2FA section of User Settings:

• Two Factor Enabled — turns 2FA on for this user. With this switch on, the user is prompted for a second factor on every login.
• Two Factor Remote Actions — a second, narrower switch that requires 2FA specifically for sensitive remote operations (remote shell, remote file browser, remote control, remote registry editor, and similar). Disabled when Two Factor Enabled is off — you cannot require 2FA on remote actions while the user has no second factor at all.

When Two Factor Enabled is first toggled on, the user is walked through 2FA enrolment on their next login.

Reset Password

A Reset Password button under the Actions section generates a one-time password for the user. The dialog shows the new password in a read-only field, with a Copy to Clipboard button for handoff, and sets the account back into mandatory-password-change state so the user must pick a fresh password on their next login.

Use this when a user has lost their credentials, or after the initial Add User dialog's generated password was not captured.

Warning: The one-time password is visible on screen only once. Close the dialog and there is no way to retrieve it again — you would have to run Reset Password a second time.

14.7 What the Users page does not do

Two commonly-expected features are not implemented in the current release. If you are looking for them, stop looking.

• No impersonation. There is no "log in as this user" affordance. To test what another user sees, sign in as them directly (using a password you reset for that purpose) or set up a dedicated test account with the permission shape you want to evaluate.
• No password policy configuration. The password length generated on account creation and on reset is fixed at 12 characters. There is no UI for minimum length, complexity rules, rotation interval, or password history.

If either of these gaps is important to your operational model, flag it to NetLock — they are product gaps, not configuration problems to be solved locally.

14.8 Deleting a user

The Delete button on User Settings opens the Delete User confirmation dialog. Deletion is:

• Hard — the account is removed from the accounts table, not soft-deleted or disabled. There is no recycle bin, no undo, no reactivate.
• Cascading to AI Chat — the user's AI Chat conversations and their messages are also deleted.
• Audited — an audit entry is written with action = delete and entity_type = user, including the deleted user's identifier and the admin who performed the deletion. See Chapter 12.3.

After deletion the console redirects back to the Users list.

Events, sessions, logins, and actions previously performed by the deleted user remain in the Audit log — the deletion removes the account, not the trail of what the account did.

14.9 Dialogs

Permissions

Access to the 2FA switches and the Reset Password button is gated by users_edit — they are edits on the user's record.

See Appendix X.2 for the full permission catalogue, including the flags referenced in the matrix throughout 14.4.

Related chapters

• Chapter 5 — Automations, Chapter 6 — Policies, and Chapter 8 — Collections cover the per-feature permission flags that appear under their respective sections in the matrix.
• Chapter 12.3 — Audit documents the audit trail written by every create / edit / delete on user accounts.
• Chapter 13 — AI Chat covers the ai_chat_page_enabled flag that appears under the AI section of the matrix, and the effect of deleting a user on their AI Chat conversations.
• Appendix A.4 — Security: IP whitelist & SSO covers the SSO configuration that the Auth Mode field on Add User depends on.
• Appendix X.2 — Permission reference is the complete catalogue of the flags exposed in the permission matrix.