Admin Users
An admin user is a person who can sign in to the admin app. Every way into the admin app authenticates one: a password, a passkey, a server token minted on the host, and a server API key, which acts as the admin user who owns it. The server itself is what you administer, never who signs in.
| Way in | Who it authenticates | Second step | Allowed addresses |
|---|---|---|---|
| Username and password | That admin user. | Asked when they have an authenticator app, or when the server demands one; see A second step for every admin user. | Checked. |
| Passkey | The passkey's admin user. | Never: the passkey is both steps. | Checked. |
Server token (server:login) | The admin user named when the token was minted. | Never. | Not checked. |
| Server API key | The key's owner. | None. | Not checked. |
The first two are the everyday sign-in; the token is the break-glass, see Break-glass on the host; the keys are for your own systems, see API Keys.
Admin users are peers: there is nobody above them, and each can create, reset and delete the others.
The Admin Users screen
Admin Users, in the System menu, lists every admin user:
| Column | Shows |
|---|---|
| Username | The name they sign in with. You marks your own row. |
| Password | Set, Leaked (the password is on a public list of leaked passwords), Setup link not used yet, or Passwordless. |
| Second Step | Authenticator app or None. |
| Passkeys | How many they have registered. |
| Last Sign-In | When they last signed in, or Never. |
| Allowed IP Addresses | Where they may sign in from, or Anywhere. See Allowed addresses. |
The actions are Create Admin User, and on each row Allowed IPs, Reset credentials and Delete. Before any of them, the admin app asks you to confirm your identity, even though you're signed in, since whoever can create an admin user can sign in as one. The confirmation holds for five minutes.
The commands
elpanctl does the same from a root shell on the server, and a little more:
| Command | Does |
|---|---|
server:admin-user:create <username> | Creates an admin user and prints their setup link. --allow-ip=<ip or cidr> (repeatable) sets the allowed addresses; --with-password also gives them a generated password, printed once. |
server:admin-user:list | Lists them: username, whether they have a password, allowed addresses, created and last sign-in. --format=tsv or jsonl for scripts. |
server:admin-user:set-password <username> | Replaces the password, or gives one to an admin user who has none. Prompts for it unless --password= is given. |
server:admin-user:reset-credentials <username> | Removes every credential and prints a new setup link. |
server:admin-user:set-allowed-ips <username> --ip=<ip or cidr> | Replaces the allowed addresses; --clear lets them sign in from anywhere. |
server:admin-user:delete <username> | Deletes the admin user. |
Only the command line can set a password for somebody else, create an
admin user with a password, and delete an admin user the screen refuses to
delete (see Delete an admin user).
--with-password is for scripts, and for a server whose admin app isn't
set up yet: there is no page to claim a setup link on, so the command warns
and the way in is a password or a server:login token.
elpanctl server:admin-user:create <username>
elpanctl server:admin-user:create <username> --allow-ip=<ip or cidr>
Setup links
A new admin user gets no password. They get a single-use setup link instead, and set their own password, passkey and authenticator app with it. The screen shows the link once, right after you create the admin user; the command prints it. A reset of their credentials issues a new one the same way.
A setup link comes in two forms, and the admin user needs only one:
- the link itself,
https://admin.<server hostname>/r/<code>; - the claim page,
https://admin.<server hostname>/r, where they type their username and the eight-digit PIN that comes with the link. This is the form for a phone call.
What it does:
- The link is valid for seven days. Once opened, the setup session lasts thirty minutes.
- Eight wrong PINs cancel the link. Issuing a new link for the same admin user cancels the previous one, so one link is pending per admin user; the screen shows Setup link not used yet while it is.
- The setup pages offer a password, a passkey, or both, and the authenticator app. Finish appears once the admin user has a working way in. While the server demands a second step of every admin user, one who set a password must also set up the authenticator app before Finish.
- Issuing and using a link are rows of the Auth Log: Setup link generated and Setup link used.
The account holders' setup links work the same way; see Your setup link in the account docs.
A setup link is a credential: whoever opens it becomes that admin user. Give the link and the PIN over different channels, or read the PIN out on the phone.
The admin user root
root is the default admin user, the one a bare server:login on the host
signs in as and creates when missing; see
Break-glass on the host. Otherwise it's an ordinary admin
user: it can have a password, passkeys and an authenticator app, and it can
be deleted. It also owns the server API keys made before keys had owners;
see API Keys.
Reset an admin user's credentials
Reset credentials on the screen, or
server:admin-user:reset-credentials <username>, takes every way in away
from an admin user: the password, the passkeys, the authenticator app and
its backup codes, the devices and the trusted devices. Every session of
theirs ends. You get a new setup link to give them.
elpanctl server:admin-user:reset-credentials <username>
Use it when an admin user has lost their way in, or when their credentials may be in somebody else's hands. The reset is one row of the auth log, Sign-in reset, and the other admin users' devices with alerts on are told.
The screen refuses to reset your own credentials: your session would end
with them, and the link with the session. Change your own on
Password & Security, see
The Password & Security page,
or ask another admin user. On the host, server:admin-user:set-password
and server:login are the other ways back in for anybody.
A password change, a credential reset, and the removal of a password each end the admin user's other sessions on their next request.
Delete an admin user
Deleting an admin user deletes their passkeys, their devices, the server API keys they own, and their rows of the auth log. An integration that uses one of their keys stops working. There is no undo.
Delete on the screen, or server:admin-user:delete <username>:
elpanctl server:admin-user:delete <username>
The screen refuses two deletions: your own admin user, and the last admin
user who can sign in with a password or a passkey. Without that one, only
root on the host could sign in, with a server:login token; give another
admin user a password or a passkey first. The deletion is recorded on the
admin user who deleted, as Admin user deleted, since the deleted admin
user's rows go with them.
The command refuses nothing: root on the host has the server:login token
anyway.
What the other admin users hear
Admin users have no email address in the panel. The channels between them are the auth log and their devices (see Devices): a created, reset or deleted admin user is pushed to every other admin user's devices that have alerts on.