User Management

Manage user accounts, assign roles, and control access to DFIRe.

Overview

User management in DFIRe is accessed via Settings → User Accounts. The interface has two tabs:

  • Users: Create, edit, and manage user accounts.
  • Role Editor: Configure permissions for each role.

For detailed information about the Role Editor and permission configuration, see Application Security.

The Users tab shows active accounts in the main list and a separate "Disabled accounts" list below it, so deactivated users do not crowd the working roster while remaining visible for review and re-enablement.

Access Control

DFIRe uses a two-tier access control system:

1. Role-Based Permissions

Each user is assigned a role that determines their system-wide capabilities:

  • Can the user create new cases?
  • Can the user access system settings?
  • Can the user view all cases regardless of assignment?

2. Case-Level Access

For each case, access is determined by team assignment:

  • Lead Investigator: Full control of the case
  • Investigator: Read/write access to case content
  • Viewer: Read-only access

A user must have both the role permission to perform an action and be assigned to the case (unless they have "View/Edit All Cases" permission).

Creating Users

  1. Navigate to Settings > User Accounts

    You need the edit_tenant permission to manage users. This permission is included in the default DFIRe Admin role, but can be assigned to any custom role via the Role Editor.

  2. Click "Add User"
  3. Fill in User Details
    • First Name / Last Name: Display name
    • Username: Unique identifier for login
    • Email: Used for notifications
    • Role: Select the user's role
    • Password: Set the initial password
  4. Configure Account Status

    The "Account Active" toggle determines whether the user can log in.

  5. Optional: Link Slack Account

    Enter the user's Slack User ID if you use Slack integration. Find this in Slack by clicking the user's profile > More > Copy member ID.

  6. Click "Save User"

SSO users: When SSO is configured, accounts are created automatically on first sign-in (unless "Allow new user creation" has been turned off for that provider). The new user is placed in the default role configured for the provider; you may want to adjust the role afterwards. If a person with an existing local username/password account signs in via SSO and the identity provider asserts the email as verified, the local account is linked to the SSO identity and password-based login is permanently disabled on it. If the identity provider does not assert email verification, the sign-in is refused — see SSO troubleshooting.

Preconfigured Roles

DFIRe includes these default roles:

Role Description
View Only Read-only access to cases they're assigned to
Standard user Create and manage cases they're assigned to, add evidence and notes
Team Lead Standard user permissions plus view/edit all cases and manage teams
DFIRe Admin Full system access including user management, settings, and audit logs

These are default template roles included with DFIRe. The superuser is free to modify them, create new roles, or reorganize permissions entirely using the Role Editor. DFIRe never checks group membership directly — it only checks individual atomic permissions as assigned through the Role Editor. See Application Security for details.

IOC-Related Permissions

The following permissions control access to IOC features and can be assigned via the Role Editor:

Permission Effect
core.manage_indicators Create, edit, classify, publish, and revoke indicators
core.export_indicators Export indicators in CSV, STIX, or plaintext format
core.import_indicators Bulk import indicators from CSV or STIX files
core.manage_taxii Configure TAXII 2.1 server settings, collections, and API keys

Editing Users

Click the edit button next to any user to modify their account:

  • Update profile information: Name, email, username
  • Change role: Select a different role from the dropdown
  • Reset password: Enter a new password (leave blank to keep current)
  • Enable/disable account: Toggle the "Account Active" switch
  • Update Slack ID: Link or unlink Slack integration

SSO users

Users who authenticate via SSO are marked with an SSO badge showing their identity provider. For SSO users:

  • Password fields are hidden — authentication is handled by the identity provider.
  • The user's email, first name, last name, and profile picture are refreshed from the identity provider on every sign-in. Editing those fields directly on the DFIRe user record is therefore temporary; change them at the identity provider for a permanent update.
  • Role, account status, phone number, and Slack ID are local to DFIRe and are not overwritten by SSO sign-ins.
  • An Unlink SSO action is available on the SSO badge — see "Unlinking SSO identities" below.

Disabling users

When a user should no longer have access:

  1. Go to Settings → User Accounts.
  2. Click the edit button for the user.
  3. Turn off Account Active.
  4. Click Save User.

Disabling a user:

  • Prevents them from signing in by any method (local password or SSO).
  • Preserves their audit trail and case history.
  • Moves them into the "Disabled accounts" list below the active users.
  • Does not delete any data.

Accounts cannot be deleted — only disabled. This prevents user ID reuse and preserves the integrity of the audit trail and case history. Disabled accounts remain in the system but cannot be used to sign in.

Last active superuser cannot be deactivated. If you are the only remaining active superuser, the system refuses to turn off your Account Active toggle — otherwise no one would be able to sign in to manage the system. To deactivate yourself, first create or reactivate another superuser, then come back and deactivate the original account.

Unlinking SSO identities

SSO identities are matched by the stable identifier (sub claim) the identity provider issues, not by email. That means renaming a user's email in DFIRe does not break the link — the next SSO sign-in still resolves to the same DFIRe account and the renamed email is overwritten by the IdP-issued value.

To let someone re-register as a fresh DFIRe account on their next SSO sign-in — for example, when their role has changed and old case history should stay attached to the previous account — use Unlink SSO. The flow is two stages, because the action is only available on a deactivated account:

  1. Edit the user, turn off Account Active, and click Save User. The edit dialog closes.
  2. Edit the same user again. The SSO badge in the dialog header now shows an Unlink SSO link next to it.
  3. Click Unlink SSO and confirm.

Unlinking:

  • Detaches the OIDC identity from the account so a future SSO sign-in is no longer routed to it.
  • Rewrites the account's email to username@unlinked.local so the email-fallback match path also cannot reattach it.
  • Leaves the account itself, its history, and its audit trail intact.
  • Is recorded in the audit log.

Once the old account is unlinked, the same person signing in via SSO is treated as a brand-new user — provisioned according to the provider's "Allow new user creation" setting, with the provider's default role. The old account remains in the system, deactivated, with its case history intact.

Pick the right tool: Deactivate the account when the person should no longer have access (and may never come back). Unlink the SSO identity when the person should come back as a clean new account, separate from their old one. Deactivate is required first; unlink is the second step.

Force Logout

Administrators can immediately terminate all of a user's active sessions:

  1. Go to Settings > User Accounts
  2. Click the edit button for the user
  3. Click "Force Logout"
  4. Confirm the action

This is useful when:

  • A user's credentials may have been compromised
  • An employee is leaving and you need immediate access revocation
  • You've changed a user's role and want it to take effect immediately

The user will need to log in again on all devices.

User list

The Users tab is split into two stacked tables:

  • Active accounts at the top — the people who can sign in today.
  • Disabled accounts below, shown only if any deactivated accounts exist. Rendered in a slightly dimmed style so the working roster reads cleanly while deactivated accounts remain visible for review or reactivation.

Both tables show the same columns:

  • Profile picture: From the SSO provider, locally uploaded, or an initials placeholder.
  • Name and username: With email address.
  • Status badges:
    • SSO badge — Shows the identity provider (Google, Microsoft, etc.).
    • ROOT badge — Superuser with full system access.
    • Service badge — API-key-only account; interactive sign-in is disabled.
  • Role: The user's assigned role.
  • Last login: Time since the user last signed in.
  • Integrations: Whether Slack and/or Jira accounts are linked.
  • API keys: Count of personal API keys the user has issued.

Authentication methods

DFIRe supports two authentication methods:

  • SSO (recommended for production): Passwordless authentication via your organization's OIDC identity provider (Google Workspace, Microsoft Entra ID, Okta, and so on). SSO is the primary method for production use as it leverages your organization's MFA and security policies.
  • Local password login: Username and password authentication. Provided as a convenience for initial setup and to support air-gapped environments without access to an identity provider. Password-based login does not support MFA.

Security: When a local-password user signs in via SSO and the identity provider asserts a verified email matching the account's email, the account is linked to the SSO identity and password-based login is permanently disabled on it. If the identity provider does not assert email verification, the sign-in is refused — the local account is not linked, to prevent account takeover through an identity provider that does not enforce email ownership.

Password Policy

For local accounts, DFIRe enforces password requirements via Django's built-in validation:

  • Minimum 12 characters
  • Cannot be too similar to personal information
  • Cannot be a commonly used password
  • Cannot be entirely numeric

Password Reset

Users with local accounts (non-SSO) can reset their own password:

  1. Click on profile menu in the top navigation
  2. Select "Change Password"
  3. Enter current password and new password
  4. Click "Change Password" to save

Administrators can also set a new password for a user from Settings > User Accounts by editing the user and entering a new password in the password field. The user is required to change it again on their next login. There is no separate "reset" action — password changes happen inline in the user edit form.

Superusers

Superusers (shown with a "ROOT" badge) have unrestricted access to the entire system, bypassing all permission checks. Superuser status:

  • Is set during initial installation or via command line
  • Cannot be granted or revoked through the web interface
  • Should be limited to system administrators only

Non-superuser administrators cannot edit superuser accounts.