Samba AD vs OpenLDAP

The Samba project has stated that OpenLDAP is not supported as a Samba AD domain controller backend, and it has no plan to add one. Its FAQ gives four reasons: Active Directory needs features such as ACLs stored within the directory, the schema would still be the AD schema, no one is actively working on the backend, and the team has chosen not to pursue it. The first two points are technical. Samba AD expects the directory to hold security descriptors on objects and to follow the AD schema, and OpenLDAP is a plain LDAPv3 server with a flexible schema that does not provide that model out of the box. The last two points mean that a fix is not on a roadmap you can wait for. Read the Samba wiki FAQ directly before you plan around any future change.

For a buyer who hoped to place Samba AD in front of an existing OpenLDAP tree, the practical meaning is that Samba AD will manage its own directory database. Users, groups and computer accounts that live in OpenLDAP will not become AD objects by pointing Samba at that server. Any design that assumes one authoritative OpenLDAP tree feeding Samba AD needs a migration or a synchronization step, and that step has to be designed, tested and owned by someone. Ask your team which applications bind directly to OpenLDAP, which of them need Kerberos or AD group semantics, and whether any of them write to the tree. Those answers determine whether the directory data moves once, stays in place for non-Windows clients, or gets duplicated.

The practical options are to plan a one-time move of directory data into Samba AD, to keep OpenLDAP for the services that need plain LDAP, or to run both with a documented source of truth for each identity. The Samba FAQ notes that many people asking for an OpenLDAP backend run an NT4-style PDC on OpenLDAP and want to reach Samba AD without moving directory data by hand, so that migration path is the one the project has in view. Before committing, confirm with the Samba team and in your own lab which client versions, applications and LDAP schema extensions must survive the move, and test a restore of the data. Work with the Samba AD DC setup guide to size the lab before touching production.

The running cost of a directory is mostly people and redundancy, not licenses. Both Samba AD and OpenLDAP are open source, so the buyer pays for domain controller or slapd servers and their replicas, for the skills to run them, for patching across release series, and for any support contract chosen. For Samba AD, the skills are Kerberos, DNS, Group Policy and samba-tool administration. For OpenLDAP, the skills are LDAP schema design, access control rules, overlays and replication topology. Ask each vendor or partner to price the same number of replicas in each design, and to state which of those skills the quote assumes your staff already hold.

Design, migration and testing are one-time costs. For Samba AD, that includes the domain build, functional level planning and the join of any Windows domain controllers. For OpenLDAP, it includes schema work, overlay choices and any move of NT4-style directory data into a new tree. Recurring costs are patching, monitoring, backup restore tests and admin time. Samba publishes a support window for each release series: six months of full support, six months of maintenance and six months of security fixes only, so a domain on an older series must be moved on a predictable schedule. OpenLDAP's current feature release is 2.7.1 and its long term support release is 2.6.15, so check which line your team will standardize on before pricing upgrades. Confirm the support end date for the exact line in the vendor's own pages.

Before accepting a quote, request: a written list of servers and replicas with their roles; the named skills and hours assumed for design, migration, testing and each year of operation; the patch and upgrade cycle, including who performs release-series moves; the backup and restore test frequency; and what the buyer owns at handover, such as runbooks and schema or configuration in version control. For any vendor support agreement, ask for the covered release lines, response targets written as commitments, what is excluded (for example, custom overlays or schema extensions), the escalation path to upstream maintainers, and how renewal pricing changes. Illustrative example: a two-site design with four directory servers will recur patching and restore tests on every server, so the quote should show that work per server.

Implementing Samba AD starts with domain design: the forest and domain names, the number of domain controllers, and whether the estate will raise its functional level to match later Windows features. The DNS backend choice comes early because it shapes zones, forwarding and day-two operations. Functional levels are raised with samba-tool, and each raise should be treated as a one-way change that needs a rollback plan and a test domain first. Plan for file serving on separate Samba domain members rather than on the domain controllers, since the Samba wiki advises against using an AD DC as a file server when there are multiple DCs. Group Policy work is a separate track: confirm which policy settings your Windows clients actually need, test them against a lab client, and do not assume every GPO behaves as it does on Windows Server.

Implementing OpenLDAP is mostly design work done before any server is built. Schema design comes first: decide which object classes and attributes the applications need, and whether custom attributes must be added to the schema. Next come overlay and access control design, which determine who can read and change which attributes, and whether password policy and referential integrity are handled inside the directory or by the applications. The replication topology is a separate decision: slapd supports single-provider, multiple-consumer replication and multi-provider replication, and the choice depends on how much downtime the estate can accept. TLS and SASL setup must be settled early, because every client bind depends on it. Confirm with your application owners which bind methods and certificate chains each application supports before you commit to a design.

Projects usually run long in four places. First, client join and login testing: Windows and Linux clients each need their own join, DNS and time-sync checks, and a single failed client type can stall a cutover. Second, application LDAP assumptions: many applications hard-code attribute names, search bases or bind formats that differ between Samba AD and OpenLDAP, so each application needs its own test pass. Third, DNS, because a Samba AD domain depends on correct SRV records and resolver settings on every client, and those problems often surface only during login. Fourth, the migration of existing users and passwords. Passwords in an NT4-style domain or an OpenLDAP store may not move without a planned reset, and the Samba FAQ notes that people moving from an NT4-style PDC on OpenLDAP still need to get their directory data across by hand. Ask any implementation partner to scope these four areas explicitly in writing.