authentik LDAP and RADIUS outposts

The most important control over what a legacy application can read from authentik is not the outpost itself but the combination of the bind behavior, the service account used for searches and the search base. An LDAP client typically performs two distinct operations: it binds to authenticate, then it searches the directory to find entries and read attributes. These are separate permission questions. A bind that succeeds proves that a user or service account knows a credential. It does not, by itself, define what that identity may read afterward. Before go-live, the team should write down, for each application, which operation the client performs with which identity and which base DN it searches from. A user bind authenticates a person who is logging into the application, such as a VPN portal or a network device login. A service account bind is different: the application uses a dedicated account only to look up directory entries, for example to resolve group membership or display names. These accounts should never be the same identity, and the service account should not be an administrator. Confirm in the authentik LDAP provider settings how the search and bind paths are configured, and test each path separately with a client tool so a success on one does not hide a gap on the other. The main risk is an over-broad search scope. If a client searches from the root of the directory with subtree scope, it can enumerate users, groups and attributes that have nothing to do with its function. Narrow the base DN to the smallest container that holds the entries the application needs, and restrict the search filter where the client allows it. Pair that with group-based access: the application should be allowed to authenticate only members of the group that governs its use, and the outpost should expose only those users. Illustrative example: a single internal wiki that needs only the group wiki-users would bind through an LDAP provider bound to that application, with a service account limited to reading entries under the users container, and no other group would be able to log in. Before relying on any of this, confirm with the vendor documentation which attributes the LDAP provider returns by default, which ones you can remove through property mappings, and how flows apply to bind requests in your release line. Flow behavior and provider options have changed between releases, so the check should be run on the exact version you deploy, against your own test directory, with a list of expected and forbidden attributes written before the test starts.

Before any client points at an authentik LDAP or RADIUS outpost, the team should run a written test plan that proves what each client can and cannot do. The goal is not a single successful login. It is a set of accept and reject cases that show the directory answers the way the legacy system did, and that failures happen in a predictable way. Keep the plan in the same change record as the provider, application and outpost configuration so that anyone reviewing the cutover can see what was tested and against which settings. Start with LDAP binds. For a representative user, test a successful bind with the correct password, a failed bind with a wrong password, and a bind by a user who is disabled or outside the bound application's authorization. Then test the service account used by each legacy application. It should run a search against the base DN and return only the entries its permissions allow, with no password attributes or group memberships it was never meant to see. Confirm this with the exact search filter and attribute list each application sends, because many legacy clients request more attributes than they use. Group-based denial is the case most often missed: a user who is authenticated in authentik but not in the permitted group must be refused by the LDAP provider's authorization, not just by the client. For RADIUS, test an Access-Accept for an authorized user and an Access-Reject for a wrong password and for a user without the required access. Use the same shared secret and client address that production devices will use, because a test from a different source address can pass while the real device fails. Record the exact attributes returned on accept, since VPN concentrators and network devices often depend on them. Confirm the outpost and provider versions match the planned production release line, using the supported versions listed in the authentik security policy as the reference point. Next, test failure behavior deliberately. Stop the outpost during a test window and attempt binds and RADIUS requests from each client. A correctly configured client should fail closed: it should refuse access and surface an error, not fall back to a cached or local account. Where a client does fall back, record it as a finding and decide whether to change the client or the rollout. Check the authentik event logs after every attempt in the plan, successful or not, to confirm each event appears with the expected user, outcome and client. Missing events are a finding in their own right, because they affect later investigations and audit evidence. Finally, map MFA limits before the pilot. LDAP simple binds and most RADIUS password-based requests cannot prompt a user for a second factor, so each client must be classed as either able to carry a second-factor challenge or excluded from MFA-dependent access. Clients that cannot answer a challenge should be excluded or moved to another method, such as a VPN client that performs its own MFA flow. Choose a pilot client that is low risk, has a clear owner and can be reverted quickly. Define the rollback path in advance: keep the legacy directory reachable, document the DNS or configuration change that points the client back, and rehearse that change once before cutover.

After go-live, the team owns five things: outpost health and connectivity, authentication failures and event logs, service account password rotation, change records for providers and flows, and outpost version alignment with the authentik server. The LDAP and RADIUS outposts are separate processes that depend on a live connection to the authentik server, so an outpost that loses that connection stops serving legacy clients even though the server itself is healthy. Monitor each outpost's connection state in the authentik interface and alert when it drops. Then run a scheduled test bind and a test RADIUS authentication from a client's network segment, because a green status does not prove that a specific client can complete a bind or an access request.

Authentication failures are the earliest signal that something has changed. Review failed LDAP binds and rejected RADIUS requests in the authentik event log, and look for spikes by client, by source address and by account. A sudden rise in failures from one network device often points to a rotated secret, an expired account or a changed search scope rather than to attacks. Enhanced audit logging is listed as an Enterprise feature on the authentik pricing page, so confirm which events your edition retains and whether they can be forwarded to your SIEM before you rely on them for investigations. Service account passwords used by clients for search or bind also need a rotation schedule. For each rotation, update every client that uses the account, confirm the new credential works, and record the date. RADIUS shared secrets follow the same pattern and must be changed on both the outpost side and the client side.

Keep each outpost on the same release line as the authentik server. Before any upgrade that touches outposts, read the release notes for the target version. The authentik 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading from earlier releases, so check PostgreSQL's maximum connection setting, any connection pooler limits and the headroom left for the outposts before you upgrade. Rehearse the upgrade in a staging environment with a copy of production data. Confirm which release lines currently receive security fixes in the authentik security policy, and plan for security releases, which the project announces at least 24 hours in advance. Name an owner who can act on that notice the same day, since the window to schedule a change may be short.

Provider and flow configuration is stored in PostgreSQL, which holds all authentik configuration and data except uploaded files. A reliable PostgreSQL backup is therefore the core of your recovery plan for LDAP and RADIUS providers, their bind and search settings, and their outpost assignments. Take a backup before every outpost-affecting upgrade and on a regular schedule that matches your recovery objectives. Restore to a separate environment at least once and verify that the providers, flows, applications and outposts appear as expected, then confirm that outposts reconnect and that client binds succeed. Also confirm how outpost tokens are handled after a restore, and where uploaded files such as custom branding assets are backed up separately. Store any exported configuration in version control so changes can be reviewed and reapplied.

Maintain a runbook with one entry per client, listing the client name, its bind model (anonymous, service account or user bind, and whether it uses LDAP or RADIUS), the authentik provider and outpost it uses, the search or access permissions it holds, the MFA limitations that apply to it, the date its credential was last rotated and the named owner who can approve changes. The owner should be a person or team in your organization, not the authentik administrator alone. Pair the runbook with a change record for each provider, flow and outpost change, including who made it, why and how to reverse it. Review the runbook at each outpost upgrade and each credential rotation, because the entries drift quickly as new network devices and VPNs are added. Ask your implementation partner to deliver this runbook as part of the handover, with the owner column completed before go-live.