Finlay.worksBareBones Ticketing manual

Configure

Admin Settings And Step-Up

What the Admin Settings hub contains, which surfaces require step-up verification, and how to keep a local break-glass administrator.

RC2 approved for evaluation Status: release-candidate Audience: System Administrator Source: c4b4d41

Admin Settings And Step-Up

Admin Settings is the entry point for product configuration. This page covers opening the hub, completing step-up verification, and keeping a local administrator account that can still sign in when your directory or identity provider is down.

Who can open Admin Settings

You need a SystemAdmin grant, held directly or through a group. A department Admin mapping is not enough. See Users and groups for how grants are made.

Opening the hub does not widen your access. Each workspace you open from it checks your SystemAdmin grant again.

What step-up is

Step-up is a re-check of your identity inside a session you are already signed in to. You enter your password again, or complete a fresh sign-on with your identity provider. BareBones Ticketing then unlocks sensitive surfaces for a limited time, after which you are asked again.

Step-up proves you are still the person at the keyboard. It grants nothing. It does not give you SystemAdmin, department access, or ticket access, and it does not approve a change.

Which surfaces require step-up

Three patterns exist. The surface tells you which one applies.

The Admin Settings hub itself loads without step-up, but before you verify it shows only the step-up form and the message "Step-up verification is required before sensitive admin changes." — none of its 31 destination workspaces are listed. Treat the hub as readable but empty until step-up succeeds.

Whole page gated. The page shows no content until step-up succeeds — reading requires step-up. This covers Tenant Administration; Department Administration and department detail; Department access administration; User Administration and user detail; Group Administration and group detail; System Admin Access; Directory and identity integrations and each integration workspace; External Identity Administration and each identity detail; Demo Data; audit; redactions; mail delivery; services; service categories; service and project custom fields; tags; workflows; status definitions; SLA policies; business calendars; project role mappings; import operations; and database connection.

Read open, save gated. The page opens and shows the current state without step-up, but saving is refused until step-up succeeds, behind a banner that says review is open while saving still requires step-up. This covers Product License, Web Access and Session Security, Storage and Key Continuity, and HTTPS and Certificates.

No step-up. The page needs SystemAdmin only: Admin Settings itself, About BareBonesTicketing, and System Diagnostics.

Application programming interface (API) paths behind these surfaces re-check step-up independently. Passing the page gate once does not carry a later save.

Open the hub

  1. Sign in with the administrator identity you intend to use.
  2. Open Admin Settings.
  3. Read the current unlock state. It reports checking, step-up required, or unlocked.
  4. If step-up is required, complete it before opening a workspace.

Complete step-up with a local or LDAP password

Use this path when you signed in with a product-local password or through Lightweight Directory Access Protocol (LDAP)/Active Directory.

  1. Leave the prefilled username alone. The form arrives holding the username stored on your account, which is the form step-up accepts.
  2. Enter that identity's current password.
  3. Select Verify credentials once.
  4. Confirm the hub reports sensitive work as unlocked, and note the expiry time if one is shown.

Step-up re-checks the account you are already signed in as. It accepts that account's stored username, or the ticket email contact address configured on it, and nothing else. You cannot verify as a different person here, and typing somebody else's username does not select them.

The prefilled value comes from the account record rather than from the name you happened to sign in with, so on a directory account it is already the form that works. If you clear it and type something the account does not hold, the refusal names the problem: "The username does not match the signed-in account. Use this account's username or configured ticket email contact address." A wrong password still reads "Credential verification failed." The two are different messages, so read which one you got before changing anything.

The step-up window is 15 minutes. When it lapses, a gated workspace shows Step-Up Verification Required with an Open Admin Settings link rather than an inline form, so you return to the hub to verify again.

The password is not written to audit records.

Complete step-up with organization SSO

Use this path when you signed in through Security Assertion Markup Language (SAML) single sign-on (SSO).

  1. Confirm the hub shows your organization SSO identity.
  2. Select Verify with organization SSO.
  3. Complete the sign-on flow at your identity provider.
  4. Return through the product callback.
  5. Confirm the hub reports sensitive work as unlocked.

A session that is stale, missing, mismatched, or federated by a method other than SAML is refused. Raw assertions are not accepted in place of a fresh sign-on.

The same identity rule holds wherever the product asks you to re-verify inside a task rather than on the hub — a regulated approval decision, a governed workflow transition signature, a queue bulk operation, project bulk staffing, and the second approval on a redaction reveal. Each of those asks for the account you are signed in as, prefilled the same way, and offers Refresh organization SSO instead of a password box where the account signs in through SSO.

How long the unlock lasts

  • The hub displays the window. Do not time it yourself.
  • The expiry is written in your tenant's display time zone and names it, as in 16:57 Europe/London (UTC+01:00). The date beside it follows the tenant's chosen date format. This is not server time and not necessarily your own local time, so read the zone rather than assuming it.
  • The unlock belongs to one user in one session.
  • Restarting the application process clears it.
  • Step-up state is held in application memory, not in a shared cache. A request routed to a second application instance does not inherit it. Run privileged work against a single instance, or use sticky sessions.

When the window expires, verify again before continuing. An expired window does not partly authorize a change you already submitted.

Keep a break-glass local administrator

A break-glass administrator is an active local user account that holds SystemAdmin. It exists so you can still sign in when LDAP or SAML is unavailable. It is an ordinary account kept in reserve, not a separate override mode: it signs in normally and still completes step-up.

An administrator whose account comes from LDAP or SAML does not count. The recovery path must be local.

Check the current path

  1. Open System Admin Access.
  2. Review the direct grants, group grants, and local break-glass summaries.
  3. Identify which active local user, or which membership of an active local group, supplies the recovery path today.

Replace one before retiring it

  1. Create the replacement local account and grant it SystemAdmin. See Users and groups.
  2. Sign in as the replacement and complete step-up to confirm it works.
  3. Disable the grant you are retiring.
  4. Re-open System Admin Access and confirm a local path still remains.

The last-local-admin rule

BareBones Ticketing refuses any change that would leave no active local SystemAdmin path. This covers disabling the user, disabling the group, removing the supporting group membership, and removing the grant itself. The refusal is recorded as a blocked operation in the audit trail.

The rule only counts paths. It does not check that anyone knows the password. Track credential custody separately.

Do not test break-glass by shutting off the identity provider or deleting accounts in a production installation.

If it does not work

  • The hub says you lack SystemAdmin. Step-up cannot create the grant. Use an already-authorized administrator or the local recovery account.
  • Credential or SSO verification fails. The surface stays locked. Read which refusal you got: a username that does not match the signed-in account says so, and anything else reads "Credential verification failed." Resolve the identity source. Do not retry with a different account.
  • You were unlocked and now you are not. The window expired, the process restarted, or your request reached a different instance. Verify again and re-read the current state of the record before editing.
  • A change is refused by the last-local-admin rule. Leave it refused. Establish another local path first.