FreeIPA vs Samba AD vs OpenLDAP: which to choose

Which directory fits your estate: FreeIPA vs Samba AD vs OpenLDAP

Choose FreeIPA when your estate is mostly Linux and UNIX and you need Kerberos single sign-on, host-based access and sudo policy, and a built-in certificate authority, all managed from one place. Choose Samba AD when Windows clients must join a domain controller that behaves like Active Directory. Choose OpenLDAP when applications need a bare LDAPv3 directory and you are willing to assemble the rest yourself. None of the three is a drop-in replacement for every Active Directory workload, so the decision rests on your client mix and on which skills your team already has.

The decisive condition for FreeIPA is a Linux-first estate where Kerberos, host policy and certificates are the real requirements. FreeIPA bundles 389 Directory Server, an MIT Kerberos KDC and the Dogtag certificate authority, and it can establish a cross-forest trust so AD users reach Linux resources. Samba AD matters when a Windows domain controller is the requirement, since it runs as an AD-compatible DC on the Heimdal Kerberos KDC. OpenLDAP fits when the job is a directory for applications, not an identity platform: slapd gives you LDAPv3, replication and strong authentication, but Kerberos, DNS and certificate issuance are yours to design and operate.

Before you shortlist, confirm three things with your own environment. Count the Windows clients and whether they must join a domain or only authenticate to applications. Check whether any Windows Server or Samba functional level you need is supported by the candidate, using the supplied Samba functional level history as the starting point. Then inventory who on your team can run Kerberos, LDAP schema and replication. The skills gap usually decides the platform before the feature list does, and it shapes the ongoing support cost more than the license terms, which are all open source for these three options.

Which directory to pick for each scenario

This table maps common estate shapes to the directory that fits best, with the condition that would change the choice. Read each row by matching your largest pressure first, such as Kerberos and sudo policy, Windows domain controllers, LDAP-only applications or an existing AD forest. Confirm each condition against your own estate before you commit.

Scenario	Best fit and reason	When the choice changes
All-Linux estate needing Kerberos single sign-on and sudo or host policy	FreeIPA. It bundles 389 Directory Server, an MIT Kerberos KDC, a Dogtag certificate authority, and host-based and sudo policy in one platform, so you do not assemble those parts yourself.	If you only need a plain LDAP store and will not use Kerberos or certificates, a standalone directory may be simpler to run.
Windows clients that need a domain controller	Samba AD. It runs as an Active Directory compatible domain controller for Windows clients, using samba-tool for administration. FreeIPA and OpenLDAP do not act as Windows domain controllers.	If you run only Linux clients and have no Windows domain requirement, Samba AD adds an AD-style domain you may not need. Confirm the Windows functional levels your clients require against the Samba functional level guidance.
Applications that only need LDAP logins	OpenLDAP. It is a standalone LDAPv3 server with slapd, replication options and a permissive OpenLDAP Public License, so you can place it behind applications without a full identity suite.	If you later need Kerberos, certificates or host policy, you will build those yourself on OpenLDAP. At that point, FreeIPA may be the lower-effort choice.
Mixed estate where an existing AD forest must keep running	FreeIPA with a cross-forest trust, so AD users reach Linux resources while AD stays the Windows authority. Confirm that the IPA DNS domain does not overlap with any AD domain in the forest.	If you are replacing AD rather than coexisting with it, the trust model may not suit you. A Samba AD domain controller is an option if Windows clients must be served without retaining AD.
Replacing AD for both Windows and Linux clients	Samba AD for the Windows domain, paired with FreeIPA only if Linux-specific Kerberos and host policy must be run alongside it. Plan the two as separate domains and test client behavior first.	If Linux policy needs are small, a single Samba AD domain may cover the estate. If Linux identity is the main need, FreeIPA with Windows clients served through a trust may be the better fit.
Samba file serving alongside directory services	Separate file serving onto a Samba domain member. The Samba wiki advises against using an AD DC as a file server when there are multiple DCs.	A single-DC lab or small site may tolerate combined roles, but confirm this against the current Samba guidance before production use.
Team with no identity engineering staff	Plan for the skills gap before choosing. FreeIPA concentrates more features in one product, while OpenLDAP requires you to design the surrounding services. Ask for a written operating scope before you pick.	A managed service or a retained implementation partner can change the staffing answer. Confirm roles and support hours in writing before you rely on either.

How FreeIPA vs Samba AD vs OpenLDAP differ on Kerberos, replication and DNS

This table sets the three self-hosted directories side by side on license, Kerberos, replication, DNS, Windows client support, backup tooling, the LDAP server each builds on and admin tooling. Read each row as a question to answer for your estate: if Windows domain controllers must be replaced, Samba AD and FreeIPA diverge sharply; if you only need an LDAP tree, OpenLDAP may be the leaner fit.

Capability	FreeIPA	Samba AD	OpenLDAP
License	GPL-3.0-or-later, community project with no paid edition	GPL-3.0	OpenLDAP Public License, described by the project as non-restrictive and open source
Kerberos implementation	MIT Kerberos KDC for single sign-on	Heimdal KDC by default, with experimental MIT Kerberos support in Samba 4.7 or later when built against system MIT Kerberos	No Kerberos KDC; Kerberos must come from a separate system
LDAP server each builds on	389 Directory Server	Samba's own AD DC directory services, presenting an Active Directory schema	slapd, the stand-alone OpenLDAP server
Replication model	Multi-master LDAP replication across at least two to three replicas per datacenter, with a limit of four replication agreements per replica in the deployment guidance	Multi-DC replication that follows Active Directory domain controller behavior, where all DCs in a domain hold directory data	Single-provider with multiple consumers, or multi-provider replication where a single point of failure is not acceptable
DNS	Optional integrated ISC BIND DNS; PKI or DNS replicas should run in each datacenter if used	Supported backends are SAMBA_INTERNAL and BIND9_DLZ; NONE is discouraged and BIND9_FLATFILE is not supported	No built-in DNS; DNS is provided by an external service
Windows client support	Windows clients join through Active Directory trusts rather than as domain members	Windows clients join as members of a Samba AD domain; functional levels run from 2008 R2 to 2016 level	Not a Windows domain controller; Windows clients reach it only through LDAP-aware applications
Backup tooling	ipa-backup and ipa-restore with full or online data-only backups; restoring an outdated backup into an active replica topology can break replication	Backup and restore handled through Samba AD tooling and database procedures; confirm the exact procedure for your release	Backup through slapcat and the database backend; consistency rules depend on replication setup
Admin tooling	FreeIPA command line and web UI	samba-tool for domain administration, including raising functional levels	slapd configuration, LDIF tools and command line LDAP utilities
Skills to operate	Linux administration, Kerberos, certificate authority and DNS operations	Windows domain concepts, Samba internals and DNS design	LDAP schema design, replication topology and building Kerberos or SSO separately

How Windows clients join each option and what changes for AD users

Windows client support is the sharpest difference between these three options. Samba AD is the only one of them that can act as an Active Directory compatible domain controller, so Windows machines can join it as a domain and use it like a Windows domain. Samba supports the Windows Server 2008 R2 functional level since Samba 4.0, the 2012 and 2012 R2 levels since Samba 4.19, and the 2016 level since Samba 4.20. Check the functional level you need against the Windows Server version on your clients and servers before you commit, and confirm domain join, group policy behavior and login in a lab built on that exact Windows Server version. Samba administers its domains with samba-tool, so Windows administrators will need to learn a new toolset for directory tasks.

FreeIPA does not present itself as a Windows domain controller. Windows users reach Linux resources through a cross-forest trust with an Active Directory domain, which requires Windows Server 2008 R2 or later and an IPA DNS domain that does not overlap with any domain in the AD forest. The trust keeps AD as the home for Windows identities, so existing Windows logons stay where they are. Confirm with your own lab which Kerberos and DNS settings your Windows clients need, and confirm how the trust behaves with your current Windows Server release. OpenLDAP offers no Windows domain join at all. It is an LDAPv3 directory server, so Windows machines cannot join it as a domain, and any Windows login depends on what you build around it.

For AD users, the practical change depends on which option you pick. With Samba AD, the directory itself moves to Linux, so you own domain controller replication, DNS and the upgrade path. Samba's wiki advises against using an AD DC as a file server when there are multiple DCs and recommends a separate Samba domain member for file serving, so plan the file servers as separate systems. With FreeIPA, AD accounts stay in AD, and the trust is the boundary you must maintain and monitor. With OpenLDAP, Windows users typically need a separate login path, so decide early whether they need domain logon at all.

What each license allows and what is paid

FreeIPA is licensed under GPL-3.0-or-later, and the project itself has no paid edition of its own. Its costs therefore come from the people who build, run and support it, the infrastructure that hosts its replicas, and any subscription you buy from a distributor. The project is packaged in Fedora, Debian and CentOS, and Red Hat sells it as Identity Management on Red Hat Enterprise Linux. The FreeIPA downloads page lists the packaging options.

Vendor-backed support: Red Hat's Identity Management on RHEL is tied to RHEL subscriptions. Confirm the support scope, the supported versions and whether a non-RHEL estate is covered before you rely on it.
Community support: Without a vendor contract, support comes from your own staff, community channels or an implementation partner. Budget for that effort as a recurring cost.
Packaged versions: Distribution repositories can lag behind upstream tags such as release-4-13-4. Confirm which build your distribution ships and whether it includes the latest security fixes.
Recurring costs: Without a license fee, spending concentrates on staff time for upgrades and testing, replica hardware or virtual machines, and any support contract. Ask each quote to separate these items.

Before you commit, confirm whether your regulator or internal policy requires a vendor-backed build and get the support terms in writing from the provider.

What drives running cost for FreeIPA, Samba AD and OpenLDAP

None of the three directories carries a license fee for the software itself, so running cost comes from servers, replicas, staff skills and the work needed to fill gaps. The cards below separate the recurring and one-time components and list what to request in a written quote.

No license fee for the software

FreeIPA is GPL-3.0-or-later, Samba is GPL-3.0, and OpenLDAP ships under the OpenLDAP Public License, so none of the three charges a license fee for the directory itself. The cost sits in the people and infrastructure around them. Ask any partner to separate software cost, which is zero here, from support subscriptions, which are optional and priced by the vendor or partner. FreeIPA is a community project with no paid edition of its own, so Red Hat's supported Identity Management is a different cost line to request if you need vendor support.

Replica and server count

FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, with no more than four replication agreements per replica and dedicated servers that run no other applications. Samba AD domain controllers and OpenLDAP provider pairs add servers in the same way, so the count of machines, their operating system support and their backup systems are recurring hosting costs. Ask for the replica count per site, the number of sites, and whether DNS or certificate services must also run on those hosts.

Staff skill mix

The largest recurring cost is usually people. FreeIPA needs administrators who understand Kerberos, certificate issuance and renewal, DNS and SSSD on clients. Samba AD needs Windows domain administration skills plus samba-tool and functional level planning. OpenLDAP needs deep LDAP schema and replication expertise. Ask a partner which roles it staffs, how many hours it assumes for run operations, and whether knowledge transfer to your team is in the scope.

Windows Server licensing if you stay on AD

Windows Server licensing applies only if you keep Microsoft Active Directory as the domain controller platform. Windows Server 2025 became available on November 1, 2024, with mainstream support ending November 14, 2029. Moving to FreeIPA or Samba AD removes the Windows Server core and client access license lines for the directory, but a Windows estate may still need licenses for other servers. Ask your Microsoft licensing advisor which of your current licenses are tied to domain controllers and which are not.

Labor to build what OpenLDAP leaves out

OpenLDAP is a standalone LDAPv3 server with replication, SASL and TLS, but it does not supply Kerberos, a certificate authority, DNS, host policy or sudo and HBAC rules. Each gap becomes a build-and-maintain task with its own design, testing and upgrade work. Ask for the list of components the quote includes, who owns the integration code, and how upgrades of those components are tested against the directory.

One-time migration and recurring upgrades

Migration effort is one-time, while patching, upgrades and backup testing recur. FreeIPA can migrate users and groups from other LDAP servers with ipa migrate-ds, but sudo and HBAC rules need manual LDIF work. Samba AD requires functional level planning, and OpenLDAP requires schema mapping. Ask for the migration scope as a fixed deliverable, the test cycle before cutover, and a written upgrade plan for the first year.

What implementing each directory involves day to day

FreeIPA's day-to-day work centers on the replica topology. Its deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, and dedicated servers without other applications, so the team must map sites and replicas before the first install. Backups use ipa-backup and ipa-restore, with full or online data-only modes. The backup documentation warns that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication. Write a restore runbook that names which server is restored, and rehearse it in a non-production topology before you need it. Confirm with the FreeIPA project how your chosen release handles these steps, since the FreeIPA backup and restore page is the authoritative reference.

Samba AD work is mostly administration through samba-tool, which handles user, group and domain tasks, including raising functional levels. The Samba wiki documents support for the 2008 R2 level since Samba 4.0, the 2012 and 2012 R2 levels since Samba 4.19, and the 2016 level since Samba 4.20, so a team migrating from older Windows domain controllers should plan level raises as discrete, tested changes. The DNS backend is a decision you make at provisioning: SAMBA_INTERNAL or BIND9_DLZ are supported, the wiki warns against the NONE backend, and BIND9_FLATFILE is not supported. Because each Samba release series receives six months of full support, six months of maintenance and six months of security fixes only, plan a regular upgrade cadence and confirm the current series dates on the Samba release planning page.

OpenLDAP shifts the most design work to your team. slapd is configured directly, its main MDB backend needs sizing and backup planning, and you choose between single-provider, multiple-consumer replication and multi-provider replication based on whether a single point of failure is acceptable. Schema, Kerberos and policy are not supplied out of the box: your team must design the object classes, authentication flows, password policy, group logic, and any sudo or host access rules. Migration from other directories is also manual work. The ipa migrate-ds command moves users and groups into FreeIPA from other LDAP servers, excluding Kerberos attributes that FreeIPA regenerates, but sudo and HBAC rules must be migrated by hand through LDIF. Before committing, ask whether your team has the LDAP schema and replication skills to own these pieces for the life of the service.

What buyers and practitioners ask before choosing a directory

How long does a directory migration take, and what drives the timeline?

The timeline depends on the size and shape of the existing directory, not on the product alone, so no fixed duration applies here. The main drivers are the number of users, groups, hosts and applications that bind to the directory, how many of those applications use hard-coded LDAP paths or Kerberos settings, and whether Windows clients will need a new domain or a trust. FreeIPA can import users and groups from other LDAP servers with the ipa migrate-ds command, but sudo and HBAC rules need manual migration through LDIF, and that manual work often takes the most time. For Samba AD, raising functional levels is a deliberate step with its own testing, documented in the Samba wiki. Ask the implementer for a written migration plan that lists each dependency and the test evidence it will produce before cutover.

Can our own team run FreeIPA or Samba AD without outside help?

Yes, many teams do, but only if they already have the skills the platform assumes. FreeIPA combines 389 Directory Server, MIT Kerberos, a Dogtag certificate authority and optional DNS and NTP, so operators need working knowledge of LDAP, Kerberos, DNS and PKI. Its deployment guidance calls for multiple replicas per datacenter, dedicated servers and careful backup handling, because restoring an outdated backup into an active replica topology can break replication. Samba AD requires administration through samba-tool and a good understanding of Windows domain concepts such as FSMO roles, Group Policy and DNS. Confirm your staff's experience with each stack, and ask whether knowledge transfer and runbooks are part of the agreed scope.

Can Samba AD fully replace Active Directory for every Windows workload?

No single open-source domain controller should be assumed to cover every Windows workload without testing. Samba AD supports the 2008 R2, 2012, 2012 R2 and 2016 functional levels, according to its wiki, but that does not mean every Microsoft feature, management tool or third-party integration behaves the same way. The Samba wiki also advises against running an AD DC as a file server when multiple DCs exist, so file services need a separate member server. Inventory your Group Policy use, certificate services, Exchange or other Microsoft products, and any applications that rely on specific AD behavior. Then verify each item in a lab against the functional level you plan to run before deciding what stays on Windows Server.

What does the work need from our own staff?

Your staff provides the knowledge of your environment, the decisions only you can make and the access to run the work. Expect to name owners for identity data, approve the target design, supply test accounts and change windows, and confirm which applications and hosts bind to the directory. Security and compliance staff should own the decisions on certificate authority design, password and MFA policy, and evidence retention. Ask the implementer to list these tasks in the written scope, so each one has a named owner and a date agreed before work begins.

Can OpenLDAP be extended to match FreeIPA's Kerberos and CA features?

OpenLDAP can be combined with other components to approximate parts of FreeIPA, but it does not ship them as an integrated suite. OpenLDAP provides slapd, a standalone LDAPv3 server with SASL, TLS certificate authentication, MDB storage and replication options. Kerberos, certificate issuance, DNS and host-based policy would be separate projects that you select, install, integrate and maintain yourself. That means more design work, more upgrade paths to track and more evidence to produce for an assessor. Confirm with your architect which components you would own, how they would be backed up and who supports each one.

What should a quote cover for each directory option?

A useful quote separates the one-time work from the recurring work and states what is in and out of scope. For FreeIPA and Samba AD, the one-time items usually include design, installation, replica layout, DNS and certificate decisions, migration of users and policies, testing and knowledge transfer. Recurring items include patching, backup verification, upgrades and support, which can be delivered through retainers. OpenLDAP quotes should also cover each separately chosen component, its integration and its ongoing maintenance. Licensing differs too: FreeIPA is GPL-3.0-or-later with no paid edition of its own, Samba is GPL-3.0, and OpenLDAP is under the OpenLDAP Public License. Ask for a written scope with deliverables and timelines agreed before work starts, and for each assumption about your environment to be listed.

How DeployOpen helps choose and implement the right directory

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. We start by working out which directory fits your Windows, Linux and application estate, then deliver the chosen option in your cloud accounts, data centers or air-gapped networks.

How we scope

Inventory which clients, servers and applications must authenticate, including Windows, Linux and LDAP-only consumers.
Confirm whether Kerberos, host-based policy, certificates or Active Directory trusts are required or only nice to have.
Agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.

How we build

Design the replica topology, DNS layout and backup approach for your sites before any server is installed.
Build the chosen directory in your environment, then integrate clients, applications and any existing Active Directory domain.
Test authentication, replication failover and restore procedures against the scope, and document the results.

How we hand over

Deliver runbooks covering administration tasks, replica management, certificate and backup routines for your operators.
Walk your administrators through daily operations, so the team can run the directory without outside help.
Provide the configuration and evidence your compliance assessors will need, while noting that independent auditors issue any formal assessment.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer once the directory is in production.
Plan upgrades against each product's own release and support windows, and confirm those dates with the vendor or project.
Ask for a quote based on the written scope, since DeployOpen does not publish a price list.

FreeIPA vs Samba AD vs OpenLDAP