MonsterOps logo MonsterOps
Docs / System / Roles & Admin Users

Roles & Admin Users

Overview

Admin users are the people who log into MonsterOps — separate from your RADIUS subscribers. Each admin has one of three roles, enforced server-side on every route (not just hidden in the UI). The first-run wizard creates the initial superadmin.

The three roles

Role Can do
superadmin Everything — admin management, System settings, backups, VPN bring-up/down, firewall apply, and the Server Console
admin Day-to-day operations — users, groups, NAS, pools, realms, sessions, firewall build, automation; cannot manage admin accounts or activate tunnels
readonly View-only across all pages; every write endpoint is rejected

Where things are

  • Admin users (System → Settings) — create accounts, assign roles, disable accounts.
  • Sessions & security — the browser session uses HttpOnly cookies (the JWT is never exposed to JavaScript), with a short-lived access cookie rotated by a longer-lived refresh cookie. Mutating browser requests carry a CSRF token; programmatic clients using API keys use bearer auth and aren't subject to CSRF.

Two-factor authentication (2FA)

Add a second factor to admin sign-in — a 6-digit code from an authenticator app (Google Authenticator, Aegis, 1Password, …), computed offline from a secret stored encrypted on the server. No external service, no phone number.

  • Set it up (System → Security → Set up two-factor) — scan the QR code (or type the setup key), confirm a code, then save the ten one-time recovery codes. They're shown once.
  • Sign in — after your password you enter the current code. Lost the device? Choose Use a recovery code instead — each code works once.
  • Require it — a superadmin can mark an account Require two-factor (System → Admins), or set MONSTEROPS_REQUIRE_2FA=true to require it for every admin. A required admin who hasn't enrolled is sent to set it up at next sign-in and can't turn it off.
  • Reset it — a superadmin can Reset 2FA for someone who lost their device; they then sign in with just their password and re-enrol.

Enrol, disable, reset, and failed-code events are all written to the audit log. The shared secret is re-encrypted automatically when you rotate MONSTEROPS_SECRET_KEY.

Keep your recovery codes

They're the only way back in if you lose your authenticator and no superadmin is around to reset you. Store them somewhere safe — a password manager, not the same device.

Common tasks

  • Harden admin logins — turn on two-factor for your account (System → Security), or require it estate-wide with MONSTEROPS_REQUIRE_2FA.
  • Add a read-only viewer — create an admin with the readonly role (e.g. for a NOC dashboard user).
  • Delegate daily ops — admin role; keep superadmin for the few who manage accounts, tunnels, and firewall apply.
  • Grant external/script access instead — use scoped API keys, not an admin login.

Problems you may hit

Serve production over HTTPS

Session cookies become Secure automatically over HTTPS (or when a proxy sets X-Forwarded-Proto: https). Over plain http:// they're intentionally not Secure so LAN access works — but the token then travels unencrypted. Don't run production on bare http.

  • An admin can't apply firewall changes or toggle VPN — those are superadmin-only by design.
  • Locked out of the only account — create a new admin from the server (CLI/DB) to recover.
  • Locked out by 2FA with no recovery codes — a superadmin can Reset 2FA for you; if it's the only superadmin, clear that account's row from the mr_admin_totp table to disable the second factor, then re-enrol.
  • A user sees the button but gets rejected — the UI may show an action, but the server enforces the role; the rejection is correct.
  • API Keys — programmatic access with scopes
  • Settings — where admin users are managed
  • Health — the superadmin-only Server Console