-
Notifications
You must be signed in to change notification settings - Fork 4
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.
| 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.
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.
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 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.
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.
- 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