checkId: check.authority.plugin.connectivity plugin: stellaops.doctor.authority severity: fail tags: [authority, connectivity, ldap, database]

Authority Backend Connectivity

This Doctor check tests reachability of the authentication backends Authority depends on. It runs a real TCP probe against a configured LDAP server, and validates that the Standard plugin has a database connection string. It is aimed at operators diagnosing login failures after the configuration check (check.authority.plugin.configured) has already passed.

What It Checks

LDAP server — when Authority:Plugins:Ldap:Enabled is true and Authority:Plugins:Ldap:Server is set, the check opens a real TCP connection to the LDAP host/port (defaulting to 389 for ldap://, 636 for ldaps://) with a 5-second timeout. An unreachable server is reported as a fail naming the host; the check never fabricates a pass when the network is air-gapped.
Standard database — when Authority:Plugins:Standard:Enabled is true, the check verifies a connection string (ConnectionStrings:Authority or ConnectionStrings:Default) is present. A missing one is a fail. The live PostgreSQL reachability proof is intentionally owned by check.db.connection/ check.postgres.schemas.present — this Authority check holds no database client of its own and does not fake the connection (ADR-026 D7).
When only the Standard plugin is enabled with a present connection string and no LDAP backend is configured, the check honestly skips, deferring reachability to the database checks.

Why It Matters

Even with auth plugins correctly configured, an unreachable LDAP directory or an unconfigured database connection string means logins silently fail. Catching this early prevents a platform-wide lockout that looks like a misconfiguration but is really a network or DSN problem.

Common Causes

LDAP server is down, firewalled, or unreachable from the Authority host.
Authority:Plugins:Ldap:Server points at the wrong host/port.
Standard auth is enabled but ConnectionStrings:Authority and ConnectionStrings:Default are both unset.

How to Fix

Docker Compose

environment:
  ConnectionStrings__Authority: "Host=postgres;Database=authority;Username=stellaops;Password=..."
  Authority__Plugins__Ldap__Server: "ldaps://ldap.internal:636"

Bare Metal / systemd

Edit /etc/stellaops/appsettings.json and set ConnectionStrings:Authority and/or Authority:Plugins:Ldap:Server, then confirm the host can reach the backend:

stella doctor run --check check.db.connection

Kubernetes / Helm

authority:
  connectionStringSecret: "stellaops-authority-db"
  plugins:
    ldap:
      server: "ldaps://ldap.internal:636"

Verification

stella doctor run --check check.authority.plugin.connectivity

check.authority.plugin.configured— verifies an auth plugin is configured at all
check.db.connection — owns the live PostgreSQL reachability proof for the Authority database