Users and Access Scoping - limuhua-backup/corten-desk GitHub Wiki
Users and access scoping
Console accounts sign in with a username, not an email address. Email is optional per user, but without one that person cannot receive an invitation, a password reset, or an emailed sign-in code.
Account types
| Administrator | Sees and does everything. Bypasses all device scoping. |
| Regular user | Sees only the devices they are entitled to. Console areas are governed by their role. |
Only a full administrator can grant the administrator flag or assign a role.
The user detail page
Since 1.10.0.
Click a username on Users (or the eye icon on its row) for one person in full: role, groups, two-factor, sign-in method, when the account was created and last signed in, the devices and address books they own, recent sign-ins, recent console actions and connections.
Each section follows the permission of the screen it comes from. Sign-ins and console actions need Manage on Logs, connections need View on Logs, devices need View on Devices (and list only devices you can see), and address books need View on Address books. Lists stop at 25 rows and link to the full log where there is one.
Connections are listed two ways: into devices the user owns, and from the RustDesk IDs the user has signed in on with the RustDesk client. The log records devices, not people, so anyone else using that machine shows up there too.
Appearance
Since 1.12.0. The light/dark switch in the top bar is saved to the account, so it holds in every tab, browser and device. My Account → Appearance also offers Match system, which follows the operating system's setting. The sign-in page uses the last choice made in that browser.
Disabling and force-logout
A user can be disabled rather than deleted. A disabled account cannot sign in to the console, and its RustDesk client tokens are refused.
Force logout revokes everything at once: all client API tokens for that user and all of their console sessions. Use it when a laptop goes missing. The person can sign in again afterwards unless you also disable them.
Changing a user's password revokes the same set, so a password reset cannot leave an old session alive.
Which devices a user sees
This is the rule, exactly:
administrator → every device
anyone else → devices assigned to them
+ devices in any device group they can access
A user reaches a device group in one of these ways:
- granted to them directly
- granted to a user group they belong to
- granted through a group access entry
Pending devices are excluded for everyone until approved.
The same rule governs the RustDesk client API. When a user signs in from a RustDesk client, the device list and address book that client receives are scoped identically. Access is not a console-only decoration — you cannot see a machine in the client that you cannot see in the console.
User groups
User groups exist to avoid granting the same device groups over and over. Put people in a user group, grant device groups to that user group, and membership does the rest.
They are also exposed to the RustDesk client's group tab.
Recommended layout
For most fleets:
- One device group per site, customer or department.
- One user group per team that supports those sites.
- Grant device groups to user groups, never to individuals, unless it is genuinely a one-off.
- Keep administrators to the smallest possible number and give everyone else a role.
Related
- Roles and delegated administration — what a non-admin can do, as opposed to what they can see
- Devices and device groups
- Email, invitations and password reset