Users screen

The Users screen lists local and Active Directory-backed users with their global roles, account and 2FA state, and each user’s vault-grant count.

Only Owner and Admin can open this screen. Auditor and User cannot list users. When the license is read-only, the list and details remain available, but actions that change a user are blocked.

What you can do here

• Create a local user and assign a temporary master password and initial role.
• Edit a username or display name.
• Assign Admin, Auditor, or User to a non-Owner user.
• Disable a user, reactivate them when capacity allows, or permanently delete an already-disabled user.
• From the founding Owner only, set a temporary password or reset 2FA for another non-Owner user.

This screen does not create another Owner. Normal creation and role changes offer only Admin, Auditor, and User.

Read the list and details

Users are listed in creation order. Each row shows role and source badges, display name and username, vault-grant count, a shortened public-key fingerprint, 2FA state, and whether the account is active or disabled.

View detail shows the same facts in a drawer. It does not show sessions, a per-user audit timeline, creation time, the Active Directory DN, or the full public key.

Source badges mean:

• Local: a user created in VaultPilot.
• Synced: a user from a directory provider; the provider appears when it can be found.
• Active Directory: a user linked to an encrypted AD credential record.

The screen may show a local user as Synced when the name matches a selected directory object. The badge alone does not prove how the user signs in.

An active user can sign in and counts toward license capacity. A disabled user cannot sign in and does not count; the record is not deleted. Placeholder rows appear while loading, and an empty state appears when no users are returned.

Create a local user

1. Open Create new user.
2. Enter a unique username of at least two characters.
3. Optionally enter a display name.
4. Select Admin, Auditor, or User.
5. Enter the same temporary master password in both fields; it must be at least 14 characters.
6. Select Create user.

Creation requires Owner or Admin, a writable license, and free active-user capacity. If capacity is full, upgrade the license or disable an account that should no longer sign in.

The browser prepares the user’s keys from the temporary master password; the password itself is never sent to the server. VaultPilot creates an active local user with a personal vault and gives the user Manager access to it.

Never put the temporary password in an audit note, support ticket, or screenshot. Deliver it through a trusted separate channel.

Edit identity and roles

Owner and Admin can edit the username and display name of active users. An Owner username cannot be changed, and an Admin cannot edit an Owner record. An Owner may edit their own display name.

A user cannot change their own global role, and the Owner role cannot be changed. Editing and role selection are disabled for disabled users; reactivate the user first.

Do not confuse the global role with a vault role. The count on the row does not show the permission level held in each vault.

Active Directory sign-in access

AD sign-in access is not granted from a Users row. Use Allow VaultPilot sign-in or Remove from VaultPilot sign-in on the related Active Directory record.

This flow is Owner-only and requires a writable license. A directory user needs its provider and directory details; an AD credential record needs its stored secret. A newly managed user is created as User; an existing Admin or Auditor role may be kept.

VaultPilot does not check the password against AD on every sign-in. Enabling access creates VaultPilot sign-in keys from the current encrypted AD credential password. A password changed later outside VaultPilot is not synchronized automatically. Selecting an OU or user does not create an account.

Refreshing managed sign-in is refused when the managed user already has shared-vault access. Removing sign-in access disables the user and ends their sessions.

Changing the user state and saving the directory selection are separate steps. The first can succeed while the second fails. After an error, reload and check the Users list and AD selection separately.

Set password and reset 2FA

These actions are available only to the founding Owner. New installations use VpAdm; the older founding username administrator is still recognized. Neither action can target the current account or any Owner account.

Set a temporary password

• The password must be at least 14 characters and match its confirmation.
• The user’s sign-in keys are replaced.
• The 2FA binding is reset and open sessions end.
• The audit history records the password set; the password itself is never recorded.

Stop condition: Do not treat this action as lossless vault recovery or routine password rotation. It creates a new personal-vault key and can carry over only shared-vault access that the founding Owner can currently unlock. Existing personal-vault content, or shared access that was not carried over, can become unreadable. Stop unless the content and vault-access inventory has been verified.

Reset the 2FA binding

The current authenticator binding is removed, the audit history records the reset, and open sessions end. After the next successful sign-in, the user can enroll a new device. Nothing happens when the user has no 2FA binding.

Disable, reactivate, and permanently delete

Disable a user

Owner or Admin can disable another active, non-Owner user, but not themselves. The account becomes disabled, sessions end, license usage decreases, and the audit history records the change. No Owner can be disabled.

Reactivate a user

Reactivate appears only for a disabled user. It requires a writable license and free active-user capacity. Success makes the user active again and is recorded in the audit history.

Permanently delete a user

Only an already-disabled user who is neither the current account nor an Owner can be deleted. The action cannot be undone.

Stop condition: Do not delete until ownership is transferred for the personal vault, shared-vault grants, and user-linked operational records. Deletion can also remove that user’s audit entries, extension devices, API clients, directory providers and actions, discovery records, stored files, and sent or received shares.

The audit history records the deletion just before it happens, with the user’s name, role, personal-vault count and a summary of the audit entries removed with the user. The user’s full audit trail is not kept.

Audit and operation boundaries

Creating, editing, changing the role of, disabling, reactivating, setting a password for, resetting 2FA for and deleting a user are each recorded in the audit history. Removing AD sign-in is recorded as a disable; refreshing managed access as an edit.

Not every entry names the affected user in the same detail. Review actor, time, action and any target details together.

The user change, the audit entry and ending sessions are separate steps. A late audit or session error can appear after the user already changed. After an error, reload the list and check account, session, license and audit state before retrying. Do not repeat a destructive action blindly.

Screen states

Before you act

• Confirm the correct server profile and user row.
• Review global role and vault role separately.
• For an AD user, check the AD record and VaultPilot account state separately.
• Confirm a password or 2FA target is neither the current account nor an Owner.
• Transfer active work and integration ownership before disabling access.
• Before deletion, list the user’s vaults, shares, API clients, directory and discovery records, and audit entries.
• Check active-user capacity before creation or reactivation.
• Read the username in the confirmation dialog one final time.

Safe evidence

• Safe to share: role, active or disabled state, whether 2FA is on, and a redacted vault-grant count.
• Use the audit action, timestamp, and a shortened integrity hash.
• For license evidence, show only the active-user total and limit.
• Keep private: real usernames, display names, email or UPN, DN, public keys, personal-vault names, and screenshots of the user list.
• Never include a temporary master password, TOTP secret, authenticator QR or recovery data, or a vault key.
• For screenshots sent to support, redact usernames and key fingerprints and never capture filled password fields.

Operator notes

• The screen does not show last sign-in or last activity. Do not report those fields as if reviewed here.
• Set password does not change an external-provider password and is not automatic rotation.
• AD sign-in access does not check AD live, and selected AD objects do not become accounts automatically.
• Disabling keeps the record; permanent deletion is irreversible and removes linked records.
• The user change and the audit and session cleanup are separate steps.
• This screen has no control for creating another Owner or transferring the Owner role.

Related

• First run, owner and license
• Security and trust model
• Audit log screen
• Active Directory records screen
• Sharing screen
• License screen

Back to Documentation →