OpenLDAP to authentik migration services

Replacing OpenLDAP with the authentik LDAP provider: what the move involves

A standalone OpenLDAP server usually answers binds and searches from many applications at once, and replacing it means moving every one of those clients without breaking a single login. The effort depends on three things: how many applications bind to the directory, which LDAP behaviors each of them relies on (for example, specific search filters, memberOf-style group lookups, referential behaviors or particular password change paths), and whether any of them need MFA in binds. Do not commit to a duration until you have an inventory of each client, its bind DN, its base DN and its search filters. The current OpenLDAP releases are 2.7.1 and the 2.6.15 long term support release, so record which version you run today, since that determines how much of your existing configuration you must reproduce.

The move happens in two steps. First, an LDAP source in authentik imports your existing users and groups from the OpenLDAP server, so the accounts, group memberships and password handling you rely on exist in the authentik database before any application changes. Second, you point applications at the authentik LDAP outpost, which serves those users and groups under a configurable base DN. The authentik LDAP provider places users under ou=users and groups under ou=groups, and the default base DN is DC=ldap,DC=goauthentik,DC=io, so most applications will need a changed base DN, user search base and group search base in their own configuration. Confirm the exact import behavior, including how passwords and attributes are carried over, in the authentik LDAP source documentation before you plan cutover.

Which OpenLDAP capabilities map to the authentik LDAP provider

This table compares the OpenLDAP features that LDAP clients depend on with the authentik LDAP provider equivalent for each. Read the status column first: rows marked as needing confirmation are the ones to test in a pilot before any application is repointed. The main takeaway is that the directory tree and bind behavior can usually be kept stable, but replication and availability must be planned again at the infrastructure level.

Capability	OpenLDAP (slapd)	authentik LDAP provider	Status
Directory tree and base DN	slapd serves the suffix you configure, such as your organization's domain-based DN.	Serves users under ou=users and groups under ou=groups below a configurable base DN, defaulting to DC=ldap,DC=goauthentik,DC=io.	Maps with changes. Set the base DN to match the existing suffix so application search bases do not change.
Users and groups	Entries live in the directory, with DNs reflecting your existing layout.	Users and groups are read from the authentik database after import, so DN layout follows the provider's ou structure.	Maps with changes. Confirm that user and group DNs and group membership attributes match what each application queries.
Simple binds	Supported for user and service account authentication.	Applications bind with a user or service account served by the outpost. Bind DN formats must be checked per application.	Maps with changes. Test each application's bind DN pattern and service account before cutover.
SASL binds	Strong authentication through SASL is supported.	Support for specific SASL mechanisms is not confirmed in this comparison.	Needs confirmation with the vendor. Ask which SASL mechanisms the LDAP provider accepts.
TLS and certificates	Certificate authentication through TLS is supported.	Client connection security depends on how the outpost is exposed. Certificate handling must be confirmed.	Needs confirmation with the vendor. Confirm LDAPS or StartTLS options and certificate authentication for the outpost.
Replication and high availability	Single-provider, multiple-consumer and multi-provider replication are supported for directories where a single point of failure is not acceptable.	No directory-level replication is planned in this comparison. Availability depends on PostgreSQL, outpost placement and load balancing.	Maps with changes. Re-plan availability at the infrastructure level, including database high availability and outpost redundancy.
Storage backend	The main backend is MDB, a transactional backend built on LMDB.	All configuration and data sit in PostgreSQL, except uploaded files.	Maps with changes. Size, back up and monitor the PostgreSQL database that now holds directory data.
Schema and overlays	Custom schema and overlays such as membership or password policy overlays extend the directory.	Attributes are exposed through authentik's own user and group fields and property mappings.	Needs confirmation with the vendor. List every custom attribute and overlay behavior your applications rely on.
Multi-factor authentication in binds	Not a native directory feature. MFA is usually handled outside the directory.	MFA support for LDAP binds is not confirmed in this comparison.	Needs confirmation with the vendor. Test whether MFA can be enforced for LDAP clients before retiring any second-factor workaround.

Base DN and attribute compatibility: where applications break first

Decide the base DN before any application is pointed at the new service. The authentik LDAP provider serves every user and group in its database under a configurable base DN, with users under ou=users and groups under ou=groups. The default base DN is DC=ldap,DC=goauthentik,DC=io, which is unlikely to match the tree your applications were configured against. If your OpenLDAP directory uses dc=example,dc=com and an application has dc=example,dc=com hardcoded as its search base, that application will return no results until the base DN matches or the application's configuration changes. Changing the base DN after go-live means reconfiguring every client that bound to the old one, so treat it as a day-one decision that is recorded in the migration plan.

Build a per-application inventory before cutover. For each application that binds to the existing server, record the search base, the filter it uses to find users and groups, the attribute it reads for the login name, the display name, the email address and any custom attribute, and how group membership is expressed (membership attributes on the group object, a memberOf-style attribute on the user, or a group search by DN). Then compare each item against the tree authentik will present under the chosen base DN. Attribute names that are mapped by default may not be the ones your applications expect, and group membership in particular is where applications most often fail silently, returning users who cannot access anything. Do not assume schema parity. Confirm each application's behavior against a test instance, and confirm the exact attributes the authentik LDAP provider exposes in its current documentation for your version, using the authentik LDAP provider documentation.

Plan for the applications that cannot be fixed by a configuration change. Some clients expect group objects to carry explicit member DNs, others use nested group lookups, and some hardcode object classes. Record every such case with the owning team, the workaround (a configuration change, an attribute mapping or a replacement integration) and the test that proves it works. Keep a rollback path for each application, because a directory migration that only looks correct in a lab often breaks in production on the first group-dependent login. Confirm each item with the application owner rather than the directory team alone.

Documented import paths from OpenLDAP into authentik

Three documented pieces decide how an OpenLDAP directory moves into authentik: an LDAP source that pulls users and groups in, LDIF exports taken with OpenLDAP's own tools, and the authentik LDAP provider that serves them back to applications. Each covers a different part of the cutover, so most teams use more than one.

LDAP source import

An LDAP source connects authentik to the running OpenLDAP server and imports users and groups into the authentik database before any application moves. This is the path that keeps the existing directory as the upstream record during the transition. Check which attributes the source maps to authentik user fields, how group membership is read, and how often the sync runs, since these settings decide whether later changes in OpenLDAP reach authentik.

LDIF export for inventory

OpenLDAP's command line LDAP utilities and LDIF tools can dump entries to LDIF files, which give you a static, reviewable copy of the directory. Use the export to count users and groups, find orphaned or disabled accounts, and reconcile the result against what the LDAP source imported. The export is a snapshot, so it does not keep authentik in sync and must be repeated if the directory changes before cutover.

Password handling

Imports through the LDAP source and LDIF exports handle credentials differently, and the password path is the item most likely to force resets. Confirm in the authentik LDAP source documentation whether password hashes are imported or whether users must set a new password on first login. Also check the hash formats your OpenLDAP entries use, because an import that cannot read them leaves users locked out until they reset.

Attribute and base DN mapping

The authentik LDAP provider serves users under ou=users and groups under ou=groups beneath a configurable base DN, which defaults to DC=ldap,DC=goauthentik,DC=io. Applications that bind to your current base DN will fail unless the provider base DN is set to match or the application configuration changes. Map the attributes each application reads, such as uid, mail and memberOf, before you cut DNS or service accounts over.

LDAP provider as the serving side

The LDAP provider is what applications bind to after migration. It serves every user and group stored in authentik, so it works whether those records came from a source import, an LDIF load or manual creation. It does not replicate OpenLDAP's directory structure, schema extensions or replication topology, so applications relying on custom object classes or on OpenLDAP-specific controls need testing before the switch.

Reconciliation before cutover

Run the LDIF inventory and the authentik user and group counts side by side, and repeat the comparison after each sync. Differences in group membership, disabled accounts and service accounts are the usual gaps. Ask your team to confirm which OpenLDAP entries are service accounts that must be recreated in authentik, because a source import will not turn them into the bind accounts your applications expect.

Sequence for syncing users first, running in parallel and cutting over

This sequence moves identities and applications from OpenLDAP to authentik's LDAP outpost without a single big-bang switch. Each phase produces a checkpoint the team can verify before the next one starts.

Inventory applications and their LDAP usage
The platform team and application owners list every system that binds to OpenLDAP, noting the bind DN style, the search base, the attributes and groups each application reads, whether it writes back to the directory, and whether it uses LDAPS or StartTLS. Each application is also marked for pilot, parallel run or later cutover. This step is done when every consumer has an owner and a documented bind and search profile, and the team has confirmed which applications need password changes or MFA inside the bind. Confirm these details with each application owner, since many clients hard-code search bases or group attributes that must match after the move.
Build authentik on the chosen database and target
The team deploys authentik on the target chosen in the design phase, with PostgreSQL as the only data store, using the Docker Compose or Kubernetes guide as the starting point. The Compose guide positions that method for test setups and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production. Certificates, the reverse proxy and backups are configured now so the LDAP outpost can be reached by its clients. This step is done when the server and worker are healthy, a backup has been restored in a test environment, and the team can reach the admin interface over the intended network path.
Import users and groups through an LDAP source
An LDAP source is configured in authentik to read users and groups from the existing OpenLDAP server, mapping attributes such as usernames, display names, email addresses and group membership. The import is run once to create authentik accounts, then re-run on a schedule while OpenLDAP remains the source of truth. Decision point: the team confirms how passwords will be handled, because an LDAP source import does not by itself carry password hashes into authentik, so the team must choose between forced resets, a password change at first login or a separate hash import path. This step is done when user and group counts match between the two directories, and a sample of accounts shows the expected attributes and memberships.
Configure the LDAP provider and base DN
The team creates an LDAP provider and outpost in authentik, sets the base DN to the value existing clients expect, and checks that users appear under ou=users and groups under ou=groups as the provider documents. Where the default base DN differs from the current directory, the team either changes it to match or plans client reconfiguration. Decision point: the team confirms MFA enrollment for LDAP binds, since authentik's MFA behavior for LDAP clients depends on the flows and bind settings chosen, and that must be verified against the application's bind method before users are asked to enroll. This step is done when a test client can bind and search with the expected DN and attribute set, and the team has a written record of the base DN, bind account and MFA behavior.
Pilot with low-risk applications
A small group of applications with low business impact and few group dependencies is pointed at the authentik LDAP outpost in a test or staging path. Owners run defined login, search, group lookup and write tests, and the team records any attribute, filter or TLS difference from the OpenLDAP behavior. Applications that write to the directory are tested separately, since authentik's LDAP provider serves the authentik database and is not a write-through replacement for OpenLDAP. This step is done when each pilot application has a signed test result, the defects found have been fixed or accepted, and the team has a list of client settings that must change at cutover.
Run both directories in parallel and reconcile
Both OpenLDAP and the authentik LDAP outpost serve their applications for an agreed period, while the LDAP source keeps authentik in step with OpenLDAP changes. The team compares user, group and attribute data on a regular schedule, investigates drift such as disabled accounts, renamed groups or password changes that have not reached authentik, and tracks which applications have moved. Reconciliation reports are kept as evidence for change and access reviews. This step is done when repeated comparisons show no unexplained differences for the in-scope population, and the team has agreed the criteria for each cutover wave.
Cut over application by application
Each application is switched in its own change window by updating its LDAP server address, base DN, bind account and TLS settings to point at authentik, then running the test set from the pilot. Applications are moved in waves, with the owner present, and the previous OpenLDAP configuration is kept ready so the application can be reverted quickly. Any application that cannot be verified is left on OpenLDAP and recorded as an open item. This step is done when each cutover has a confirmed login and search test, the owner signs off, and the application appears in the migration log with its rollback path.
Decommission OpenLDAP after the rollback window
Once every in-scope application has run on authentik through the agreed rollback window, the team stops OpenLDAP writes, takes a final LDIF export and a verified backup, and shuts the service down in a controlled order. Retained backups are stored under the organization's retention policy, and the record of the migration, including reconciliation results and open exceptions, is filed with the change records. This step is done when no application still binds to OpenLDAP in monitoring logs for the agreed period, the final export has been tested for restore, and the decommission has been approved by the system owner.

Choosing a cutover path for each application type

Applications in this group authenticate users with a bind and look up a few attributes, such as mail, display name or group membership, using a service account. They usually expose a single LDAP URL, a bind DN, a bind password and a user search base in their configuration. These are the lowest-risk moves because the protocol surface is small and the change is mostly a host and credential update.

Test: Point a staging copy of the application at the authentik LDAP outpost, then sign in with a known test user and confirm the returned attributes match what the application expects.
Configure: Replace the host and port, set the bind DN to the authentik service account format, and rotate the bind password to a new value stored in your secrets manager.
Confirm the search filter: Check whether the application searches by uid, sAMAccountName or mail, and confirm that authentik returns those attributes for users under ou=users.
Check TLS: Confirm whether the application verifies the certificate chain and hostname, and load the authentik CA into its trust store before cutover.
Confirm with the vendor: Ask whether the application caches directory results and how long it keeps stale group data after a change.

Run a sign-in test for each role the application grants before you switch production traffic, and keep the old OpenLDAP endpoint available for a rollback window.

Some applications hard-code the base DN, the object classes they query, or the group filters they expect, often because the directory structure was built into a configuration template years ago. authentik's LDAP provider uses a configurable base DN, with the default being DC=ldap,DC=goauthentik,DC=io, and places users under ou=users and groups under ou=groups. If your OpenLDAP tree uses a different layout, these applications will fail silently or return empty results.

Test: Run an LDAP search with the exact base DN, filter and attribute list the application uses, against the authentik outpost, and compare the output with the same query against OpenLDAP.
Configure: Set the base DN in the authentik LDAP provider to match the old tree where practical, or record the mapping and change the application configuration.
Confirm object classes: Check whether the application requires object classes such as posixAccount or groupOfNames, and verify the attributes authentik returns for each.
Review group filters: Test membership filters like memberOf or member against authentik groups, and confirm the group DN format matches what the application parses.
Confirm with the vendor: Ask which schema and base DN settings are hard-coded versus configurable, and whether a supported change path exists for the object classes it queries.

Write the query results from both directories side by side so that any attribute or DN difference is documented before the application moves.

What drives the cost and duration of an OpenLDAP replacement

This table lists the factors that change the effort of replacing OpenLDAP with the authentik LDAP provider, what raises and lowers each one, and what to request in a written scope. Read it before asking for a quote, because most of the difference between a small and a large engagement comes from the rows below.

Driver	What raises effort	What lowers effort	What to request in the quote
Applications bound to OpenLDAP	Many services bind directly, each with its own search filters, group expectations and service accounts	A short, verified inventory of binds with owners and test procedures for each	Named application list, bind DN per app, and a test case per application
LDAP client behavior	Clients that assume specific schema attributes, memberOf values, nested groups or referrals	Clients that use simple binds and standard attributes only	Written compatibility test matrix per client version and the expected attribute mapping
Directory size and group structure	Large user counts, deep or nested groups, and groups used as application authorization	Flat, well-named groups already mapped to applications	Count of users, groups and nesting depth, plus the sync schedule for the initial import
Base DN and OU layout	Clients hard-coded to an existing base DN that differs from the authentik default	Base DN chosen to match current clients, so fewer client changes are needed	Confirmed base DN, OU structure and any client configuration changes in scope
Password storage and migration	Password hashes that cannot be carried over, forcing resets or a staged cutover	Compatible hash formats or a planned reset window agreed with the business	Hash format inventory, migration method and who owns user communication
MFA on LDAP binds	Requirements that users complete a second factor during bind, which some clients cannot prompt for	Clients that accept the workflow or a scoped service account policy	Confirmation of the MFA method per client and a test of the bind behavior
Enterprise features the design depends on	Designs that rely on capabilities listed as Enterprise on the authentik pricing page, which are priced separately from open-source capabilities	Designs limited to open-source capabilities, verified against the current feature list	Written list of required features, the edition each needs, and a statement of which parts of the design depend on them
Number of environments	Separate development, test, staging and production directories, each needing sync and client tests	A repeatable deployment and sync procedure reused across environments	Environment count, data refresh rules and whether non-production data is masked
Team PostgreSQL and container skills	No in-house PostgreSQL operations or Docker Compose or Kubernetes experience	Existing platform skills and a managed PostgreSQL service	Who runs the database, backup ownership and skills handover in the statement of work

What usually goes wrong when OpenLDAP is retired

Most failed LDAP retirements fail at the edges: a client that hard-codes a base DN, a hash it cannot verify, or a bind that stops working behind a firewall. The cards below cover the risks that tend to surface only after OpenLDAP is switched off, with the prevention step and the parallel run check for each.

Base DN and attribute names change

The authentik LDAP provider serves users under ou=users and groups under ou=groups beneath a configurable base DN, which will differ from your OpenLDAP tree. Applications that hard-code a search base, a bind DN format or attributes such as uid or memberOf will fail silently or return empty results. Prevention: inventory every client's search base, bind DN pattern and attribute mappings, and set the base DN in authentik to match them where possible. Parallel run: confirm each application can search, log in and resolve group membership against authentik.

Password hashes that cannot be reused

Existing OpenLDAP password hashes do not automatically work as authentik passwords, and a bind that succeeds against OpenLDAP may fail after cutover. Plan how each user's credential is set: a forced reset, a staged import, or a first-login capture during a transition period. Confirm which hash schemes your OpenLDAP instance uses and whether authentik can verify them before you rely on any import path. Parallel run: test a bind with a migrated account, a reset account and a locked or disabled account.

MFA on binds that cannot prompt

Adding a second factor to LDAP binds only helps clients that can present a challenge or a code. Many embedded devices, legacy mail clients and service accounts send a simple bind with no prompt path, so enforcing MFA can lock them out. Prevention: classify every bind by client type, decide which service accounts stay on a separate policy, and document the exceptions before enforcement. Parallel run: test each client class with MFA enforced and record which ones fail.

Outpost placed behind latency or firewall limits

An LDAP outpost that sits across a WAN link, a stateful firewall or a NAT boundary can drop long-lived connections or add enough delay to time out binds. Clients with short timeouts often report intermittent logins rather than a clear outage. Prevention: place the outpost close to the applications that bind to it, open the LDAP and LDAPS ports both ways where the design requires it, and measure bind latency under load. Parallel run: compare bind times and failure rates from each application subnet.

Decommissioning before the rollback window closes

Turning off OpenLDAP as soon as authentik answers queries removes the fallback you need if a client or group mapping breaks later. Some faults appear only at month-end jobs, password changes or new group assignments. Prevention: write down the rollback window, keep OpenLDAP read-only and backed up for that period, and define the criteria that close it. Parallel run: confirm rollback works end to end by repointing one non-critical client back to OpenLDAP and back again.

Group membership semantics differ

OpenLDAP groups often use static membership attributes, nested groups or a memberOf overlay, while authentik models membership through its own group objects. Applications that expect nested membership or a specific group DN format may grant the wrong access or none at all. Prevention: map each access rule to the group it depends on, decide whether nesting is needed, and check how group entries are exposed under ou=groups. Parallel run: compare effective group lists for a sample of users in OpenLDAP and authentik and confirm the applications read them the same way.

How long and how much does replacing OpenLDAP with authentik take?

What drives the cost of replacing OpenLDAP with authentik?

Cost follows the written scope, and the largest drivers are the number of applications that bind to LDAP, how many of them need changes, and how much directory data must be reconciled. Each application that authenticates against OpenLDAP needs its bind DN, base DN, search filters and attribute expectations checked against the authentik LDAP provider, and some will need configuration changes or testing. Other drivers include the number of user and group sources, whether passwords must carry over, the number of environments (test, staging, production), and how many change windows the cutover needs. DeployOpen does not publish a price list. A quote follows from the agreed scope, so ask for each cost component to be listed separately: discovery, source sync, application cutover, testing, documentation and any ongoing support. Ongoing costs usually come from running authentik itself, including hosting, PostgreSQL and upgrades, which recur after the project closes.

How long does an OpenLDAP to authentik migration take?

Duration depends mainly on the application inventory, not on the directory size alone. A directory with many users can sync quickly, while a few applications with unusual LDAP queries, hard-coded base DNs or custom schemas can take longer to test and cut over. Plan the timeline in phases: inventory of LDAP clients, syncing users and groups into authentik, building and testing the LDAP provider and outpost, cutting applications over one at a time, and retiring the old server after a confirmed rollback window. Each application owner needs time to test, so their availability often sets the pace. Ask for the timeline as a list of phases with dependencies and client decisions named, and confirm the application count and change freeze dates before agreeing a schedule.

What does the migration need from our team?

The work needs several things from your side before it starts. You need read access to the OpenLDAP directory, including the schema, the base DN, the group structure and the bind accounts used by applications. You need a named owner for each LDAP-dependent application who can confirm what it queries, what attributes it expects and how it tests successfully. Your team also needs to approve change windows, provide test accounts, and agree who signs off on cutover and rollback. Network access between the authentik outpost and each client, plus the ability to change application configuration, must be confirmed early. Ask the partner to list these inputs in the statement of work so that delays can be traced to a specific dependency.

Can our own team replace OpenLDAP with authentik without a partner?

Yes, a capable internal team can do the work, and the decision depends on skills and capacity rather than on whether the product allows it. The team needs experience with LDAP schemas and bind behavior, PostgreSQL and container or Kubernetes operations, and enough time to test every application that binds to the directory. The main risk for in-house teams is underestimating the application inventory, because undocumented LDAP clients often surface during cutover. A partner can contribute a fixed-scope discovery, a tested cutover plan and documentation, while your team keeps ownership of the platform afterward. Whichever path you choose, confirm who will run the authentik upgrades and outpost updates once the migration is complete.

Does the authentik LDAP provider cover everything OpenLDAP does?

No, and the gap should be assessed before committing to the project. The authentik LDAP provider serves the users and groups held in the authentik database under a configurable base DN, with users under ou=users and groups under ou=groups. It is designed to let applications authenticate against authentik, not to be a general-purpose directory server. OpenLDAP offers features such as its own MDB backend, replication across providers and consumers, caching proxies, and a wide range of overlays and schema options. Check each capability your applications and operators rely on, including custom schema attributes, write-back from applications, replication topology and any non-standard search behavior. Test those cases against the authentik LDAP provider documentation and your own applications rather than assuming parity.

Does authentik's licensing change the plan for this migration?

Licensing affects which features you can use, so confirm it before the design is fixed. Most of authentik's code is under the MIT license, while code in the authentik/enterprise/ directory is under a separate enterprise license defined in that directory. The authentik pricing page lists an Open Source edition, an Enterprise edition and an Enterprise Plus edition, and some features are Enterprise-only. Enterprise-only items include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication and enhanced audit logging. If your LDAP migration depends on any of these, the cost and timeline must include the license. Ask for a written statement of which features the design uses and under which edition they are licensed, and have your legal or procurement team review it.

Which parts of the migration cost more to run after go-live?

Most recurring costs come from operating the platform rather than from the migration itself. The authentik architecture includes a server container, a worker container and PostgreSQL, which stores configuration and data, so hosting and database capacity recur after go-live. Upgrades recur as well, and the authentik security policy lists supported versions that receive security fixes, with security releases announced at least 24 hours in advance, so your team needs a process to apply them. Outposts such as the LDAP outpost must be kept on compatible versions. If you buy Enterprise support, its fees recur according to the subscription. Ask the proposal to separate one-time project work from recurring hosting, support, upgrade and monitoring effort.

How DeployOpen scopes, delivers and supports the OpenLDAP replacement

DeployOpen plans the move from a standalone OpenLDAP server to the authentik LDAP provider as a written, fixed-scope engagement inside your own infrastructure. The work covers user sync, base DN and attribute mapping, MFA behavior for LDAP binds, testing against each bind-dependent application, and a handover your team can operate.

How we scope

We inventory every application that binds to the current OpenLDAP server, including service accounts and the search filters each one uses.
The written scope lists which LDAP sources are imported into authentik first and which directory features are confirmed or excluded.
We document the base DN, OU layout and attribute mapping each client expects before any build work starts.

How we build

We configure the LDAP source to import users and groups from the existing directory into authentik before any client is repointed.
We deploy the authentik LDAP outpost in your environment and set the LDAP provider base DN to match the client expectations.
We test each client bind, group lookup and MFA prompt in a staging environment and record the results against the agreed scope.

How we hand over

You receive configuration documentation covering sources, providers, outposts, bind flows and the attribute mappings in use.
We provide a cutover runbook with per-application steps, rollback points and the checks to run after each repointing.
Handover includes a list of directory features the authentik LDAP provider does not offer, with the workarounds agreed in scope.

How we support

Ongoing support, version upgrades and continuous testing are available as retainers after handover.
Support can cover outpost upgrades, sync troubleshooting and periodic review of LDAP bind behavior as applications change.
Before any retainer starts, confirm response expectations, covered components and upgrade responsibilities in the written agreement.

Replacing an OpenLDAP server with the authentik LDAP provider