User Management
ProxCenter provides centralized user management for your platform. Administrators can invite team members, assign roles, and control access to the dashboard from a single interface.
In multi-tenant deployments, provider administrators can also review users across every tenant from one cross-tenant view.
User Listing
Navigate to Security & Access > Users to view all users in your ProxCenter instance. The user list displays:
| Column | Description |
|---|---|
| Name | Full name of the user |
| Email address used for authentication | |
| Role | Assigned role determining their permissions |
| Status | Active, invited, or disabled |
| Last Login | Timestamp of the user's most recent login |
| Created | Date the user account was created |
Use the search bar to filter users by name or email. You can also sort by any column.
Cross-Tenant Users
Provider administrators can view all users across all tenants from a single page. This view shows:
- User identity and account status
- Tenant assignments
- Effective role propagation
- Last login and invitation state
Tenant administrators only see users assigned to their own tenant.
Inviting Users
To add a new user to your ProxCenter instance:
- Navigate to Security & Access > Users
- Click Invite User
- Enter the user's email address
- Select a role to assign
- Click Send Invitation
The invited user will receive an email with a link to set up their account and create a password. The invitation appears in the user list with a status of Invited until accepted.
You can invite multiple users at once by entering several email addresses separated by commas.
User Roles
Every user must be assigned a role that defines their level of access within ProxCenter. By default, the following system roles are available:
- Admin -- Full access to all features and settings
- Operator -- Can manage infrastructure and perform operations, but cannot modify users or security settings
- Viewer -- Read-only access to dashboards and inventory
With the Enterprise edition, you can create custom roles with fine-grained permissions and tenant-aware assignments. See RBAC for details.
Roles on a Community install
Role assignment is an Enterprise feature, so the role picker in the user dialog is not shown on a Community install. In its place the dialog states the rule that applies instead:
In Community edition, every user has full administrator access. Scoped, role-based permissions require the Enterprise edition.
That is not a formality. On a Community install, an account created from Security & Access > Users is granted the super_admin role at global scope in its own tenant, as part of the creation itself. Community has no way to narrow it afterwards, so an account that received nothing would land on an empty dashboard with no screen able to repair it.
Between v1.4.7 and v1.4.8 that grant was tied to a resolved license verdict. A Community install that runs the frontend alone never establishes one, so accounts created in that window received no grant at all: their owner signed in successfully and saw an empty dashboard, and no administrator could fix it, since the only control that assigns a role is the Enterprise picker.
Upgrading to v1.4.8 repairs them. The grant now keys on the shape of the deployment rather than on a license answer, and every sign-in checks the account that is signing in: if it holds no active role and no active individual permission, and the deployment is Community, it is granted super_admin there and then. The check runs whatever the sign-in method, it never blocks a sign-in, and it leaves alone any account that already holds a grant, so it cannot overwrite a deliberate assignment. Ask the affected users to sign in once and their dashboard fills.
The repair is recorded in the audit log like any other grant.
On an Enterprise install nothing of this applies: a new account is created with no grant, and you assign its role from the picker in the same dialog, or from the Assignments tab of Security & Access > RBAC / Roles when it needs several scoped roles.
Editing a User
To modify an existing user:
- Click on the user in the user list
- Update their name, role, or status as needed
- Click Save Changes
Administrators can also:
- Reset password -- Send a password reset link to the user's email
- Disable account -- Temporarily prevent the user from logging in without deleting their account
- Remove user -- Permanently delete the user account and revoke all access
Removing a user is irreversible. Their actions will still appear in the audit log, but they will no longer be able to access ProxCenter.
API tokens the account created
Disabling or deleting an account does not stop the API tokens it minted. A token is a service account with its own secret and its own scopes: it does not ride on anybody's session, so it keeps reading your fleet after its creator is gone.
Since v1.4.8 the dialogs say so rather than letting you find out. When the account you are disabling or deleting has active tokens, the dialog lists them, each with its name, its prefix and when it was last used, under the warning that applies:
- Disabling: This account created N active API token(s). Disabling the account does not stop them: a token authenticates on its own.
- Deleting: This account created N active API token(s). They survive the deletion: a token authenticates on its own.
Tick Delete these tokens as well to remove them in the same gesture. The box is unchecked by default every time the dialog opens: a token outliving the person who created it is often the correct outcome, a scraper that must keep running for instance, so nothing is destroyed unless you ask for it.
When the box is ticked, the tokens are deleted before the account is written, so a failure leaves the account untouched rather than disabled with live tokens behind it. The audit entry for the account change carries how many tokens went and which prefixes.
If you leave the tokens alive, they keep their provenance: each row in Settings > API carries a Created by column, frozen at creation, that still names the deleted account.
Seeing the tokens of a user needs admin.users, the permission that already governs this page, not admin.apitokens. An administrator offboarding somebody can see what that person issued without being given the whole token table.
Two-Factor Authentication
The user list shows a 2FA column indicating whether each user has TOTP enrolled. A super_admin can act on this column from the row action menu:
- Require 2FA -- Force the target user to enroll TOTP on their next sign-in. Available when the target has not enrolled and no requirement is currently active.
- Cancel 2FA requirement -- Lift the requirement before the user enrolls. Available when the requirement is active.
- Disable 2FA -- Remove TOTP and all recovery codes from the target account. Available when the target has 2FA enrolled. Use this as a recovery path when a user has lost both their authenticator app and their recovery codes. The action is refused on the actor's own row to prevent self-lockout, and is refused when the policy "Require 2FA for super_admin" would force the actor to immediately re-enroll.
All three actions emit audit events under category auth (2fa_required_for_user, 2fa_requirement_cleared, 2fa_disabled) with resourceId set to the target user id.
See Two-Factor Authentication for the user-facing flow and the global policy.
Sessions
A ProxCenter session is a row in the database, and that row is what grants access. It can therefore be ended on demand instead of remaining valid until its cookie lapses, and a revoked session is refused on the very next request the browser makes.
Your own sessions
Every user manages their own sessions from Profile, in the Active sessions card at the end of the Security section. Each row shows the browser and operating system (the full user agent is in the tooltip), the IP address, when the session signed in and when it was last active. The session you are reading the page with is tagged This device.
- Sign out on another row ends that one session.
- Sign out other sessions ends every other session at once and keeps the current device signed in.
The current session has no Sign out button of its own: use the normal sign-out for that.
Another user's sessions
The user list carries a read-only Sessions column with the number of live sessions per user. A super_admin also gets a second tab on Security & Access > Users, All sessions, listing every live session of the installation with its user, tenant, sign-in time, last activity, IP address and device. The list is ordered by last activity and capped at the 500 most recently active sessions, with a warning when the installation has more.
| Action | Scope |
|---|---|
| Revoke session | The single session on that row |
| Revoke sessions | Every session of that row's user |
| Revoke all sessions | Every session of every user of the installation, your own included |
Revocation is not a lockout. The user can sign in again immediately, so use Disable account or Remove user when that is what you mean.
Revoke all sessions signs the whole installation out, you included, and Revoke sessions on your own row signs you out too. Both confirmation dialogs say so before you commit.
Changing a user's password, or disabling their account, revokes all of that user's sessions as a side effect.
Sessions also end on their own: after 12 hours without activity, and 7 days after sign-in whatever the activity. Both deadlines are configurable, see Session lifetimes.
Audit trail
Administrator revocations are written to the audit log under category auth:
| Action | Notes |
|---|---|
session_revoked_single | One session, details.by = "admin". The session id is deliberately never logged |
sessions_revoked | Every session of one user, details.revoked carries how many |
sessions_revoked_all | Every session of the installation, details.revoked carries how many |
Signing yourself out of your own sessions from Profile is not audited.
Permissions Overview
User permissions in ProxCenter are determined by their assigned role. Each role contains a set of permissions organized by category:
| Category | Examples |
|---|---|
| VM | vm.view, vm.start, vm.stop, vm.create, vm.delete |
| Storage | storage.view, storage.manage |
| Node | node.view, node.manage |
| Backup | backup.view, backup.create, backup.restore |
| Admin | admin.users, admin.rbac, admin.audit, admin.settings |
A user can only perform actions for which their role grants the corresponding permission. Menu entries and UI elements are automatically hidden when the user lacks the required permission.
Permissions
Access to User Management requires the following RBAC permission:
| Permission | Description |
|---|---|
admin.users | View, invite, edit, and remove users, and revoke every session of one user |
The All sessions tab, revoking an individual session, and revoking every session of the installation are reserved for the super_admin role itself rather than granted by a permission.