Sign-in, roles and audit
This page covers how people sign in, what each role can do, how to give users access to individual destinations, the audit log, and notifications. Sign-in Bootstrap administrator. The account set by BMENT_ADMIN_USERNAME and BMENT_ADMIN_PASSWORD signs in with a username (or email) and password. See Deploy the server. Single sign-on (OIDC). Everyone else signs in through an OpenID Connect identity provider, such as Microsoft Entra ID, Google or Keycloak. An account is created the first time a person signs in. Single sign-on doesn't need a license. Every user accepts the end-user license agreement at first sign-in, and again whenever it changes. Add an identity provider Set the External URL under Settings → Security. It's used to build the redirect URIs. Open Settings → OIDC providers and choose + Add provider. Fill in the form: Field Meaning Slug (URL key) Short identifier used in the provider's redirect URI. Kind generic, azure, google or keycloak. Display name and Icon The button shown on the sign-in page. Issuer URL, Client ID, Client secret From the app registration at your identity provider. The secret is stored encrypted. Scopes (space-separated) The scopes to request. Identity claim (account key), Username claim, Group claim Which claims supply the account identity, the username and the user's groups. Tenant ID (azure) For Microsoft Entra ID. Require group membership and Allowed groups (one per line) Only let in members of the listed groups. Enabled Show the provider on the sign-in page. Register the redirect URI that the form shows with your identity provider. Choose Test discovery to check that the server can reach the issuer, then Save. You can add several providers. Each appears as its own button on the sign-in page. By default, the server refuses to contact private or internal network addresses for identity providers, SMTP, syslog and webhooks. To use an identity provider on your internal network, turn on Allow private OIDC issuers under Settings → Security. Roles and destination access There are two roles: Role Can use admin Everything: clients, agent installs, backup schedules, backups, runs, restores, audit and all settings. user The dashboard, their own profile, and only the destinations they've been granted. Map groups to roles under Settings → Role mappings. Enter a Group name, a Role and, optionally, a Provider slug. Mappings are applied every time someone signs in, so your directory stays in charge. A role changed by hand is overwritten at the user's next sign-in. A user who matches no admin mapping gets the user role. [!TIP] Limit admin mappings to your main identity provider by filling in Provider slug. Otherwise a less trusted provider that sends a group with the same name could grant admin access. Grant a destination to a user: on Destinations, choose Grants on a destination, then Grant a new user. Pick the user and any combination of: management (bucket metadata, retention) restore (read backups) write (upload backups) Use Revoke to take a grant away. Sessions and passwords Under Settings → Security: Session lifetime (hours): from 1 to 168 hours (7 days). Applies to new sign-ins. Sessions are held on the server, so they can be ended centrally. Argon2 memory (KiB), Argon2 iterations and Argon2 parallelism: the cost of password hashing (Argon2id). They apply to new password hashes. Existing passwords keep working. Trust forwarded headers: turn this on only behind a reverse proxy (see Deploy the server). Repeated sign-in attempts from one IP address are rate-limited. Audit log Sensitive actions are recorded with who did it, what it affected, the outcome, the IP address and the browser. That includes sign-ins, license agreement acceptance, credential tests, backup runs, restores, client enrollment, kicks and deletions, settings changes and diagnostics downloads. Open Audit to filter events and see each one in full. Under Settings → Audit: Retention: Retention (days) (0 keeps events forever), Max rows (0…
BackupMunk Enterprise documentation