Accounts, groups, and role separation

Every account on the OPNsense firewall is a potential path to the keys of the estate. The built-in user and group model lets the operator grant exactly the access each operator needs and no more. For a single-firewall, small-team estate the built-in model is enough. For multi-firewall estates with HR-managed identity, the model extends to LDAP, RADIUS, or SAML.

This lesson covers the built-in user and group model, the privilege separation patterns it supports, the offboarding discipline that prevents stale accounts, and the integration points where external identity makes sense.

The built-in model

OPNsense has two default accounts: root and admin. Both have full administrative access. The admin account exists as a renaming of root for environments where “root” is reserved or discouraged; the privileges are identical.

The operator adds additional accounts under System → Access → Users. Each account has:

• A username (must be unique).
• A password or, preferably, key-based SSH plus TOTP.
• A set of groups the account belongs to.
• An expiry date (optional but recommended for contractors and temporary access).
• A descriptive certificate (optional, for client-cert authentication).

Groups are defined under System → Access → Groups. Each group has a name, a description, and a set of privileges. The privileges map to specific OPNsense GUI pages and API endpoints. Examples of privilege names:

• Firewall: Rules: edit — can edit firewall rules.
• Firewall: Aliases: edit — can edit aliases.
• Services: Unbound DNS: edit — can edit Unbound configuration.
• System: User Manager: View — can view user manager.
• Diagnostics: command — can run diagnostics commands.

A user inherits the union of privileges from all groups they belong to. The privilege model is additive — there is no “deny” privilege that overrides an allow. The design is that access is granted explicitly, never assumed.

Common privilege-separated groups

Three groups cover most production estates.

Read-only auditors

A group with privileges that allow viewing every page but editing none. The privileges are the “View” variants of every section:

• Firewall: Rules: View
• Firewall: Aliases: View
• Services: Unbound DNS: View
• System: Status: View
• Diagnostics: View

This group is for auditors, security reviewers, and junior operators who need to see the configuration without changing it. Read-only access still grants visibility into credentials, certificates, and API keys — be careful with delegation.

Diagnostics operators

A group that can run diagnostics and view most pages but cannot edit firewall rules or system settings. The privileges:

• Diagnostics: command (run shell commands via the GUI diagnostics page).
• Diagnostics: View (view system logs, packet capture, states).
• All read-only privileges.

This group is for operators who need to investigate incidents without making configuration changes. The Diagnostics: command privilege is the most powerful — it allows running arbitrary shell commands as root via the GUI. Grant it sparingly.

Full administrators

A group with all privileges. This is the default for the root account and for senior operators. The group has the same privileges as the root account.

$ pfctl -s rules -R 87 2>/dev/null; sockstat -l -P tcp | grep ':443 '

@87 pass in quick on igb0 inet proto tcp from 192.0.2.0/24 to any port = https
root     nginx      1234  7  tcp4   10.255.100.1:443     *:*

Offboarding

The offboarding discipline is to disable accounts when access should be revoked. Three triggers:

1. Operator departure. The account is disabled or deleted on the operator last day.
2. Role change. The operator moves to a role that no longer requires firewall access. The account is disabled.
3. Lost credentials. The operator device is lost or the password is compromised. The account is disabled immediately.

The disable flow:

1. Disable. Under System → Access → Users, edit the user and check the “Disabled” box. Apply.
2. Verify. Confirm the user cannot log in (try with the known credentials from a test workstation).
3. Audit. Review the user recent activity (auth log, audit log) for signs of compromise.
4. Delete (optional). After the verification and audit, delete the account. Deletion is irreversible; disable is reversible. Production convention is to disable and keep for a period (e.g. 30 days) before deleting, in case the offboarding was premature.

The audit trail for offboarding should be the same regardless of trigger:

• A ticket with the request, the approver, and the operator notified.
• The timestamp of the disable action.
• The result of the verification step (login attempt refused).
• The audit log review summary.

When to integrate external identity

For a single firewall with a small team, the built-in user model is sufficient. For multi-firewall estates with HR-driven identity, the model needs to extend to an external identity provider. The trigger points:

More than three firewalls

When the operator count grows beyond what is comfortable to manage on every firewall individually, central identity pays for itself. The operator adds the user once on the central service; the firewall pulls the user list at authentication time.

HR-driven onboarding and offboarding

If the operator identity lifecycle is managed by HR (joiner, mover, leaver flows), the firewall should be tied to the same identity source. When HR disables the operator central account, the firewall access is disabled automatically.

Multi-application estate

If the operators also use other systems (VPN, Wi-Fi, internal applications) that share the same identity, centralising the firewall auth on the same source means operators have one identity, one MFA enrolment, and one offboarding flow.

Compliance requirements

Some compliance regimes (PCI-DSS, SOC 2, ISO 27001) require centralised identity management and audit trails that the built-in model cannot provide.

The integration options OPNsense supports:

• LDAP/Active Directory. OPNsense queries an LDAP server for user attributes and group membership. The os-ldap plugin handles the integration. The firewall becomes an LDAP client.
• RADIUS. OPNsense delegates authentication to a RADIUS server. The RADIUS server can in turn delegate to LDAP or another backend. This is the pattern when MFA is centralised via freeRADIUS.
• SAML. OPNsense does not have first-class SAML support in the core; integration requires a custom plugin or a SAML-to- RADIUS bridge (e.g. privacyIDEA).

Production patterns

Three patterns make the user model manageable in production.

Quarterly account review

Every quarter, the security team reviews every account on every firewall. The review produces a list of accounts with: the username, the date of last login, the assigned groups, the operator, and the status (active, justified, stale, unknown). Stale accounts are disabled in the review.

Group naming convention

Group names that describe the role, not the person. Examples: fw-readonly, fw-diagnostics, fw-admins. The group assignment is the role. When the role changes, the group membership changes; the group itself is stable.

Documented onboarding and offboarding runbook

The steps to add a new operator and the steps to remove an operator are documented, reviewed, and tested. The runbook includes the account disable verification, the audit log review, and the offboarding ticket closure.

Summary

• The built-in user and group model supports privilege separation through additive privileges.
• Three groups cover most estates: read-only auditors, diagnostics operators, full administrators.
• Offboarding: disable first, verify, audit, then delete (or keep disabled for a period).
• External identity (LDAP, RADIUS, SAML) is the right pattern for multi-firewall estates with HR-driven identity.
• Quarterly account reviews catch stale accounts that are the top compromise vector.