Users and Roles
An Admin manages the people on a tenant under Settings > Users and Roles. The list covers everyone: active members, suspended ones, and invitations nobody has accepted yet, each with their email, role, and status.
Onboarding is by invitation link only. There is no self-service registration, and every account authenticates against your installation.
The Two Roles
| Role | What it means |
|---|---|
Admin |
Administers the system: users and roles, data sources, exclusion groups, the vulnerability data, email, API tokens, and the audit log. |
Member |
Uses every licensed capability, including decisions that carry commercial weight, such as creating a migration wave or a wave schedule. |
The boundary is administering the system against using the product, not a general permission tier. Capability actions are never role-gated: Members do the work the product exists for.
The audit log is the one exception to that, and it is Admin-only because its entries expose actions other users took. Reading what somebody else did is administration, not capability work. See Audit Log.
Inviting Someone
Invite by email, with a role you assign then or change later.
An invitation is scoped to one tenant and is single-use, and accepting it is atomic: two people clicking the same link resolve to exactly one success. Re-inviting an email that already has an invitation outstanding invalidates the earlier one rather than leaving two valid links in the world.
Acceptance requires the invitee to set their own credentials. The Admin never sees or sets them.
The dialog always shows the one-time link, and says separately what became of the email: sent, where a provider is configured; or a plain statement that none is configured and the link must be shared by hand. See When No Email Is Sent.
Suspending and Removing
| Action | Effect |
|---|---|
Suspend |
Reversible. Access stops; the role and the history are preserved. |
Remove |
Permanent, and scoped to this tenant only. |
Neither action affects the same person’s membership in another tenant, and neither deletes audit history.
Changing a Role
Set a member’s role at invite time or later. A role change applies on that member’s next request, because authorisation is re-read live rather than cached, so there is nothing to invalidate and no window in which the old role still works.
Your installation blocks the case where you would lock yourself out: you cannot demote or remove yourself as the last active Admin. A suspended Admin never counts toward a tenant still having one.
|
Caution
|
The guard covers one actor, not the general case. Two Admins independently demoting or removing each other in the same window can still leave a tenant with no Admin at all. Where a tenant has exactly two, coordinate the change. |
Resetting a Password
A password reset starts in one of two ways, and both end in a one-time link that only the affected person can use to set a new password.
Forgot Password
On the sign-in page, Forgot password? emails the person a reset link that is valid for 24 hours and works once. The option appears only when LJVMI_WEB_PUBLIC_BASE_URL is set and at least one tenant can send mail. Otherwise the sign-in page tells people to ask an Admin. See Email.
-
The answer is the same whether or not the address has an account, so the form never reveals who has one.
-
Asking does not change the existing password. It keeps working until the link is used.
-
A link is sent only for an account with an active membership in a tenant that can send mail, and no more than one link per minute is issued for an account. If the mail fails, the link is withdrawn at once.
Both ends are recorded in the audit log, with the account the link belongs to as the actor: Password reset requested once the link was mailed, so a request that sent nothing leaves no entry, and Password reset completed when the link was used. See Audit Log.
Reset by an Admin
An Admin can force a reset for any member. The existing password is invalidated immediately, and the triggering Admin can never authenticate as the person, because only they can set the new password through the link.
The dialog shows the link and says what became of the email, exactly as an invitation does.
The audit log records the reset itself as a member password reset, with the Admin as the actor, and Password reset completed once the person uses the link. See Audit Log.
The First Admin
On a fresh database your installation creates an initial Admin and generates a random password, logged once and written to a file with owner-only permissions. Your first sign-in returns a restricted session and requires you to change that password before anything else.
Recovering a Lost Admin Password
An installation whose only Admin has lost their password is recovered by an Operator: set ADMIN_PASSWORD_RESET=true and restart. That resets the password of the admin account and generates a new one rather than accepting one you choose, and it is the same authority that editing the database by hand would need, without the SQL.
-
The new password is written to the log and to
.initial-admin-passwordbeside the application database, with owner-only permissions. -
Sign in with it. Your installation requires you to change it at once.
-
Unset
ADMIN_PASSWORD_RESETand restart again. While it is set, every restart resets the password, and the log says so each time.
It never creates an account. A tenant whose original Admin was removed is not recoverable this way, which is the other reason to keep more than one Admin.
Managing Users From Automation
The integration API covers the same operations with the same reads and writes: listing members, inviting, removing, changing a role, suspending, unsuspending, and triggering a reset. See The Integration API.