Learn Authentik - LDAP Outpost Provider

#Introduction

In episode 17, you connected Authentik as a client to an external LDAP using a source. User data flows from the external directory into Authentik. Episode 18 fully reverses the direction: Authentik becomes the LDAP server. That role is performed by the LDAP outpost, a component that presents Authentik users and groups in the LDAP language so legacy applications can keep using them.

Think of it like an interpreter at an international event. The Authentik delegation speaks modern standards (REST, JSON, OIDC), while legacy applications only understand the LDAP protocol. The outpost sits in the middle and translates the conversation without changing the truth of the data on either side.

#What Is an LDAP Outpost

An LDAP outpost is a component that runs the LDAP protocol in front of Authentik data. There are three things to understand before using it:

• Read-only against the directory. LDAP clients can bind and search, but all data writes must still go through the Authentik UI or API. The outpost isn't storage; it's a window, not a warehouse.
• Passwords are validated via a flow. When a client binds with a password, the outpost runs an Authentik bind flow instead of matching a hash. The consequence: Authentik policies like account blocking and reputation still apply on the LDAP path.
• One source of truth. There's no synchronization to maintain. Users created in Authentik are immediately visible to the LDAP application.

#Standalone vs Embedded Outpost

Authentik has two modes of running an outpost:

• Embedded — runs inside the Authentik server process. The fastest for trials and lab environments because no extra container is needed; suitable for a single non-production instance.
• Standalone — runs as a separate container connected to Authentik via a token. The process is isolated, scalable, and becomes the recommended mode for production.

The rule of thumb: start with embedded to learn the mechanism, then move to standalone as soon as the deployment enters a production environment.

#Creating an LDAP Provider

The provider is created from the Directory → Providers menu, then choosing LDAP Provider. Several core settings are worth understanding.

#Base DN

The Base DN is the directory root advertised to clients, for example dc=ldap,dc=example,dc=com. It's like the building address clients mention on first connection. The Base DN isn't where user data lives; it's a namespace label that must stay consistent across the installation.

#Bind Mode

The bind mode determines how clients prove their identity:

• Direct — the client binds directly with an Authentik user's username without searching first. This is the most common and simplest mode.
• Search — the client does a two-step bind: an initial bind with a technical account, then a search for the target user. This mode is needed by applications that separate the connection account from the user account.

#Bind Flow

The bind flow is the Authentik flow that runs validation when a bind occurs. This is where rules like reputation policy and conditional MFA get evaluated too. Don't point at just any flow; use the authentication flow you carefully designed in episodes 4 through 7.

#Connecting the Outpost

Once the provider is created, Authentik automatically creates the associated outpost. For standalone mode, open the outpost details and copy its token:

docker run -d --name authentik-ldap \
  -p 1389:3389 \
  -e AUTHENTIK_TOKEN='token-outpost-dari-UI' \
  -e AUTHENTIK_HOST='https://auth.example.com' \
  ghcr.io/goauthentik/proxy:latest

The goauthentik/proxy image is used for all outpost types; the LDAP or proxy role is determined by the configuration on the Authentik side. Once the container is running, the outpost status in the UI changes to Healthy.

#Verifying the Connection

Check directly from a client machine with ldapsearch:

ldapsearch -x -H ldaps://ldap.example.com \
  -D "uid=arman,ou=users,dc=ldap,dc=example,dc=com" \
  -W -b "dc=ldap,dc=example,dc=com" "(uid=arman)"

If the result contains the full user entry with the memberOf group attribute, the connection and bind flow are working correctly.

#Connecting LDAP Clients

There are three common client categories:

• Linux (PAM/SSSD) — point ldap_uri and ldap_search_base at the outpost in /etc/sssd/sssd.conf; SSH login and local services then use Authentik identities.
• Internal applications — fill in the LDAP Host, Base DN, Bind DN, and Bind Password fields in the settings of applications like Nextcloud, GitLab, or ERP applications.
• Network devices and VPNs — many switches, access points, and VPN gateways can use LDAP as their user authentication source.

#LDAP Operations: Bind, Search, and memberOf

The two operations clients perform most often:

• Bind — proves identity with a username and password; the outpost forwards it to the Authentik bind flow.
• Search — looks up entries with filters like (uid=arman) or (&(objectClass=person)(mail=arman@example.com)).

memberOf is a dynamic attribute containing the list of group DNs the user belongs to. Because it's computed on the fly from Authentik data, group membership changes are visible immediately without waiting for synchronization. This is what makes the outpost superior to periodic sync schemes.

#LDAP Outpost Use Cases

• Unified authentication source — all applications, modern and legacy, share one identity directory.
• SSO for legacy applications — applications without OIDC/SAML support can still log in with the same identity.
• Network device authentication — switches and firewalls use the same credentials as other applications.
• VPN authentication — remote users are validated by Authentik policies.

#LDAP Outpost Security

• Use LDAPS (LDAP over TLS) outside trusted networks; don't let plaintext LDAP on port 389 cross your network.
• Restrict network access to the outpost port with a firewall so it isn't open to the public internet.
• The outpost is read-only and validates through flows, so IP reputation and account blocking remain active.
• Don't expose more attributes than the client needs.

#Closing

Summary of episode 18:

• The LDAP outpost exposes Authentik users and groups as an LDAP directory for applications that only understand the LDAP protocol.
• Embedded outposts suit labs; standalone suits production and scalability.
• The provider is configured via base DN, bind mode, and bind flow.
• Search and memberOf support both authentication and group-based RBAC.

In episode 19, we shift to the defense side: the reputation system and threat detection that automatically blocks IP addresses and accounts behaving suspiciously. See you there!