Users & Access Control¶
Access control is module-based and enforced on the server. The navigation hides what you cannot use, but the hiding is a courtesy — the API refuses it either way.
Three levels per module¶
Every module is one of three levels for a role:
| Level | Meaning |
|---|---|
| none | Invisible. The navigation entry is not rendered and the API returns 403. |
| read | View, query and export. Every write is refused. |
| write | Full access. |
Parent-child fallback¶
Sub-modules inherit their parent's level unless they have an explicit grant of their own. This is what stops a product upgrade from breaking your roles: when a new sub-page is added, existing roles inherit the parent's level instead of silently losing access to something they had.
Built-in roles¶
| Role | Intent |
|---|---|
| Administrator | Everything, including user and role management |
| Operations | Day-to-day: backups, config push, bastion access |
| Viewer | Dashboard, visualization, alerts, DCIM and IPAM — read-only |
| Guest | Dashboard only. New users created by LDAP / SSO first login land here. |
Built-in role codes cannot be renamed or deleted, because parts of the product test for them. Their permissions can be edited, and once you edit one your version wins — later upgrades will not put it back.
Custom roles¶
Create as many roles as you need and set each module's level explicitly. A common pattern is a regional operations role: write on devices and backups, restricted to specific device groups, no access to system settings.
Users¶
Settings → User management: username, display name, email, phone, source, role, status and creation date. Users can be created locally or arrive from LDAP / OIDC. Bulk edit changes role or status for a selection.
Self-service is separate from administration: any signed-in user can change their own password and manage their own two-factor device without needing permission on the users module.
Authentication¶
Settings → Authentication settings:
- LDAP — bind against your directory; first login creates a local user record with the default role.
- Enterprise SSO (OIDC) — single sign-on, with a configurable button label.
- Two-factor (TOTP) — standard authenticator apps, with recovery codes.
Stopping brute force¶
Three complementary controls, all under Settings → General → Security policy, best used together:
- Login-failure lockout — after N failures nobody gets in for a while. Blunt but effective, and it cuts both ways: someone else can use it to lock you out of your own account, so do not set the threshold too low.
- Login CAPTCHA (slider puzzle) — off by default. Require it after N failed attempts (2 out of the box) or on every sign-in (set the count to 0). It is checked before the password, so a script never even gets to try a password — and it locks nobody out, a real person just drags the slider and carries on.
- Password complexity — minimum length and character classes.
It stops bulk, unattended credential stuffing by raising the cost of one attempt from milliseconds to hundreds of milliseconds, which is what makes a 100k-word dictionary impractical. It does not stop a targeted attacker who can write image processing — that is what two-factor and passkeys are for. The puzzle is generated on your own server and no third-party service is involved.
Audit¶
Writes are audited: who, when, which object, from which IP and which authentication source. Denied writes are logged too — an account repeatedly bumping into permission errors is worth a conversation either way.