LDAP / Active Directory

LDAP/AD auth lets users sign in with their existing directory username and password — useful for organizations (banks, universities) that run on-prem Active Directory without a modern SAML/OIDC identity provider. See Enterprise SSO if your identity provider does support OIDC — that’s the more commonly recommended path when it’s available.

Unlike SSO, this isn’t a redirect flow: the username and password are submitted directly to Guardian, which binds to your directory server on your behalf. Guardian never stores the real password.

There’s no dashboard form for this yet — it’s configured via a direct API call, typically by GT Arsenals support during Enterprise onboarding.

How it works

1. Guardian binds to your directory as a service account (bind_dn/bind_password) and searches for the user’s entry under user_search_base using user_search_filter.
2. Guardian re-binds to the directory as that user’s own DN, using the password the user submitted. This re-bind succeeding or failing is the credential check — Guardian never compares a password itself.
3. On success, Guardian reads the user’s email from email_attribute and issues a normal session, same as any other login.

Configuring it

Requires a superadmin JWT for the tenant (or an operator token, for cross-tenant setup):

curl -X POST "https://your-hub.example.com/api/auth/ldap/config?tenant=<your-tenant-slug>" \
  -H "Authorization: Bearer <admin-jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "server_url": "ldaps://dc.your-domain.corp:636",
    "bind_dn": "CN=guardian-svc,OU=Service Accounts,DC=your-domain,DC=corp",
    "bind_password": "<service account password>",
    "user_search_base": "DC=your-domain,DC=corp",
    "user_search_filter": "(sAMAccountName=%s)",
    "email_attribute": "mail",
    "jit_provisioning": true
  }'

• server_url — use ldaps:// (recommended) for TLS, or ldap:// for plaintext (only ever appropriate on a trusted internal network).
• bind_dn / bind_password — a read-only service account used only to search the directory. Leave bind_dn empty for an anonymous search bind, if your directory allows it.
• user_search_filter — must contain %s, replaced with the submitted username (escaped against LDAP injection). The default ((sAMAccountName=%s)) is the standard Active Directory login-name attribute; use (uid=%s) for most other LDAP directories.
• jit_provisioning: true creates a Guardian account automatically on a user’s first successful login, with the Technician role. Without it, a user must already exist in Users & Roles before they can sign in.

Signing in

curl -X POST "https://your-hub.example.com/api/auth/ldap/login" \
  -H "Content-Type: application/json" \
  -d '{"tenant": "<your-tenant-slug>", "username": "<directory-username>", "password": "<directory-password>"}'

Returns the same access_token/refresh_token pair a password login does. Failed attempts always return a generic “invalid credentials” error — Guardian never reveals whether a username exists, whether LDAP is even configured, or why a bind failed.

Requirements

Gated by the same Enterprise-tier entitlement as SSO — see Billing & Plans. Configuring it on a lower tier is refused with a clear error.