Directory And LDAP

BareBones Ticketing reads Active Directory over Lightweight Directory Access Protocol (LDAP) and copies the identities and memberships you have scoped into its own database. It does not query the directory when deciding whether a request is allowed. This page covers configuring the connection, scoping it, and synchronizing.

Active Directory is the only implemented provider.

What sync does and does not do

Synchronization creates and updates user accounts, creates and updates groups, and sets group memberships. That is its whole effect on access.

Being in scope lets the account exist in BareBones Ticketing. It grants nothing. The account has no department access, no ticket access, and no SystemAdmin until you map its group to a department (Departments and access) or record a grant against it (Users and groups).

Sync never writes to your directory. It reads.

Before you start

• You need SystemAdmin and a satisfied step-up. The whole workspace is gated. See Admin Settings and step-up.
• Have an active local SystemAdmin account you have signed in with. If the directory work goes wrong, that account is how you get back in.
• Get a read-only bind account from the directory owner. Do not use a Domain Admin account or a person's own administrator account.
• Agree the base distinguished name (DN), the user and group search scopes, and any filters with the directory owner first.

Create the integration record

1. Open Directory and identity integrations.
2. Select Add integration, choose Active Directory / LDAP, then select Add integration.
3. Open the Active Directory / LDAP workspace.
4. In Connection, set Provider and connectivity:
   • Provider: Active Directory.
   • Directory integration enabled.
   • Host and Port. Port 636 is the normal LDAPS port.
   • Use SSL / LDAPS.
5. Set Bind and safety posture:
   • Bind account / DN and Bind password.
   • Allow anonymous bind.
   • Trust a pinned certificate, and the Pinned certificate thumbprint it requires.
6. Select Save connection settings once.

Leave Bind password blank to keep the stored password. Type in it only to replace the password.

Port 389 without SSL and anonymous bind each weaken the connection and need explicit approval in your environment.

Trust a pinned certificate does not. It is for a directory using a self-signed certificate or a private certificate authority that cannot be added to the host trust store, and it is a pin, not a relaxation: with it on, the server's certificate must match the Pinned certificate thumbprint you saved, as SHA-1 or SHA-256. A certificate that is missing, malformed, mismatched, expired, or not yet valid fails the bind closed. Spaces, colons and hyphens in the thumbprint you paste are normalized before it is saved.

Use Inspect server certificate to read what the server is presenting before you pin it, and check the details against what the directory owner told you to expect. Pinning a thumbprint you have not verified is how you pin an attacker's certificate.

Turning the option on without a thumbprint is refused. This is not a troubleshooting step, and there is no setting that accepts whatever certificate the server happens to present.

The bind password is excluded from configuration audit records, sync records, and error messages.

Set the directory scope

1. Open Directory scope.
2. Enter the base DN.
3. Add each user source scope and group source scope. Each has a search base DN, an optional LDAP filter, and an enabled or disabled state.
4. Use the browse and suggestion controls to inspect the directory. What they return is a draft until you save it.
5. Read the warnings for overlapping or duplicate roots and filters.
6. Set nested-group traversal only if you need it. The depth runs from 1 to 10 and defaults to 3. Cycles are detected.
7. Select Save directory scope.

Keep the scope as narrow as the work requires. Scope decides which accounts and groups sync creates.

How an identifier is matched in the directory

When someone signs in or re-verifies with a directory identity, the product looks the identifier up inside the configured scope. A plain identifier such as joe is matched against sAMAccountName. An identifier shaped like an email address, such as joe@example.com, is matched against either userPrincipalName or mail, so an account whose UPN and mail attribute differ can be found by either.

A lookup that matches more than one directory entry inside the queried scope is refused, rather than the product choosing one. If a person cannot sign in and the directory holds two entries carrying the same address, that is the reason. Narrow the scope or fix the duplicate with the directory owner. Do not work around it by broadening the search.

Test the connection

1. Re-open Connection and check the saved values.
2. Select Test connection once.
3. Read the result.

The test runs against saved configuration, not against unsaved edits in the form. So does sync.

If the test fails, fix the transport, trust, bind, or scope with the directory owner. Do not turn off certificate validation to make the test pass.

Run an incremental sync

Incremental sync catches up from a stored change watermark. Use it for routine work.

1. Open the Sync tab.
2. Review the cadence and guardrail settings, then select Save sync settings.
3. Open the Activity tab and review it for the last result, the last failure, the watermark, the schedule, and whether a run is in progress.
4. Select Request incremental sync.
5. Wait. Use Refresh sync posture to check progress. Do not start a second run alongside the first.
6. Reconcile the created, reactivated, updated, and membership counts, and read the warnings.

A successful LDAP sign-in can create or reactivate a user on its own. Group memberships arrive only with sync, so a user created this way may have no department access until the next sync finishes.

Run a full sync

Full sync reconciles everything in scope. Anything in the product but no longer found in scope is treated as absent from the directory and made inactive.

1. Review the saved roots, the filters, the nested depth, recent failures, and worker capacity.
2. Confirm with the directory owner that users and groups missing under the current scope should be treated as gone.
3. Select Request full sync once.
4. Watch the Activity tab until it completes or fails.
5. Reconcile which identities were made inactive, which memberships changed, and what access moved as a result.

Narrowing the scope and then running a full sync makes the excluded users and groups inactive in BareBones Ticketing. Their directory records are untouched, and their ticket history in BareBones Ticketing stays.

By default a run stops at 10,000 visited nodes, 20,000 membership changes, or 120 seconds, whichever comes first. These are configuration guardrails, not performance figures.

Disable the integration

1. Confirm you have local SystemAdmin access and know which users sign in through LDAP.
2. On the Sync tab, select Disable directory integration.
3. Confirm LDAP sign-in and synchronization have stopped.

The saved configuration stays and remains readable. Product users, groups, and history stay. Your directory is untouched.

While the integration is disabled, the browse, connection-test, and sync controls are unavailable.

If it does not work

• The connection test fails. Work through transport, trust, bind, and scope with the directory owner. Do not disable certificate validation.
• A sync is already running. Refresh the sync status and wait. Do not queue a competing request.
• A run is refused on worker capacity. Reactivating users or applying memberships would exceed the licensed worker limit. Narrow the scope or reconcile capacity. See Limits and scope.
• A full sync inactivated more accounts than expected. Keep the run evidence. Correct the scope, then review before running full sync again.
• The directory is down and you cannot sign in. Use the local break-glass administrator. See Admin Settings and step-up.

Related pages

• Admin Settings and step-up
• Departments and access
• Users and groups
• SAML and two-factor
• Limits and scope