FreeIPA vs Samba AD: which one fits a Linux-first or a Windows-first estate
Choose FreeIPA when the estate is mostly Linux and UNIX hosts and the goal is central identity for them. FreeIPA bundles 389 Directory Server, an MIT Kerberos KDC for single sign-on, a Dogtag certificate authority and optional ISC BIND DNS, and it adds host-based access control and sudo policy on top. Choose Samba AD when Windows clients must join a domain and authenticate the way they do against Active Directory, because Samba runs as an AD compatible domain controller that uses the Heimdal Kerberos key distribution center. Both are GPL-3.0 projects, so neither requires a Microsoft license, but the Windows client and Group Policy requirements are what usually settle the question.
The decision turns on four things. First, the client mix: count the Windows workstations and servers that must join the domain and the Linux hosts that need Kerberos and policy, and treat any Windows-heavy mix as a Samba AD signal. Second, the policy model: if you need sudo rules, HBAC and an integrated CA, FreeIPA has them built in, while Samba AD leaves Linux policy largely to other tools. Third, the DNS design: FreeIPA expects at least two DNS servers in each client's resolv.conf and recommends replicas per datacenter, while Samba AD supports the SAMBA_INTERNAL and BIND9_DLZ backends and warns against the NONE backend. Fourth, the team's skills, since the Samba wiki advises against running an AD DC as a file server when there are multiple DCs, so plan a separate member server for file serving. Confirm the Windows functional level you need against the Samba wiki before committing, because Samba supports the 2008 R2 level, the 2012 and 2012 R2 levels, and the 2016 level in later releases.
Which scenarios favor FreeIPA and which favor Samba AD
This table maps common scenarios to the better fit between FreeIPA and Samba AD, with the reason and the condition that would reverse the choice. Read each row against your existing skills, your Windows client count and whether an Active Directory forest must stay authoritative. Use it to shortlist, then confirm each cited behavior in a lab before you commit.
| Scenario | Better fit | Why | What would change the answer |
|---|---|---|---|
| Linux-only fleet with central sudo and host policy | FreeIPA | FreeIPA bundles Kerberos single sign-on, sudo and HBAC rules with its LDAP directory for Linux hosts. | Adding Windows clients that must join a domain would add a Samba AD DC requirement. |
| Mixed Windows and Linux office needing a domain controller | Samba AD DC | Samba runs as an Active Directory compatible domain controller and is administered with samba-tool. | Windows features beyond Samba's AD DC scope need a lab check before you commit. |
| Existing AD forest that must keep Linux users reachable | FreeIPA with a cross-forest trust | FreeIPA can establish a cross-forest trust so AD users reach Linux resources on Windows Server 2008 R2 or later. | An IPA DNS domain that overlaps any AD forest domain blocks the trust, so plan names first. |
| Windows file shares hosted on domain controllers | Neither as the file server | The Samba wiki advises against an AD DC as a file server when multiple DCs exist and recommends a separate domain member. | Confirm this guidance against your own topology, since the advice is tied to multi-DC designs. |
| Certificate issuance from an integrated CA | FreeIPA | FreeIPA includes an integrated Dogtag certificate authority alongside its directory and Kerberos services. | If policy requires an existing enterprise CA, compare FreeIPA's CA setup options before installing. |
| Windows domain at a 2016 functional level | Samba AD DC | Samba supports the 2016 functional level since Samba 4.20, with 2012 and 2012 R2 levels since 4.19. | If your domain must run a newer functional level, confirm Samba support for that level first. |
| Small team with limited Linux or Windows administration skills | Depends on existing skills | Each platform needs trained operators, and FreeIPA's backup and replication rules add operating steps. | A team fluent in Windows AD leans toward Samba, while a Linux-experienced team leans toward FreeIPA. |
How FreeIPA and Samba AD are built and what that means for operations
FreeIPA and Samba AD both act as domain controllers, but they are assembled from different parts and aimed at different clients. The cards below cover the component bundle, the Kerberos implementation, DNS, replica planning and file serving, and what each choice means for the team that runs the directory.
FreeIPA is a bundle of components
FreeIPA combines the 389 Directory Server LDAP directory, an MIT Kerberos KDC, the Dogtag certificate system, and SSSD on client machines, with optional ISC BIND DNS and NTP. Operationally, that means one installer and one backup and restore process cover several services, but each component's behavior (certificate renewal, Kerberos tickets, directory replication) becomes part of your runbook. Check which pieces you need before you install, because DNS and certificates can be turned off or handled by an external CA.
Samba AD DC uses Heimdal Kerberos
A Samba Active Directory domain controller uses the Heimdal Kerberos key distribution center rather than MIT Kerberos. Samba also documents experimental MIT Kerberos support from version 4.7 when it is built against the system MIT library. For a Windows-centric estate this matters less than it sounds, since Windows clients speak the Kerberos that AD expects, but Linux admins who already maintain MIT Kerberos tooling should test their own keytab and ticket workflows before committing.
Samba administration runs through samba-tool
Samba AD domains are administered with the samba-tool command, including raising domain and forest functional levels. Teams that script user, group and DNS changes will write against this command set rather than a web console or the FreeIPA ipa CLI and API. Plan for that skill gap, and make sure changes are reviewed and recorded, because a functional level raise cannot be casually reversed and should be scheduled as its own change.
Choose the DNS backend deliberately
A Samba AD DC supports the SAMBA_INTERNAL and BIND9_DLZ DNS backends. The wiki warns against the NONE backend and states that BIND9_FLATFILE is not supported. Choosing SAMBA_INTERNAL keeps DNS inside Samba and simplifies a single-DC lab, while BIND9_DLZ integrates with an existing BIND deployment. Confirm which backend your DNS team can operate, because DNS failures break Kerberos and AD logons for both Windows and Linux clients.
Replica count and placement
FreeIPA's 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. They also advise at least one replica per datacenter running PKI or DNS if those services are used, and at least two DNS servers in each client's resolv.conf. Model your topology against these rules early, since replication design is hard to change once clients and certificates depend on it. Ask whether your Samba design will match that redundancy with equivalent DC placement.
Keep file serving off multi-DC domain controllers
The Samba 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. The operational consequence is a second server role to build, patch and back up, but it keeps DC resource use, file locking and maintenance windows from affecting authentication. Teams migrating a small Windows file server onto a Samba DC should budget for that extra host before cutover, and check whether FreeIPA's host model suits their file access needs.
Functional levels, DNS, trusts, tooling and licensing compared
This table sets FreeIPA and Samba AD side by side on the features that decide whether each one fits your estate, from license and Kerberos to functional levels, DNS and trusts. Read each row against the Windows and Linux clients you must support, since the rows cover server-side facts only. Where a row says to confirm, check it against your own test environment before you commit.
| Capability | FreeIPA | Samba AD |
|---|---|---|
| License | GPL-3.0-or-later, community project with no paid edition | GPL-3.0, community project maintained by the Samba team |
| Kerberos implementation | MIT Kerberos KDC, integrated with 389 Directory Server | Heimdal KDC by default, experimental MIT Kerberos support in 4.7 or later when built against system MIT Kerberos |
| DNS backends | Optional integrated ISC BIND DNS, with DNS over TLS between clients and IdM DNS servers added in 4.13.0 | SAMBA_INTERNAL and BIND9_DLZ backends; the wiki warns against NONE and does not support BIND9_FLATFILE |
| Functional levels | Managed through the IdM domain configuration; confirm the supported level set for your release | 2008 R2 since 4.0, 2012 and 2012 R2 since 4.19, 2016 since 4.20 |
| Trusts with Active Directory | Cross-forest trust with an AD domain on Windows Server 2008 R2 or later, using Samba components; the IPA DNS domain must not overlap any AD forest domain | Samba AD DC is itself an AD domain controller; confirm trust configuration against the Samba documentation for your topology |
| Two-factor options | HOTP (RFC 4226) and TOTP (RFC 6238), including YubiKey hardware tokens, with OTP checks proxied to an existing RADIUS server | Not covered by the supplied facts; confirm MFA options with the Samba team before design |
| Administration tooling | IdM web UI (new beta web UI introduced in 4.13.0) and command-line tools | samba-tool for domain administration, including raising functional levels |
| 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 | Not covered by the supplied facts; confirm backup and restore procedure for your DC topology |
| Current release | Newest tag release-4-13-4; 4.13.4 fixed two CVEs in July 2026 | Samba 4.25.0 stable, with 4.24.8 also available for download |
What GPL-3.0 means for FreeIPA and Samba AD in practice
FreeIPA is licensed under GPL-3.0-or-later, and the project is a community effort with no paid edition of its own. You can download, run, modify and redistribute it without a license fee. It is packaged in Fedora, Debian and CentOS, and Red Hat ships it in Red Hat Enterprise Linux as Identity Management. Which package you use determines which update stream, backports and vendor support you receive, so the distribution choice is part of the operating decision.
- No license fee: The GPL-3.0-or-later terms carry no per-user or per-server charge from the upstream project.
- Distribution packages: Fedora, Debian and CentOS each ship FreeIPA on their own release cadence, so patch timing depends on the distribution you choose.
- Red Hat build: Identity Management on RHEL is the packaged form Red Hat supports, and its support terms come with the RHEL subscription.
- Community support: Upstream help comes through public channels and project documentation, with no contractual response commitment.
- Recurring costs: Hosting, staff time for patching, backups and replica management, and any third-party support contract recur each year even though the software is free.
Before you commit, confirm with your distribution or Red Hat which FreeIPA version and support window applies to your platform, and ask any implementation partner to state in writing who handles security patches and upgrades.
Samba is licensed under GPL-3.0, so the license terms match FreeIPA's core license family but the project and release model differ. Samba 4.25.0 is the current stable release, and Samba 4.24.8 remains available for download. Each release series gets six months of full support, then six months in maintenance mode, then six months of security fixes only. Samba 4.25 started in September 2026, so the series you deploy determines how long you receive routine fixes.
- GPL-3.0 license: Samba carries no license fee for running it as an Active Directory compatible domain controller.
- Six months full support: Each new series receives full fixes for the first half of its life.
- Six months maintenance: The next phase accepts fixes with less frequent releases, so plan upgrades before this window closes.
- Six months security only: The final phase covers security fixes, which means an unpatched feature set is a risk you must manage.
- Series planning: Upgrading between series is a recurring task that needs test time and a rollback plan.
Before you build on a series, read the Samba release planning page, calculate the end dates for your chosen series, and ask any support provider to commit to upgrade assistance within that window.
Neither FreeIPA nor Samba charges a license fee, so the money you spend goes to people and support rather than to the software itself. A support subscription from a vendor or partner buys a defined level of response, patches and advice, and its terms vary by supplier. Those terms, not the GPL license, decide what you can expect when a production domain controller fails or a CVE is published.
- Support subscriptions: A vendor or partner sells support, response times and patch delivery for a defined scope.
- Implementation labor: Design, installation, trust setup, migration and testing are one-time costs driven by domain size and integration count.
- Operations labor: Monitoring, patching, backup testing and functional-level planning recur for as long as the directory runs.
- Training: Staff who can operate Kerberos, DNS and replication reliably are a continuing cost, especially during staff turnover.
- Quote scope: Ask for the written scope, named deliverables, response commitments and what happens when a Samba or FreeIPA series reaches the end of its window.
Confirm vendor support terms directly with each supplier, in writing, and do not assume a GPL license implies any particular service level.
What drives the running cost when neither product has a license fee
Neither FreeIPA nor Samba charges a software license fee, so the running cost sits almost entirely in people, servers and the work of keeping a directory healthy. The largest recurring line is staff time: someone must patch the operating system, track FreeIPA or Samba releases, watch replication health and handle account lifecycle. FreeIPA's deployment recommendations call for 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. Each replica adds patching and monitoring work, so the replica count is the first number to fix in a quote. If Samba is used for file serving, the Samba wiki advises against running file shares on an AD DC when several DCs exist and recommends a separate member server, which adds another machine to build, patch and back up.
One-time costs cluster around design and migration. DNS design is the main decision: FreeIPA's recommendations ask for at least two DNS servers in each client's resolv.conf, and the Samba AD DC supports only the SAMBA_INTERNAL and BIND9_DLZ backends. Trust setup with Active Directory has its own work, because the IPA DNS domain must not overlap any AD forest domain. Migrating users and groups is comparatively bounded with ipa migrate-ds, but sudo and HBAC rules need manual LDIF work, so budget that effort separately. Ask the provider which of these items sit inside the fixed scope and which are open-ended.
Recurring costs also include backup verification, upgrades and training. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore drills belong in the operating budget, not only the install. Samba release series receive six months of full support, six months of maintenance and six months of security fixes only, so a Samba estate on an older series forces an upgrade cycle that someone must plan. Ask for scope, server and replica counts, support hours, the named owner of each upgrade, and whether training is included or priced separately.
Moving Windows clients, Linux hosts and identities between the two
This sequence gives you a tested path for moving identities and services between FreeIPA and Samba AD, or running both in a phased coexistence, without breaking authentication for users who depend on either directory. The exact order depends on your estate, so treat the steps below as a checklist to adapt rather than a fixed runbook.
Inventory identities, clients and dependencies
Before changing anything, list every user, group, host, service account and application that authenticates against the current directory. Record which Windows clients join which domain, which Linux hosts use SSSD or Kerberos, and which sudo and HBAC rules control access. Your team owns this inventory, and it is done when each identity has a named owner and each dependent system has a documented authentication path.
Confirm DNS domains do not overlap
Check that the FreeIPA DNS domain and the Samba AD DNS domain are distinct and do not overlap with any domain in the other forest. FreeIPA's trust documentation requires non-overlapping DNS domains for a cross-forest trust, so resolve any overlap before building the trust. Your DNS and directory administrators confirm this together, and the check is complete when name resolution for both namespaces is verified from clients on each side.
Build the trust or stage the target directory
For coexistence, establish the cross-forest trust that FreeIPA documents for Active Directory, with Samba components on the Samba side where the design requires them. For a full move, stand up the target directory with at least the replica count your deployment recommendations call for in each datacenter. The step is done when test users from one side can authenticate to a test resource on the other side.
Migrate users and groups with ipa migrate-ds
When moving LDAP-backed users and groups into FreeIPA, run the ipa migrate-ds command against the source directory. The tool excludes Kerberos attributes because FreeIPA regenerates them, so plan to reset or re-establish Kerberos credentials for migrated accounts. Your identity engineer runs a dry review on a copy first, and the step closes when migrated counts match the inventory and sample logins succeed.
Rebuild sudo and HBAC rules by hand
Sudo and host-based access control rules do not transfer automatically. Export the existing policy, convert it to LDIF, and load it into the target directory, then review each rule against the inventory from the first step. The migration how-to is the reference for this work. The step is done when a representative set of Linux hosts grants and denies access exactly as the source policy did.
Move clients and services in waves
Re-point Linux hosts, Windows clients and applications to the target directory in small groups, starting with non-critical systems. Keep a rollback path for each wave. Your operations team records which clients moved, which Kerberos and LDAP settings changed, and any failures. The wave is complete when logins are verified and monitoring shows no authentication errors for the group.
Protect backups and replication during cutover
Take a current full backup before each cutover step. Do not restore an older backup into an active replica topology, because FreeIPA's backup documentation warns that this can break replication. If a restore is needed, rebuild the affected replica from a consistent source instead. The step is done when replication status is healthy on every server and a restore test has been run in an isolated environment.
Decommission the source and document the result
After all clients and services authenticate against the target, retire the old directory in a planned order and keep its last backup under your retention policy. Confirm which party handles ongoing support and upgrades for the new platform, and record the final architecture, trust configuration and rule set. The step is done when the decommission checklist is signed off and the documentation is handed to the team that will operate the estate.
Where FreeIPA and Samba AD projects usually run long
DNS design is where most FreeIPA and Samba AD projects slip. Both platforms depend on DNS for service discovery, so a misplaced zone or a single resolver costs more time than any other item. FreeIPA's deployment recommendations call for at least two DNS servers in each client's resolv.conf, and they expect the IdM DNS zone and the Active Directory-facing zones to be designed before the first replica is promoted. Samba's DC supports the SAMBA_INTERNAL and BIND9_DLZ backends, and the wiki warns against the NONE backend and states that BIND9_FLATFILE is not supported. Confirm which DNS backend your Samba design needs, who owns resolver configuration on every Linux and Windows host, and how DNS will be tested before any client is joined.
Kerberos and time synchronization cause the most unexpected failures. Kerberos ticket validation fails when clocks drift, and both platforms rely on Kerberos for logins. Plan time sources for every domain controller and client, and test authentication after each change. On the Samba side, the AD DC uses the Heimdal KDC by default, and MIT Kerberos support is experimental, so confirm the build and Kerberos library your team will support. Certificate issuance design also needs early attention: FreeIPA's integrated Dogtag CA carries renewal and CRL duties on the first server by default, and Samba does not provide a comparable built-in CA, so ask who issues and renews the certificates your services need.
Windows domain join, Group Policy replacement and functional level raises extend timelines. Windows clients join a Samba AD domain, but Group Policy objects are not replaced by FreeIPA host and sudo policies, so every policy that currently lives in GPO must be inventoried and re-implemented or retired. Plan a pilot with a small set of Windows and Linux clients and record every item that does not behave as expected. Functional levels also need a rehearsal: Samba supports the 2008 R2 level since 4.0, the 2012 and 2012 R2 levels since 4.19, and the 2016 level since 4.20, and raising them is done with samba-tool after testing on a copy of the domain. For FreeIPA, the cross-forest trust needs a DNS domain that does not overlap with the AD forest, so settle naming before any trust work begins. Ask whether your team has Linux administration depth for FreeIPA or Windows domain administration depth for Samba AD, because the platform you choose sets the skills you must staff.
What buyers ask before choosing between FreeIPA and Samba AD
Does FreeIPA or Samba AD have a license fee?
Neither product charges a license fee. FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own, and Samba is licensed under GPL-3.0. Your cost is the infrastructure, the staff time to build and operate the directory, and any support contract you choose to buy from a vendor or implementation partner. Ask any vendor you engage to separate one-time build work from recurring operations and support in the quote.
What drives the effort and cost of a FreeIPA or Samba AD deployment?
The main drivers are the number of sites and domain controllers, whether you need Kerberos, certificates, DNS and host policy in one platform, how many Windows clients and applications authenticate against it, and how much existing data must be migrated. FreeIPA also brings a certificate authority and replication topology that need planning. Samba AD adds functional level choices and a DNS backend decision. Ask for a written scope that lists each of these items so the quote reflects the actual work.
How long does a typical implementation take?
No duration can be stated here without a scoped plan, because timing depends on the number of sites, the size of the directory, the migration source and how many systems must be cut over. The Samba wiki's release planning gives support windows for Samba releases, which matter for the maintenance schedule, but it does not give project durations. Ask for a timeline tied to named milestones such as a lab build, a pilot domain, replica placement and client cutover.
Can an in-house team deploy and run either product without outside help?
Yes, a team with strong Linux and directory skills can deploy either product alone, and both are open source with public documentation. The harder part is ongoing operation: FreeIPA's deployment guidance calls for multiple replicas per datacenter and careful backup and restore handling, and Samba AD needs samba-tool administration and DNS planning. Be honest about who will hold these skills after the first build. If the answer is one person, plan for documented runbooks or a retainer.
Can Samba AD replace Microsoft Active Directory for Windows clients?
Samba can run as an Active Directory domain controller and supports the Windows Server 2008 R2 functional level, the 2012 and 2012 R2 levels, and the 2016 level since Samba 4.20. That makes it a candidate for smaller or specific estates, but whether it fits depends on your Group Policy, application and management tooling needs. Test your exact Windows client builds, group policy usage and third-party integrations in a lab before deciding, and confirm feature coverage with the Samba project.
Can FreeIPA trust an existing Active Directory forest?
Yes. FreeIPA can establish a cross-forest trust with an Active Directory domain through Samba components, so AD users can reach Linux resources. The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, and the FreeIPA AD trust guide lists Windows Server 2008 R2 or later as the supported AD side. Plan the DNS naming before installation, because changing it later is costly.
What does the work need from our team?
Expect the team to own DNS design, certificate and CA decisions, replica placement, backup scheduling and client configuration. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter and dedicated servers without other applications, and they advise at least two DNS servers in each client's resolv.conf. Samba AD requires the team to choose a DNS backend from SAMBA_INTERNAL or BIND9_DLZ and to avoid running the domain controller as a file server when multiple DCs exist. Confirm named owners for each area before the build starts.
When should we run FreeIPA and Samba AD together?
Run both when Linux identity, Kerberos, certificates and host policy belong in FreeIPA, while a set of Windows clients or Windows-only applications needs a Samba-hosted AD-compatible domain. Keep the DNS domains separate, plan the trust path explicitly, and assign one team to own the boundary. Running two directories adds operational overhead, so confirm that the Windows requirement cannot be met by one platform first. This decision is worth testing in a lab with your actual client mix.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the choice between FreeIPA and Samba AD rests on your requirements rather than on our preference. We start from the workloads, client mix and trust needs you have, and we set out the work in writing before anything is built.
How we scope
- We map which Linux, UNIX and Windows clients must authenticate, and which ones need Kerberos, group policy or file services.
- We record the functional level, DNS backend and trust requirements that the written scope must satisfy before any build starts.
- We agree deliverables and timelines in writing, and we offer ongoing support and continuous testing as a retainer after handover.
How we build
- We install and configure the chosen directory in your own cloud accounts, data centers or air-gapped networks, with replicas placed per your design.
- We configure DNS, time synchronization, client enrollment and any cross-forest trust, and we test each path against the scope.
- We run security testing against the deployed directory and document the hardening decisions taken during the build.
How we hand over
- We document the architecture, replication topology, backup and restore procedures, and the administrative tasks your team will own.
- We prepare the controls and evidence that your compliance assessors will need, without issuing any audit report or attestation ourselves.
- We walk your administrators through daily operations so your team can run the directory without relying on us for routine work.
How we support
- We can keep the directory patched, upgraded and monitored under a retainer, with the scope of that retainer agreed in writing.
- We revisit functional levels, release lines and trust configuration when upgrades are planned, so changes are scoped before they run.
- We help you confirm vendor support terms, subscription coverage and version lifecycles directly with the platform providers involved.
