Users

Admin only. This panel is hidden from non-admin operators. If the tab isn’t visible in your Settings nav, your account doesn’t have the Admin role.

The Users panel is the GUI for local Mimir accounts — the username-and-password accounts your team uses when there’s no SSO identity provider in the loop. It also lists everyone who’s ever signed in via SSO, so the panel doubles as the canonical “who has access to this tenant” view.

In v1 the only mutation the panel exposes is create. Roles can’t be changed after the fact, and there’s no edit, disable, or delete affordance — Mimir doesn’t currently surface those flows in the GUI. This page covers what you can do here and what to fall back to when you can’t.

What you get

One table and one create form:

Users table — every Mimir account, paginated server-side but fetched fully into the page on load. Four columns:
- Username — the canonical identifier on the account.
- Role — Admin (orange) or Operator (muted).
- Sign-in — a small pill showing which provider the account authenticates against: Password (local), OIDC / Entra, or SAML 2.0. Matches the row’s provider tag.
- Created — when the row first landed in the users table, in your Time & Display format.
Add user form — at the bottom of the panel. Three controls:
- Username — free text. Mimir accepts whatever you type as the canonical identifier.
- Password — minimum 14 characters. The form’s Min. 14 characters hint reflects the server’s policy.
- Admin (can manage users and settings) — a checkbox below the form. Unchecked = Operator (the default).
- Add user — submits the form.

The form is purely additive — it creates an account with the provider tag Password (local). Accounts signing in via OIDC or SAML appear in the table automatically the first time they authenticate; you never type those into this form.

How to create a local user

Open Settings → Users.
Type a Username. Pick something a person will recognize in an audit log — alice over user42, real-name handles over pseudonyms.
Type a Password at least 14 characters long. The form rejects submissions below that floor.
Decide on the role. Leave Admin unchecked for a normal Operator (most accounts). Tick it to grant admin (settings + users
- agent updates + threat feeds + …).
Click Add user.

A green toast confirms User "<username>" created and the new row appears in the table.

Roles in v1

Two roles, both flat:

Admin — can do everything: manage other users, mint and revoke enrollment secrets, set the agent + osquery rollout percentages, configure SSO, edit threat feeds, run fleet-wide hunts without a capability grant.
Operator — can view hosts, alerts, indicators, campaigns, mint their own API keys, edit their own Time & Display preferences, launch hunts within their per-user host cap, run quick hunts, acknowledge alerts.

There is no “read-only” role and no per-resource scoping. If a user needs admin access on a single tenant only, your remedy is to deploy a separate Mimir tenant — the user/role boundary is per-tenant, not per-resource within a tenant.

For fleet-hunt access without full admin, there’s the can_launch_fleet_hunts capability — a finer-grained grant adjacent to the role. Capabilities live on the Capabilities admin page, not this one.

What this panel does NOT do

Several things you’d reasonably expect on a Users page that aren’t here in v1:

No “change role” affordance. A user created as Operator stays Operator. To promote, your operator removes and re-adds them via direct database access; the same is true for demotion.
No “disable user” toggle. A user is either present and active, or absent entirely (which the GUI also can’t do).
No “delete user” button. Removing an account requires direct database intervention by whoever runs the Mimir deployment.
No password reset for someone else. Users change their own passwords from their account page when that flow lands; there’s no admin-initiated reset in v1.

If your team needs any of these flows urgently, the workaround is your sysadmin running SQL against the users table (back up first). This is an explicit GUI gap, not a security feature.

SSO accounts and this panel

If your tenant has SSO configured (OIDC or SAML), users that sign in via the identity provider appear in this table automatically the first time they authenticate — Mimir creates the row at that moment. Two implications:

You don’t mint SSO users here. Permissions live in the IdP. Whoever the IdP grants access to gets a row in this table after their first successful sign-in, not before.
Admin role for SSO users is controlled by the Admin groups field on the SSO config (see Settings → SSO). If the IdP reports the user as a member of one of those groups the first time they sign in, the row lands with Admin; otherwise Operator. The role check runs only at JIT provisioning — subsequent sign-ins read the role straight from the database, so adding or removing a user from an IdP admin group later does NOT retroactively flip their Mimir role. The Single Sign-On page covers this gap in detail.

For account hygiene — provisioning, password rotation, MFA — the IdP is the system of record. Deprovisioning is a separate concern documented on the SSO page: removing a user from the IdP prevents new sign-ins but does not invalidate their existing Mimir session or API keys; that requires direct database intervention by the deployment operator until v1 grows a GUI disable-user affordance.

Troubleshooting

The form rejects my submission with no error toast. The HTML form’s required attributes block submissions with empty Username or Password before the JS handler runs. Check both fields contain text and the password is at least 14 characters.

Failed to create user. Usually a duplicate username. Mimir enforces case-sensitive uniqueness on the users.username column; alice and Alice are different rows. Pick a different value or ask your operator to check for an existing row.

An SSO user signed in but isn’t in the table. A failure at the provisioning step means no row was created. Check Settings → SSO for the provider’s status (Active / Disabled), and check your server logs for the actual SSO error — most often a misconfigured issuer URL or a missing email / groups claim on the assertion.

A user is in the table but can’t sign in. If their provider column says Password, the password is wrong (or they’re typing a password from a different system). For OIDC / SAML, check the IdP side — Mimir trusts the IdP’s authentication result; if the IdP says “no”, Mimir says “no” too.