Users And Groups

Every user account has one authoritative identity source. Groups carry product access. SystemAdmin is granted explicitly, never inherited from a directory or a claim. This page covers all three.

Before you start

• You need SystemAdmin and a satisfied step-up. User Administration, Group Administration, and System Admin Access are whole-page gated. See Admin Settings and step-up.
• Know each person's authoritative source before you create anything.

Identity sources

Do not create a local account that duplicates a directory identity. Two records for one person is the failure this table exists to prevent.

CustomerPortalSso users are managed by the provider. Do not pre-provision them, add them to internal groups, or reset their password.

Create a local user

1. Open User Administration and review User roster.
2. Filter by source and status to confirm the person does not already exist.
3. Select Add local user.
4. Enter Username, Display name, and Initial password. Add a Ticket-email contact if the person should receive ticket mail.
5. Save once.
6. Open User Details and confirm Overview, Access, Password, Memberships, and Ticket email.

Send the initial password through a private channel. Do not record it in a ticket, a change record, or a chat message.

Pre-provision a SAML user

Do this when you want the account, its groups, and its access ready before the person's first sign-on.

1. Open User Administration and select Pre-provision SAML user.
2. Enter the Mapped SAML subject, exactly as your identity provider sends it, and a Display name. Add a Ticket-email contact if needed.
3. Save once.

No local password is created. Sign-in remains with the identity provider.

Create a local group

1. Open Group Administration.
2. Review the Local, LDAP, active, and inactive filters.
3. Select Create local group and enter the group name.
4. Save once, then open Group Details.
5. Add active users. Local, LDAP, and SAML users can all be members of a local group.
6. Confirm each membership.

Adding a member who is already in the group changes nothing. Removing one who is not in the group changes nothing. Neither is an error.

An inactive user or an inactive group cannot take a membership change.

LDAP group membership is read-only. It comes from synchronization and you cannot edit it here. See Directory and LDAP.

Before removing a membership, check what the group carries: department access, and possibly a SystemAdmin group grant.

Grant SystemAdmin

SystemAdmin comes from exactly one place: an explicit active grant recorded in System Admin Access. Department Admin, directory group membership, and SAML claims do not produce it on their own.

1. Open System Admin Access.
2. Review Active grant roster, covering Direct user grants, Group grants, and Local break-glass paths.
3. Check the target is active. For a group, check who is in it — every member receives the grant.
4. Select Grant new reach.
5. Choose one:
   • Grant direct System Admin for one user.
   • Grant via group for one group.
6. Save once.
7. Confirm the roster shows the new grant and that a local break-glass path still exists.

Use a direct grant for a named individual. Use a group grant when membership of that group is the thing that should decide administrator reach.

An active local group, or an LDAP group that sync has created in the product, can supply SystemAdmin only after you record a group grant against it. A SAML group reaches SystemAdmin only through a mapping into a local group, under the guardrails in SAML and two-factor.

Remove a grant

1. Open System Admin Access and locate the exact grant.
2. Read Supports local break-glass and the inherited-member list.
3. Confirm another active local SystemAdmin path exists.
4. Arm the removal control, then confirm.
5. Re-check the effective administrator list.

Removal disables the grant. The record stays for history.

The last-local-admin rule applies here. See Admin Settings and step-up.

Disable and reactivate a user

1. Open User Administration and open the user.
2. Check whether the user holds SystemAdmin, directly or through a group.
3. Check whether disabling the user removes department access other people depend on.
4. Select the disable control once.
5. Confirm the resulting state on the user record.

Use the same control to reactivate.

Disabling a directory account switches it off only inside BareBones Ticketing. For an LDAP or SAML user the disable control is scoped to this product — the underlying directory or identity-provider account stays active at its source, and the user record says so: "This disables the account only in BareBones Ticketing. The LDAP account remains active in the directory source." To stop someone signing in at all, disable them at the directory as well.

Disabling a group has the same reach: it can remove department access and SystemAdmin from everyone in it. The same directory scoping applies — disabling an LDAP group switches it off only in BareBones Ticketing; the directory group stays authoritative and read-only here.

The worker limit

Your product license permits a number of workers. A worker is an active internal user with department access at any level — View counts, even though View alone cannot take ticket work — or an active SystemAdmin grant. See Editions.

A membership change or a grant is refused when applying it would take the count over the licensed worker limit. The check runs before the change is written, so nothing is saved. Reconcile licensed worker capacity, then retry. Do not work around the check. See Limits and scope.

Clear a lost authenticator

Do this for an active local or LDAP user whose authenticator app is gone.

1. Verify the person's identity through an approved private process.
2. Open User Administration, then the user's Access section.
3. Select Clear authenticator enrollment once.
4. Confirm the enrollment is cleared.
5. Have the person sign in with their password and enrol again.

Clearing enrollment removes the enrollment and nothing else. It does not reset the password and does not let anyone past primary sign-in. It does not apply to SAML users. See SAML and two-factor.

If it does not work

• You cannot reset a password. The account is LDAP or SAML. The Password section still opens, but in place of a reset control it shows a directory-owned message — "LDAP users cannot receive direct password resets here. Use directory-managed access and sync processes instead." Passwords for those accounts belong to the directory or the identity provider.
• You cannot edit a group membership. The group is an LDAP group. Fix it in the directory and synchronize.
• A save is refused on worker capacity. See the worker limit above.
• A disable or a grant removal is refused. The last-local-admin rule stopped it. Establish and test another local path first.
• You suspect a duplicate person. Stop. Work out which record is authoritative. Do not create a third.

Related pages

• Admin Settings and step-up
• Departments and access
• Directory and LDAP
• SAML and two-factor
• Limits and scope