obserae by spartan‑conseil

Authentication

obserae lets people sign in two ways, side by side:

  • Local accounts — created on the Users page, with a password stored (hashed) by obserae. Always available.
  • Active Directory (LDAP) — your team signs in with their existing company credentials. Optional, and set up on Settings → Authentication.

Turning on Active Directory does not remove your local accounts. The built-in admin always stays a local account you can use to get back in — even if the directory is unreachable. Think of it as your break-glass key.

Before you start

Ask whoever manages your Active Directory for:

  • The directory URL, ideally secure: ldaps://dc.corp.example:636.
  • A service account (a dedicated read-only user) — its full DN and password. obserae uses it to look people up; it never needs to be an administrator.
  • Where users live (the user base DN, e.g. OU=Users,DC=corp,DC=example).
  • The names (or full DNs) of the AD groups you want to map to obserae roles.

Set it up

  1. Open Settings → Authentication.
  2. Tick Enable LDAP / Active Directory sign-in.
  3. Fill in the Directory URL. Prefer ldaps:// (secure). If your server uses plain ldap:// with StartTLS, tick Use STARTTLS. Paste your Root CA if the certificate is issued by an internal authority.
  4. Under Service account, enter the Bind DN and Bind password. The password is stored encrypted and never shown again.
  5. Under User search, set the User base DN and, usually, keep the default User filter (sAMAccountName=%s) — that is the standard Active Directory login attribute.
  6. Add one or more Group mappings: on the left, an AD group (its name or full DN); on the right, the obserae role it should grant (admin, analyst, auditor, or any group you created).
  7. Click Test connection. A green message means obserae reached the directory and the service account signed in. Fix any error before continuing.
  8. Click Save.

Now an Active Directory user can sign in on the normal login page with their company username and password.

How roles are decided

When someone signs in, obserae looks at the AD groups they belong to and grants the obserae roles you mapped. This is refreshed every time they log in, so moving someone between AD groups updates their obserae access on their next sign-in — no action needed in obserae.

A user who matches no mapping can still sign in, but sees nothing they are allowed to act on until you add a mapping for one of their groups. You will see them appear on the Users page (marked as an LDAP account) so you can adjust the mapping.

Good to know

  • The admin is your safety net. If the directory ever becomes unreachable, sign in as the local admin. An operator can reset its password on the host with obserae-cli user reset-admin-password.
  • Passwords are never stored by obserae for AD users. obserae checks them against the directory each time; it only keeps a lightweight profile (name and group membership) so the rest of the product works.
  • LDAP accounts are managed in Active Directory, not here. Their roles come from the group mapping, so the Users page does not let you edit an LDAP user’s groups directly.
  • Not single sign-on (yet). Users still type their credentials on the obserae login page. Redirect-based SSO (Microsoft Entra ID, Keycloak, …) is not available yet.

From the command line

An operator can do the same from the host:

obserae-cli ldap show     # review the current settings (password hidden)
obserae-cli ldap test     # check the directory is reachable
obserae-cli ldap set --enabled --url ldaps://dc.corp.example:636 ...