Skip to content

FastTAK Authentication Guide

Overview

FastTAK supports two authentication modes:

  1. Certificate-only — users authenticate with client certificates (.p12). No passwords, no LDAP. Simple but no centralized user management.

  2. LDAP via LLDAP — users authenticate with username/password against LLDAP, a lightweight LDAP server. Certificates still required for TAK client connections, but web admin and monitor dashboard access use password-based login.

How LDAP Authentication Works

The init-identity container configures this chain on startup:

TAK Server ←→ ldap-proxy ←→ LLDAP ←→ PostgreSQL (app-db)

The bootstrap sequence

  1. LLDAP starts — lightweight LDAP server backed by PostgreSQL (app-db)
  2. init-identity runs — creates the LDAP infrastructure via LLDAP's GraphQL API:
  3. Creates adm_ldapservice service account (LDAP bind user)
  4. Creates webadmin user with password from TAK_WEBADMIN_PASSWORD (generated per-install by setup.sh; find it with grep TAK_WEBADMIN_PASSWORD .env)
  5. Creates tak_ROLE_ADMIN group
  6. Configures custom attribute schemas
  7. Exits
  8. ldap-proxy starts — listens on port 3389 (internal), proxies LDAP binds to LLDAP and provides /auth/verify for Caddy forward auth
  9. TAK Server reads CoreConfig.xml — connects to ldap-proxy for auth

How a user logs in (web admin on 8446)

  1. User opens https://takserver.example.com (or https://host:8446)
  2. TAK Server shows login form
  3. User enters username + password
  4. TAK Server queries ldap-proxy: cn=<username>,ou=people,dc=takldap
  5. ldap-proxy forwards the bind to LLDAP, which validates credentials
  6. If valid, TAK Server checks group membership for tak_ROLE_ADMIN
  7. User gets admin or read-only access based on groups

How a TAK client connects (ATAK/iTAK)

  1. Client connects to port 8089 with client certificate (TLS mutual auth)
  2. TAK Server validates the cert is signed by its CA
  3. TAK Server looks up the cert's CN in LDAP to find group membership
  4. Groups with tak_ prefix become TAK channels (e.g., tak_team1 → channel team1)
  5. Group membership is cached for 30 seconds (updateinterval="30")

Important: LDAP cache delay

When a new user is created or group membership changes, TAK Server's LDAP cache takes up to 30 seconds to refresh. During this window: - The user can connect (cert auth works immediately) - But they may see "No channels found" - After 30 seconds, disconnect and reconnect — channels appear

Groups and TAK channels

LLDAP Group TAK Channel Who sees it
tak_ROLE_ADMIN (admin access) Admin users
tak_team1 team1 Users in group
tak_fires fires Users in group

Only groups with the tak_ prefix appear as TAK channels. Create groups in the Monitor dashboard (or directly in LLDAP), then assign users.

Key components

Component What it does Runs on
lldap Lightweight LDAP server (Rust), user directory, GraphQL management API Port 3890 (internal)
ldap-proxy LDAP proxy with enrollment token interception, forward auth endpoint Port 3389 (internal)
init-identity One-shot bootstrap of LDAP users, groups, and schemas via GraphQL Exits after setup
adm_ldapservice Service account TAK Server uses to query LDAP LLDAP user
CoreConfig.xml TAK Server config with LDAP connection details /opt/tak/

Rate Limiting

Authentication requests to /auth/verify (the endpoint Caddy uses for forward_auth) are rate-limited per source IP. Only failed attempts count toward the budget — successful auths don't consume it, because Caddy's forward_auth hits this endpoint on every protected-route request and counting successes would lock out legitimate users. See DD-037 for the failures-only semantics.

By default, 10 failures per 5 minutes triggers a 15-minute lockout. Tunable via LDAP_RATE_LIMIT_* env vars (see .env.example). Exceeding the limit returns HTTP 429 with a Retry-After header.

Recovering from accidental lockout: if you trip the limit during testing (wrong password, debugging client configs), restart ldap-proxy to clear the in-memory state:

docker compose restart ldap-proxy