Migrate from Microsoft Active Directory to Samba AD

The size and shape of the existing domain drives most of the effort: the number of domains and forests, the count of domain controllers, the Group Policy estate, the DNS zones, and how many applications authenticate with Kerberos, LDAP or NTLM. Each application that depends on a specific Windows behavior adds test work before any Samba DC is promoted. Ask the implementation partner to inventory these dependencies first, because the inventory sets the test scope and the cutover plan. Confirm with Samba's documentation which features your estate uses before assuming parity.

One-time costs cover the assessment, the lab build, the coexistence work, testing, cutover and decommissioning of Windows DCs. Recurring costs cover staff time to patch and monitor Samba DCs, backups, monitoring tools, and any support contract you choose to buy. Samba itself is licensed under GPL-3.0, so there is no per-server license fee for the directory software. Samba publishes release series with six months of full support, six months of maintenance mode and six months of security fixes only, so budget for a planned upgrade cadence rather than long-term reliance on one release.

Samba's release planning gives each release series six months of full support, six months in maintenance mode and six months of security fixes only, and Samba 4.25 started in September 2026. This means each DC fleet needs an upgrade cycle that fits inside those windows. Each upgrade carries test and change-control effort, and it recurs. Decide who performs upgrades, whether that is your team, a retained partner or a commercial support provider, and write the cadence into the operating model. Confirm the current support status of any series with the Samba release planning page before you choose a version.

The team needs working knowledge of Kerberos, DNS, LDAP, Group Policy behavior, and the samba-tool command used to administer Samba AD domains. Engineers who already run Linux servers and understand Windows domain concepts usually adapt faster than teams that have only managed Windows. Budget for training or pairing time, and for one or two people who own the directory after cutover. Ask any partner to show how knowledge transfers to your staff through runbooks, reviewed change records and joint operations, and to name who holds on-call responsibility for the directory.

Testing usually costs more time than the directory build itself. Plan test cases for Windows client logons, Group Policy application, SYSVOL replication, DNS resolution, file access through separate member servers, and every application that binds to the directory. 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 file services may need their own build and test cycle. The functional level you need also limits which Windows Server features can be enabled. Samba supports functional levels up to 2016 in the release line described by the wiki, so confirm the level your domain requires before scoping tests.

A written scope should list the domains and forests in scope, the number of DCs and their roles, the functional level now and after migration, the DNS backend chosen, and the SYSVOL and idmap synchronization approach. It should name the applications and services to be tested, the rollback plan for each stage, and the criteria for demoting the last Windows DC. Add the named deliverables, such as runbooks and test evidence, the acceptance criteria, the exclusions, and who is responsible for each step. Most engagements are fixed-scope at DeployOpen, so the written scope sets the price and timeline.

A capable team can run a Samba AD migration itself if it has the Linux, DNS and Kerberos skills, a lab to rehearse in, and time to test each application. Hire help when the estate is large, when Group Policy or file services carry heavy dependencies, when regulated evidence is required, or when the team cannot absorb the cutover risk alongside daily operations. DeployOpen plans, implements, tests, documents and supports self-hosted platforms in your own infrastructure, and it prepares evidence for compliance assessments without issuing audit reports. Ask for a written scope that separates the parts your team keeps from the parts a partner delivers.

The largest cost drivers are unplanned dependencies, failed coexistence tests and extended parallel running. Risks grow when Windows-only applications, legacy NTLM dependencies or custom Group Policy settings appear late in the project. Parallel running adds cost because two directories must stay in step. Ask for a risk register in the scope, with each risk linked to a test and an owner, and agree on a rollback point before the last Windows DC is demoted. Confirm each Samba capability you rely on against the official Samba wiki pages before the cutover date is fixed.

The cost is mostly people time, plus the Linux servers and any support contract you choose. Samba itself is licensed under GPL-3.0, so there is no per-server software license for the directory itself. The main cost drivers are the number of domains and DCs, how many Group Policy, DNS and application dependencies you must re-test, how much of the Windows Server and CAL spend you can actually remove (some Windows client CALs may still apply to other servers), and the skills your team already has. Ask any implementation partner for a fixed-scope quote that lists each phase, the environments covered, the test plan, the rollback steps and what is delivered in writing. Ongoing support is a separate, recurring line item.

The duration depends on the size of the forest, the number of DCs and the number of systems that authenticate against them, and no duration is fixed by the Samba documentation. Most of the calendar time goes to inventory, testing DNS and Kerberos behavior, and running Samba DCs alongside Windows DCs in a coexistence period. Ask for a timeline that separates the coexistence stage from the cutover and the decommissioning stage, and confirm which dependencies each stage must clear. Check the Samba release planning page for the support window of the release series you intend to deploy, because a long project should not start on a series near the end of full support.

A team with strong Linux, DNS, Kerberos and Group Policy experience can run a Samba AD project, but the work is more than installing a package. Your team needs to plan the functional level, handle SYSVOL and idmap configuration, verify DNS backends, and test every Windows client and application that depends on AD. The Samba wiki advises against using an AD DC as a file server when multiple DCs exist, so file services need their own design. If the team has not run a directory before, budget for training or for an outside partner to plan, implement and document the work. Ask any partner to state in writing who performs each task and which tasks remain with your staff.

Passwords do not come with a standard AD export, so user accounts must be re-created or re-set through a controlled process. Plan how each user gets a new credential: a forced reset at first logon, a staged rollout by group, or a coordinated cutover window. Confirm with your security team how MFA enrolment, service account credentials and Kerberos keytabs will be rebuilt, because these do not move with a user list. Keep the export as a reconciliation source, and check the results against the source directory before anyone signs off on the cutover. The export file itself contains personal data and should be stored and deleted under your data handling rules.

Before demoting the last Windows DC, confirm that every FSMO role is held by a Samba DC and that replication is healthy in both directions. Check that DNS resolves the domain, SRV records and the global catalog answer correctly from every subnet, and that Kerberos authentication works for test users and service accounts. Verify that SYSVOL content and Group Policy objects are present and applied on sample clients, and that idmap ranges are consistent so file permissions keep their meaning. Run a rollback rehearsal, confirm backups of the Windows DC and its configuration, and make sure every application that bound to the old DC has been re-tested. Record the results so the sign-off can be reviewed later.

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. If your forest runs a level above 2016, Samba is not a drop-in replacement for that level, so confirm the level before you plan the coexistence period. Raising a functional level is done with samba-tool, and it is one-way in most cases, so test it in a non-production copy first. Ask your partner to confirm the Samba version that matches your current level and to document the steps for the raise.

Expect gaps in Group Policy and file serving rather than in basic authentication. Samba documents its own support for Group Policy and SYSVOL, but the features your estate uses, such as specific policy extensions, must be tested against your own GPOs before you rely on them. The Samba wiki recommends a separate Samba domain member for file serving when multiple DCs exist, which changes your file server design. Build an inventory of GPOs, logon scripts and file shares, then test each one on a Samba DC with a sample of Windows clients. Record anything that does not behave the same way and decide whether to rework it, keep a Windows server for that function, or accept the change.

Most Windows clients keep working when the domain, DNS and Kerberos settings are correct, but each client type should be tested before cutover. Pay attention to DNS configuration, time synchronization, domain join state and any application that relies on specific AD schema attributes. Linux hosts that join through SSSD or Winbind need their own tests, and those hosts may also be a reason to review whether FreeIPA is a better fit for Linux identity. Ask for a test matrix that covers each Windows version, each Linux distribution and each line-of-business application you run today.