OpenLDAP vs LLDAP: which to choose

OpenLDAP or LLDAP: which directory fits your applications

Choose OpenLDAP when your applications need full LDAPv3 behavior, replication, overlays, or direct reads of password hashes, and choose LLDAP when a small user and group store with a web UI backs a few applications and your in-house team accepts a volunteer-maintained project. The decision turns on four questions: which LDAP features your applications actually call, whether each application can validate users without contacting the directory, how much availability you need, and who will maintain the system after go-live. Start by listing every application that will bind to the directory and checking whether it needs search filters beyond simple lookups, schema extensions, or hashed passwords it validates locally. LLDAP's own README states that services needing password hashes to validate users without contacting LLDAP are not and will not be supported, so that single check often settles the question.

OpenLDAP is the general-purpose option. The OpenLDAP 2.6 Administrator's Guide describes slapd as implementing LDAPv3 over IPv4, IPv6 and Unix IPC, with SASL and TLS authentication, and it supports single-provider replication and multi-provider replication when a single point of failure is not acceptable. If your design needs those features, the cost is operational: you will write and review slapd configuration, manage schema and access controls, and plan replication yourself. LLDAP trades that flexibility for simplicity. Its FAQ says it is much simpler to set up and has a far smaller image, but that it is not as flexible, and it states that it is not a full LDAP server. Confirm with each application vendor which LDAP operations and password schemes it requires before you commit to either option.

Maintenance is where the two differ most for regulated teams. OpenLDAP is developed by the OpenLDAP Project under the OpenLDAP Foundation, and the current releases are 2.7.1 and 2.6.15, with 2.6 as the long term support line. LLDAP's latest release is v0.6.3, published April 30, 2026, and its FAQ describes it as volunteer-developed software with a bus factor of one, offering no commercial support and not recommended for large organizations unless you can audit and maintain the code. Ask your team who will own schema changes, backups, TLS certificates and upgrades, and whether anyone can support a directory outage at night. If the answer is unclear, the self-hosted OpenLDAP path with a documented support plan usually fits better than a single-maintainer tool, and a fixed-scope engagement can cover the build and handover.

Which scenarios favor OpenLDAP and which favor LLDAP

This table maps common deployment scenarios to the platform that fits each one better, with the condition that drives the choice. Read each row as a decision test: if the condition describes your environment, the named option is the stronger starting point.

Scenario	Better fit	Condition that drives the choice
Regulated enterprise with several directory-dependent systems	OpenLDAP	Needs full LDAPv3 behavior, schema control, replication and overlays because many applications and integrations query the directory directly. LLDAP's FAQ says it is not recommended for the infrastructure of a big organization unless you are prepared to audit and maintain the code.
Homelab or small team with a handful of applications	LLDAP	Sign-in is the main need and one administrator manages users in a web UI. LLDAP's FAQ says it is much simpler to set up and has a far smaller image than OpenLDAP.
Multi-site deployment that cannot tolerate a single point of failure	OpenLDAP	Requires provider and consumer replication across sites. OpenLDAP supports multi-provider replication for environments where a single point of failure is not acceptable. LLDAP's README says it does not aim to provide a full LDAP server.
Team that needs a web UI for daily user administration	LLDAP	Helpdesk staff add users, manage groups and reset passwords in a browser. LLDAP ships a web front end, while OpenLDAP's FAQ-stated counterpart ships without one, so a separate tool or workflow is needed.
Application that validates password hashes directly against the directory	OpenLDAP	The application needs the hash itself. LLDAP's README says services that need password hashes to validate users without contacting LLDAP are not and will not be supported. Confirm the application's bind method before choosing.
Applications that browse the directory with LDAP tools	OpenLDAP	Administrators or applications use standard LDAP browsers or schema-aware clients. LLDAP's README says LDAP browsing tools are generally not supported.
Single identity store feeding Keycloak or Authelia for OIDC and SSO	LLDAP	The directory only needs to act as a source of truth for users and groups, and the SSO layer handles OAuth, OpenID or reverse proxy features. LLDAP's README suggests this pattern.
Several isolated customer or business units in one directory	OpenLDAP	Each unit needs its own namespace under a shared server. LLDAP does not natively support virtual hosts or multi-tenancy, and its FAQ suggests one instance per virtual host instead.

How OpenLDAP and LLDAP are built and what that means for operations

OpenLDAP is a full directory server and proxy suite that you tune and operate. LLDAP is a small server with a web UI and a deliberately narrow LDAP surface. The cards below cover the design differences that decide how much work each one puts on your team and which applications can use it.

slapd and the MDB backend

slapd implements LDAPv3 over IPv4, IPv6 and Unix IPC, with SASL and TLS certificate authentication. Its main database backend is MDB, a transactional store built on LMDB. Operationally, this means you own schema design, ACLs, TLS certificates and backup procedures through configuration rather than a web console. Check that your applications need only the LDAP operations they call, since slapd exposes the full protocol and extensions.

Replication topologies

slapd supports single-provider, multiple-consumer replication and multi-provider replication for environments where a single point of failure is not acceptable. Choosing between them is an architecture decision you make early, because it sets how writes flow and how conflicts are handled. LLDAP has no comparable replication design in its documentation, so a single LLDAP instance is your availability boundary. Confirm the replication model with your own recovery time requirements before you commit.

Caching proxy and lloadd

slapd can act as a caching LDAP proxy, while lloadd is a separate stand-alone LDAP load balancing proxy shipped with OpenLDAP 2.7. Running lloadd adds another component to deploy, monitor and secure, but it lets you spread client connections across directory servers without changing applications. LLDAP does not ship a proxy or load balancer in its documentation. If you expect many clients against one directory, plan the proxy tier as its own piece of work.

Single base DN and GraphQL API

LLDAP does not natively support virtual hosts or multi-tenancy: all users sit under one base DN, and the FAQ suggests running one instance per virtual host. Administration is scriptable through a GraphQL API, and custom attributes can be managed in the web UI or with a community CLI. This suits a single organization with a simple tree. If you need several directory trees or a fixed DIT layout that other systems expect, OpenLDAP's configuration model is the better fit.

SQLite default and external databases

LLDAP stores its data in SQLite by default and can use MySQL, MariaDB or PostgreSQL instead, with documented migration away from SQLite. The SQLite default keeps a single-host install simple, but moving to a shared database is the step that makes backups, failover and upgrades routine for a team. OpenLDAP stores its directory in its own backend rather than a relational database, so there is no equivalent database choice to make. Confirm the database and backup procedure your operations team will run.

Install paths and footprint

LLDAP installs from OCI images with Docker or Podman, on Kubernetes or TrueNAS, from distribution packages, or from source. Its FAQ says it runs in under 10 MB of RAM including the database, with an image about 10 times smaller than OpenLDAP's. OpenLDAP is installed from packages or built from source and is configured through slapd settings. Ask your platform team which packaging and deployment path your standard image pipeline supports, since that often decides the effort more than image size does.

Capability by capability: what each directory implements

This table compares what OpenLDAP's slapd and lloadd implement against what LLDAP exposes through its deliberately narrower interface. Read each row as a question to ask your applications: if the application needs a capability LLDAP does not provide, OpenLDAP or another directory is the safer fit.

Capability	OpenLDAP (slapd and lloadd)	LLDAP
LDAPv3 coverage	Implements all of LDAP and its extensions, per LLDAP's own FAQ comparison	Partial LDAP interface, opinionated and simplified; the project states it is not a full LDAP server
Replication	Single-provider, multiple-consumer and multi-provider replication for designs without a single point of failure	No replication feature described in the supplied project documentation; confirm with the maintainers before relying on it
Overlays and extensions	Overlay architecture is part of slapd; confirm the specific overlays you need in the 2.6 or 2.7 documentation	Not described; treat custom server-side behavior as unsupported
Load balancing	lloadd is a stand-alone LDAP load balancing proxy shipped with OpenLDAP 2.7	Not described; LLDAP documentation does not present a load-balancing component
Caching proxy	slapd can act as a caching LDAP proxy	Not described
Web UI	No bundled web UI; LLDAP's FAQ notes OpenLDAP ships without one, so administrators add a separate tool	Built-in web front end for managing users and groups and for self-service password reset by email
API access	Administered through LDAP operations and command line utilities	GraphQL API and community CLI for custom attributes
Storage backends	MDB, a transactional backend built on LMDB, is the main database backend	SQLite by default; MySQL, MariaDB or PostgreSQL as alternatives, with documented migration away from SQLite
Password hash handling	Stores credentials under directory controls; a poor configuration can leave passwords in clear, so review the password policy and TLS settings	Services that need password hashes to validate users without contacting LLDAP are not and will not be supported
Virtual hosts and multi-tenancy	Multiple naming contexts and access controls are designed into slapd; confirm your layout against the admin guide	Not supported; all users sit under one base DN, and the FAQ suggests one instance per virtual host
Browsing tool support	Works with standard LDAP browsing tools	LDAP browsing tools are generally not supported; Synology is the only service known to be definitely incompatible

Licensing and what each project includes

OpenLDAP Software is available under the OpenLDAP Public License, which the project describes as a non-restrictive, free, open-source license. It is developed by the OpenLDAP Project, a team of volunteers, as an organized activity of the OpenLDAP Foundation, and is derived from University of Michigan LDAP release 3.3. The current releases are feature release 2.7.1 and long term support release 2.6.15, so a production deployment usually chooses between the LTS line and the newer feature line.

License: The OpenLDAP Public License permits use, modification and redistribution under its terms, with no paid edition to purchase.
Releases: Feature release 2.7.1 and long term support release 2.6.15 are the current lines, per the OpenLDAP website.
Server and proxy: The package includes slapd, the stand-alone LDAP directory server, and lloadd, a stand-alone LDAP load balancing proxy.
Tooling: Client libraries, LDIF tools and command line LDAP utilities ship with the release.
Retired components: OpenLDAP 2.7 retired the back-sql and back-perl backends and deprecated the GnuTLS integration, which matters if your configuration depends on them.

Confirm with your legal team whether the OpenLDAP Public License terms fit your redistribution model, and check which release line your vendor or distribution packages.

What LLDAP does not implement and why it matters

The first thing to know is that LLDAP is not a full LDAP server. Its README says the goal is not to provide one and points users who need a complete implementation to OpenLDAP. In practice, LLDAP exposes a deliberately narrow LDAP interface built for authentication and group lookups. Two README statements matter most for your shortlist. First, services that need password hashes to validate users without contacting LLDAP are not supported and will not be. Second, LDAP browsing tools are generally not supported. Synology is the only service the README names as definitely incompatible. Treat that list as the project's own known-issues record, not as a complete compatibility matrix, and confirm each application against the current README before committing.

The second gap is for OAuth, OpenID Connect and reverse proxy features. LLDAP does not provide them. The README suggests pairing it with a companion such as Keycloak or Authelia, with LLDAP acting as the source of truth over LDAP. That design adds a component to deploy, patch, back up and monitor, and it moves the single sign-on decision to the companion. If your applications expect a directory that also issues tokens or enforces access at a proxy, budget for that second system from the start. Ask the vendor or project of each companion which LDAP attributes and group structures it expects.

Before choosing LLDAP, run a short test against your own applications. Confirm that each one binds with a service account and validates credentials through an LDAP bind, not by reading password hashes. Confirm that none of them requires a hashed password attribute, and that any administrative tool you rely on for browsing the directory works with LLDAP's interface. Check group membership lookups, nested groups and the attributes each application reads. Finally, confirm how the application behaves when LLDAP is unreachable. If any answer depends on a feature you cannot verify, OpenLDAP's full slapd implementation is the safer baseline, and the OpenLDAP project site is where to confirm its current release line.

What drives running cost for each directory

Running cost for a directory is mostly people time: who configures it, who patches it, and who answers when it breaks. The cards below cover the footprint figures LLDAP publishes, the skills OpenLDAP's configuration model demands, and the support gap that matters most for a regulated estate.

Infrastructure footprint

LLDAP's FAQ says it runs in under 10 MB of RAM including its database and that its image is about 10 times smaller than OpenLDAP's, or 20 times smaller with PhpLdapAdmin added. Those are the project's own figures, so measure them on your hardware. A small footprint lowers hosting cost, but it does not remove the need for backups, monitoring and a tested restore for either server.

Staff skills for OpenLDAP

OpenLDAP is configured through a flexible model: schema, database backends, overlays, ACLs and replication all need to be set and reasoned about. The FAQ describes LLDAP as much simpler to set up but less flexible. Budget for staff who can read the 2.6 Administrator's Guide and test ACL and TLS changes before they reach production.

No commercial support from LLDAP

LLDAP offers no commercial support. Its FAQ calls it hobbyist software developed by volunteers with a bus factor of one. For a regulated service that authenticates staff, ask your team whether an outage, security fix or urgent patch has a named responder and a response expectation. If not, that risk moves to your own staff or to a third party.

Audit and maintenance burden

The LLDAP FAQ says it is not recommended for the infrastructure of a big organization unless you are prepared to audit and maintain the code. That is a recurring cost: someone must track releases, review changes and test upgrades. OpenLDAP also needs this discipline, but its 2.6 LTS and 2.7 release lines give a clearer patching path to plan around.

Upgrade and migration effort

Upgrades recur for both products. OpenLDAP upgrades depend on which release line you run, with 2.6.15 as the current long term support release and 2.7.1 as the feature release. LLDAP's latest release is v0.6.3, published April 30, 2026. If you start on SQLite, plan a migration to MySQL, MariaDB or PostgreSQL before the store grows, and test it in a copy first.

Third-party support to request

Neither product's vendor is in the supplied sources as a support seller, so ask who provides hands-on help. Request, in writing, the scope of any support contract, response targets, which versions are covered, and whether a partner will harden, back up and document the setup. Use the same list for both products so the quotes compare cleanly. Ask for every item as a separate line.

Moving between OpenLDAP and LLDAP later

This sequence shows how to move directory data and application logins between OpenLDAP and LLDAP without losing users, groups or access, in either direction. It ends with each application tested against the new directory and a cutover that has a documented way back.

Inventory every application that binds to the directory
List each application, appliance and script that talks to the directory, and record its bind account, search base, filters, the attributes it reads and writes, and whether it checks password hashes locally or sends a bind request to the server. Include backup jobs, VPN concentrators, NAS devices and reverse proxies, since these are the systems most often missed. The step is done when every consumer has a row in the inventory and an owner who has confirmed the details. LLDAP's README states that services needing password hashes to validate users without contacting LLDAP are not supported, so this check decides whether LLDAP can serve a given application at all.
Confirm schema, attributes and password requirements
Compare the object classes and attributes each application expects with what the target directory provides. OpenLDAP lets you load custom schema, while LLDAP manages a fixed set of user attributes plus custom attributes through its web UI or GraphQL API, so any attribute an application needs must exist on the target before data moves. Decide how passwords will be handled, because migrating hashed passwords is only possible when the target accepts the same hash scheme. The step is done when a written mapping shows each source attribute, its target, and any attribute that will be dropped or replaced.
Export and map users, groups and memberships
Export the source tree as LDIF or through the LDAP search tools, then transform entries to the target naming, base DN layout and group model. Users, groups, group memberships and plain attributes such as names, mail addresses and department values carry over with the mapping in hand. Because LLDAP places all users under one base DN and does not offer multi-tenancy, a source directory that uses several subtrees for separate populations needs an explicit flattening decision. The step is done when a test import into a non-production target produces the same user and group counts as the source, and a sample of entries matches attribute by attribute.
Rebuild password handling and login paths
Set up the password path for the target. Where the source hashes can be carried over and the target accepts them, load them under a tested configuration. Where they cannot, plan a controlled reset or a first-login process, and confirm how users will change passwords afterwards, including email-based reset if the target offers it. Confirm that any replication or sync design, such as OpenLDAP's syncrepl-based replicas, or LLDAP's single-instance model, meets the availability the applications need. The step is done when a test user can authenticate to each application through the new path and a failed login is rejected and logged.
Recreate application bind configuration and access policy
Update each application's bind DN, bind password, search base, filters and TLS settings to point at the target, and rebuild any access rules that previously relied on source-specific groups, ACLs or overlays. Access policy rarely transfers automatically, so re-derive it from the inventory and have the application owners sign off. Record the new configuration in the runbook so the next person knows where each setting lives. The step is done when each application's configuration has been changed in a staging environment and reviewed, and the owner has written approval for the access model.
Test each application against the target directory
Run a scripted test for each application that covers a successful login, a failed login, a password change where supported, group-based authorization, and any scheduled job that reads the directory. Include a directory browsing or export check if an administrator depends on one, since LLDAP's README says LDAP browsing tools are generally not supported. Keep results per application so a failure can be traced to a single change. The step is done when every test passes on the staging target and the failures found earlier are closed with a written note.
Cut over and keep the source available for rollback
Freeze changes on the source directory for an agreed window, run a final delta export, apply the application configuration changes in the same order they were tested, and confirm authentication from each consumer. Keep the source server read-only and running until the rollback point has passed, so you can revert the application configuration if a problem appears. The step is done when all consumers authenticate against the target, the cutover record names who approved it, and the source is archived with its LDIF export and configuration files.
Update the operating runbook and support path
Rewrite backup, restore, patching, certificate renewal and user lifecycle procedures for the new platform, and confirm who supports it. OpenLDAP is backed by the OpenLDAP Project and its releases, while LLDAP offers no commercial support according to its FAQ, so an organization on LLDAP should decide in advance who maintains the code. Ask any implementation partner for a written scope covering these procedures before work begins. The step is done when the runbook has been walked through by the operators who will use it and a support arrangement is recorded.

Where OpenLDAP and LLDAP implementations usually run long

OpenLDAP usually runs long in design and configuration, not in installation. The server itself is a stand-alone slapd process, but a production deployment means deciding the directory schema before data arrives: object classes, attribute types, naming contexts and how applications will query them. Plan time for TLS certificate management and SASL mechanisms, since the server offers strong authentication through SASL and certificate authentication through TLS, and both need to be tested against every client that will bind. Replication is the largest block of work. Single-provider, multiple-consumer replication is simpler than multi-provider replication, and each choice needs a failover test, not just a successful sync. The LLDAP FAQ also warns that a poor OpenLDAP configuration can leave passwords stored in clear, so a review of password storage and access controls belongs in the scope from day one.

LLDAP usually runs long in compatibility testing and data decisions, even though its first setup is quick. The README states that services needing password hashes to validate users without contacting LLDAP are not supported, and that LDAP browsing tools are generally not supported, so each application you plan to connect must be tested for bind behavior and attribute needs before go-live. Database choice matters early: LLDAP uses SQLite by default and documents MySQL/MariaDB or PostgreSQL as alternatives, with a documented migration away from SQLite. Confirm which backend your operations team will back up and restore, and rehearse that migration if you expect to leave SQLite. Because LLDAP does not provide OAuth or OpenID features itself, the README suggests pairing it with components such as Keycloak or Authelia, which adds integration, configuration and testing work for each browser-based application.

Fixed-scope engagements should name these items in writing before work starts. For OpenLDAP, agree the schema and naming design, the TLS and SASL configuration, the replication topology with its failover and recovery tests, the password storage review and the list of client applications to test. For LLDAP, agree the application compatibility matrix, the database backend and any migration, backup and restore testing, and the companion components for OAuth or reverse proxy access. Ask the vendor or community for current support options, since LLDAP offers no commercial support, and confirm how the in-house team will maintain configuration after handover. Timelines and fees follow from that written scope, so the scope document is the first thing to agree.

Questions buyers ask before choosing OpenLDAP or LLDAP

Can LLDAP replace OpenLDAP as an enterprise directory?

For most enterprise directories, no. LLDAP's README says its goal is not to provide a full LDAP server and points users who need one to OpenLDAP. Its FAQ also says it is not recommended for the infrastructure of a big organization unless you are prepared to audit and maintain the code. LLDAP fits a small set of applications that need a simple user store with a web UI. If you need multiple virtual hosts, multiple tenants, or a broad set of LDAP clients, OpenLDAP is the closer match. If you want OAuth or OpenID features on top of LLDAP, its README suggests pairing it with a component such as Keycloak. Confirm your required LDAP operations and client list with application owners before deciding.

Does LLDAP support replication, and what does OpenLDAP offer?

The LLDAP material available to us does not describe replication, so treat it as unavailable until the maintainers confirm otherwise in writing. Its FAQ positions it as a lightweight server rather than a full LDAP server, and it recommends one instance per virtual host. OpenLDAP's slapd supports single-provider, multiple-consumer replication and multi-provider replication for environments where a single point of failure is not acceptable. It can also act as a caching LDAP proxy, and OpenLDAP 2.7 includes lloadd, a stand-alone load balancing proxy. Before go-live, have your engineers design the failover path, the consumer count and the clock and server ID rules, then test a primary failure end to end.

Can OpenLDAP serve applications that need password hashes?

OpenLDAP can, and LLDAP cannot for this use case. LLDAP's README says services that need password hashes to validate users without contacting LLDAP are not and will not be supported. OpenLDAP is a full LDAPv3 server that supports SASL and TLS, so applications that bind to the directory can validate credentials there. Whether an application needs readable hashes or only bind requests depends on that application and on the access controls you set for the password attribute. The LLDAP FAQ also warns that a poor OpenLDAP configuration can leave passwords stored in clear, so set the hashing scheme and attribute access rules deliberately. Confirm the authentication method with each application vendor and test a bind from every client before cutover.

What does each option cost to run, and what drives it?

Neither license charges a fee. OpenLDAP is under the OpenLDAP Public License, and LLDAP is free software under GPL-3.0. Your running costs come from hosting, storage, backups, a database if you use one with LLDAP, and staff time to operate and upgrade the service. LLDAP has the lighter footprint: its FAQ says it runs in under 10 MB of RAM including the database, and its image is about 10 times smaller than OpenLDAP's. OpenLDAP's effort rises with the number of replicas, overlays and sites you run. Design, build and migration are one-time costs, while hosting, monitoring, patching and support recur. When you request a quote, ask the provider to separate design, build, testing, handover and ongoing support, and to state the assumptions behind each line.

How much setup effort does each one need, and what must the team supply?

LLDAP is much simpler to set up, according to its FAQ. It installs from OCI images with Docker or Podman, on Kubernetes or TrueNAS, from distribution packages, or from source. OpenLDAP requires decisions on schema, directory tree layout, access controls, TLS certificates, backups and replication before it serves clients. Your team should supply an engineer who understands LDAP, a directory design, a list of client applications with their bind and attribute needs, a certificate process, and a tested backup and restore procedure. Our sources do not give a duration for either setup, so ask any implementer for a timeline tied to a written scope with named deliverables. DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

Can our own team run this without outside help?

Yes, if you have someone who can read LDAP filters, access control lists and TLS settings and who will own upgrades. LLDAP suits a small team that can keep a single instance patched and backed up. OpenLDAP suits a team that already runs directory services or can build that skill. Internal runbooks should cover schema changes, password reset flow, backups, replica monitoring and version upgrades. OpenLDAP's current releases are 2.7.1 and the long term support line 2.6.15, so choose the line that matches your upgrade cadence. Because LLDAP is volunteer-developed with a bus factor of one, plan upgrades and security fixes without assuming upstream will respond on your schedule. Keep at least two trained people on the directory.

What support options exist for OpenLDAP and LLDAP?

LLDAP offers no commercial support. Its FAQ calls it hobbyist software developed by volunteers, so your options are the project's documentation and community channels. OpenLDAP is developed by the OpenLDAP Project, a team of volunteers, as an organized activity of the OpenLDAP Foundation, so its base support is also community-led. Confirm whether any commercial support provider for OpenLDAP meets your response and coverage needs, and ask for response targets in writing. DeployOpen supports self-hosted platforms inside your own infrastructure, and ongoing support, upgrades and testing are available as retainers. Ask what is covered for LDAP specifically, including replication incidents and upgrade testing, before you sign.

How hard is it to switch from LLDAP to OpenLDAP later?

Switching is moderately hard because the directory models differ. LLDAP places all users under one base DN, so moving to OpenLDAP means designing a directory tree, mapping attributes and custom attributes, and updating every client's bind DN and search base. LLDAP stores its data in SQLite by default or in MySQL, MariaDB or PostgreSQL, and its documentation covers migration away from SQLite, but that helps only with storage. Export users and groups through the GraphQL API or LDIF, run both directories in parallel, and test each application's login path before cutover. Confirm the attribute mapping, password handling and rollback plan with your implementer before you start.

How DeployOpen helps choose, implement or migrate a directory

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a directory decision, we start by mapping which applications must bind to the directory and whether they need password hashes, replication or multiple base DNs, then write that scope down before any work begins.

How we scope

Inventory every application that will bind to the directory, including whether each one needs password hashes or direct LDAP queries.
Record replication, high availability and multi-tenancy requirements in the written scope before choosing a server.
Agree deliverables, timelines and acceptance criteria in writing, since most engagements are fixed-scope.
Confirm with each application vendor which LDAP features it depends on, such as schema extensions, overlays or memberOf support.

How we build

Deploy the chosen directory in your cloud account, data center or air-gapped network, using your own certificates and TLS settings.
Configure access control, password storage and schema for your applications, and test authentication paths end to end.
Set up backup, restore and monitoring so directory data can be recovered and changes are visible to your operators.
Where a migration from another directory is in scope, test data moves in a non-production copy before any cutover.

How we hand over

Document configuration, schema changes, bind accounts, backup procedures and the application integration map for your team.
Walk your administrators through routine operations such as adding users, resetting passwords and rotating service credentials.
Deliver written runbooks for upgrades and rollback, so your team can plan maintenance without relying on the original builders.
Provide evidence of configuration and controls that your auditors or assessors can review, without us issuing any attestation.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
Ask any quote to separate one-time build work from recurring retainer work, so you can see what recurs each year.
Confirm the support window, response expectations and escalation path in writing before the engagement starts.
Confirm with the directory project's maintainers which release lines and security fixes apply to your deployment.

OpenLDAP vs LLDAP