Administration

Users and roles

Create accounts, decide what each role can do, and manage how people sign in.

How access works

Two things decide whether someone can do something. Their roles decide what they are capable of anywhere in DFIRe. The case team decides which cases that capability applies to. A user needs both.

A role is a named set of permissions. A user can hold several, and their permissions are the union of all of them. DFIRe never checks role membership directly. It checks individual permissions, which is why a role you build yourself works exactly like a shipped one.

On each case, a user is a lead investigator, an investigator or a viewer. Leads and investigators can write, viewers can only read. Permissions that grant access to every case, such as viewing or editing all cases, lift the team requirement for their holder.

Two settings tabs cover this area, and each has its own permissions so you can delegate them separately. Settings → User Accounts holds the accounts. Settings → Access Roles holds the roles. For the permission model itself, see Application security.

The user list

Settings → User Accounts stacks two tables. Active accounts sit at the top. Disabled accounts appear below them, dimmed, and only when some exist. Deactivated people stay visible for review without crowding the working roster.

Both tables show the same columns: a profile picture, the name, username and email, and the assigned roles. Each row also carries the time since the last sign-in, which integrations the account links to, and how many API keys it holds. Three badges can appear on a row.

SSO names the identity provider the account authenticates against.
ROOT marks a superuser.
Service marks an API-key-only account that cannot sign in interactively.

Administrators who can change users also see an MFA column. See Seeing who has it.

Creating a user

Choose Add User in Settings → User Accounts and fill in the name, username, email and an initial password. Assign at least one access role. The Account Active toggle controls whether the account can sign in. If you use Slack, you can also enter the person's Slack user ID here.

SSO accounts create themselves. With SSO configured, an account appears on first sign-in, in the default role set for that provider. Review the role afterwards. Turn off Allow new user creation on the provider to stop this.

SSO takes over a matching local account. If someone with a local password account signs in through an identity provider that asserts their email as verified, DFIRe links the two. That account then loses password sign-in permanently, and DFIRe removes multi-factor authentication from it. A provider that does not assert email verification gets the sign-in refused instead of linked. An unverified email would otherwise let someone take over the account. See SSO troubleshooting.

The shipped roles

DFIRe ships four roles. Each builds on the one before it.

Role	What it can do
View Only	Reads the cases it is assigned to, the IOC registry and the Knowledge Base. Changes nothing.
Standard user	Creates cases, works the ones it leads or is assigned to, and claims cases that have no lead. Manages evidence, notes, timers and timelines on those cases.
Team Lead	Everything above, across every case including archived ones. Deletes cases, manages case teams and projects, reads analytics and the whole audit log, and curates the IOC registry.
DFIRe Admin	Everything above, plus subject-matter configuration and user and role management.

DFIRe Admin covers playbooks, runbooks, evidence types, workflow steps, the incident lifecycle, categories and verdicts, reporting templates, compliance timers, webhooks and automation. It does not reach storage, licensing, backups, single sign-on or the integrations, which stay with superusers.

Treat these four as starting points. A superuser can change them, build new roles, or reorganize the permissions completely.

All four shipped roles can read playbook definitions and review history under Settings → Playbooks. The designer is read-only unless the user also has edit rights on that playbook.

Permissions worth knowing about

Most permissions follow the create, view, edit and delete pattern on an object. Three IOC permissions do not, because registry work is not ordinary editing.

Permission	What it allows
`core.manage_indicators`	Curating the registry: bulk operations, publishing, unpublishing, revoking and merging
`core.export_indicators`	Exporting registry and case indicators as CSV or STIX, alongside `core.view_indicator`
`core.import_indicators`	Importing indicators in bulk from CSV, STIX or plain text

Evidence files use the ordinary four permissions on the evidence file object. A role without create can read a case's files but cannot upload. A role without view cannot download. Case assignment still applies on top. See Application security for what each one covers.

Editing roles

Settings → Access Roles is where you decide what a role can do. Pick a role, and choose a second one under Compare with to see the two side by side and spot where they differ.

Permissions are grouped into collapsible sections, one per object, such as cases, evidence, playbooks and indicators. Each header summarizes what the role has: create, edit, delete and view, plus manage, export or import where the object uses them. Expand a section to toggle individual permissions. There is no save step: a permission applies the moment you tick it, and reaches every user in the role.

New role adds an empty role for you to grant permissions to. Rename and Delete act on the selected role. A role that still has members cannot be deleted, so reassign its users first.

You can grant a permission you do not hold yourself, with one group of exceptions. These are global case access, archived-case access, tenant configuration, user, role and permission management, API key administration, webhook configuration and Slack user mapping. Only someone who already holds one of them can grant it. The editor hides those rows from everyone else and says that some capabilities are hidden. If such a grant reaches the server anyway, DFIRe refuses it and shows the reason. That is what stops a delegated editor from widening their own access.

Restoring the defaults

Superusers can return the four shipped roles to their original permissions with Reset default roles. A default role that was renamed or deleted comes back under its original name. Members stay in place, and roles you created yourself are never touched. Use it after experimenting, or after an upgrade, to pick up the current recommended baseline.

Delegating one area

Most settings areas can go to a role without full administrator access. Create a role, grant it only that area's permissions, and assign it. The user reaches that part of Settings and nothing else. Because a user can hold several roles, a narrow role like this also layers on top of a broader one. Superuser-only areas cannot be delegated.

Editing a user

Open a user from the list to change their name, email, username and roles, to set a new password, or to toggle Account Active. At least one role is required. You can also link or unlink their Slack ID.

Service account converts the account to API-key-only. This signs it out of every browser session and deletes every API key it holds, and only a superuser can reverse it. A superuser account cannot become a service account, so the switch is absent unless the account already carries the status. See API access.

Setting someone else's password revokes their keys and sessions. The user's sessions end and every enabled API key on the account is disabled. They sign in again, and re-enable or replace whatever their integrations depended on. Changing your own password ends your sessions but leaves your keys alone. Send the new password over a channel you trust, and ask them to change it once they are in.

SSO accounts

An SSO account carries a badge naming its provider, and its password fields are hidden.

The identity provider owns the email, first name, last name and profile picture, and refreshes all four on every sign-in. A provider that sends a phone number refreshes that too. Editing any of them in DFIRe therefore lasts until the next sign-in. Change them at the provider instead. Roles, account status and Slack ID are DFIRe's own and survive an SSO sign-in untouched.

Disabling an account

Open the user, turn off Account Active, and save. The account can no longer sign in by any method, its audit trail and case history stay intact, and it moves to the disabled table.

Accounts cannot be deleted, only disabled. Deletion would free the user ID for reuse and break the audit trail, so DFIRe refuses it.

The last active superuser cannot be deactivated. DFIRe refuses, because nobody would be left to administer the installation. Create or reactivate another superuser first.

Unlinking an SSO identity

DFIRe matches an SSO identity by the stable identifier the provider issues, not by email. Renaming someone's email in DFIRe therefore does not break the link, and the next sign-in overwrites the rename with the provider's value.

Unlinking lets the same person come back as a brand-new account on their next SSO sign-in. The old case history stays attached to the old account. It works only on a deactivated account, so it takes two passes:

Edit the user, turn off Account Active, and save. The dialog closes.
Edit the same user again. Unlink SSO now appears beside the SSO badge.
Select it and confirm.

Unlinking detaches the identity and records the change in the audit log. It also rewrites the account's email to [email protected], so no email fallback can reattach it. The account, its history and its audit trail all stay. The person's next sign-in provisions a fresh account under the provider's default role.

Which one do you want? Deactivate when someone should lose access. Unlink as well when they should return as a clean account, separate from the old one.

Sessions

Each user manages their own sessions in My Profile. Current Session shows the one in front of them. Other Sessions lists the rest, with a control to revoke any single one and Revoke all other sessions to clear them together.

An administrator can end every session an account holds with Force logout, from the user's row or the edit dialog. Use it when credentials may be compromised, when someone leaves, or to make a role change bite immediately. The user signs in again on every device. A System Root account is the exception: only another System Root user can end its sessions, and DFIRe hides the control from everyone else.

Signing in

DFIRe accepts two kinds of sign-in.

Single sign-on, through your organization's OIDC provider. The provider decides what a sign-in requires, so any multi-factor step it enforces applies here. DFIRe never asks an SSO account for a code of its own. This is the recommended method in production.
Local password, for initial setup and for environments with no identity provider. These accounts can require a code from an authenticator app after the password.

Password rules

A local password must be at least 12 characters. It cannot be entirely numeric, cannot be a commonly used password, and cannot closely resemble the account's own details.

Users change their own password from the profile menu, entering the current one and the new one. Administrators set a password by editing the user, which carries the consequences described above.

Multi-factor authentication

An account that signs in with a password can require a code from an authenticator app afterwards. DFIRe uses time-based one-time passwords, so any standard app works. Each user turns it on for their own account, and a superuser can require it across the installation.

Setting it up

Open your profile
Choose My Profile from the user menu and find Multi-Factor Authentication.
Confirm your password
Choose Set up MFA and enter your current password.
Add DFIRe to your authenticator app
Scan the code on screen, or type the setup key beside it if you cannot scan.
Enter a code and choose Turn on
The code proves the app is set up correctly. DFIRe signs your other sessions out here, so you will sign in again elsewhere.
Save your recovery codes
DFIRe shows ten recovery codes once and never again. Keep them somewhere you can reach without DFIRe.

Signing in with it

After the password, DFIRe asks for a code. A wrong code leaves the sign-in open for another try, but each failure makes the authenticator wait longer before it accepts the next one, and reaches the audit log. DFIRe also limits how fast attempts can arrive. The step expires five minutes after DFIRe accepts your password, and you start again from the password.

Without your authenticator app, choose Use a recovery code and enter one you saved.

Recovery codes

A recovery code signs you in once and is then spent. The sign-in screen stops offering them once you have none left, so replace them before that.

Replace recovery codes in your profile issues ten fresh ones and cancels the old set. It asks for your password and a code from your authenticator app. A recovery code is not accepted here, because one code would otherwise produce ten more.

Turning it off

Turn off asks for your password and one code, from either the app or your recovery codes. DFIRe signs your other sessions out.

What single sign-on does to it

Linking an account to an identity provider disables password sign-in, and multi-factor authentication goes with it. DFIRe removes the registered authenticator and the recovery codes, signs the other sessions out, and records the removal. The provider decides what sign-in requires from then on.

If a user loses both the app and the codes

Nobody can turn MFA off without a code, so this needs an administrator. Open the user in Settings → User Accounts, choose Edit user, then Reset MFA. This needs the permission to change users, and it does not work on a superuser account unless you are one.

A reset signs the user out everywhere and lets them back in with their password alone until they set MFA up again. Every enrolment, replacement, removal and administrator reset reaches the audit log.

Requiring it for everyone

A superuser can turn on Require multi-factor authentication in Settings → User Accounts. Password accounts then have to set up an authenticator app. SSO accounts are outside it, because their provider decides what their sign-in requires. So are service accounts, which use an API key and never a password.

Setting MFA up takes a sign-in, so the requirement does not lock everyone out the moment you enable it. Sign-ins allowed before setup is how many times an account with no authenticator can still get in with its password. Each of those sign-ins says how many remain and where to set MFA up. After the last one DFIRe refuses the password, and the user needs an administrator.

Changing this setting needs MFA on your own account, in both directions. Set it up in My Profile, sign in with a code, and the setting becomes available. The requirement never refuses a superuser a sign-in, so enabling it and then losing your authenticator cannot shut you out of the installation.

An account gets its full allowance back whenever it sets MFA up, turns it off, or an administrator resets it. To let a blocked user in without changing anything else, open them in Settings → User Accounts, choose Edit user, then Restore sign-ins. This needs the permission to change users, does not work on a superuser account unless you are one, and reaches the audit log.

Seeing who has it

The MFA column in Settings → User Accounts is visible to administrators who can change users. A tick means the account has an authenticator registered and a cross means it does not. A dash means the question does not apply, which covers service accounts and SSO accounts. Opening a user shows the same state in words, along with how many sign-ins remain while the requirement is on.

API keys are outside it

An API key is a credential in its own right and multi-factor authentication does not cover it. See API access.

Superusers

A superuser carries the ROOT badge and bypasses every permission check. The status is set during installation or from the command line, and the web interface cannot grant or revoke it. Administrators who are not superusers cannot edit a superuser account.

A superuser must have an email address, so the person who administers the installation stays reachable. DFIRe refuses to clear it, and flags a superuser that has none in the user list. A superuser also cannot be a service account, because such an account signs in with an API key and never with a password.

Keep the number of superusers small. Everything else can be delegated through roles.

← Timestamp formats Single sign-on →