When Samba AD fits and when Active Directory still wins for Samba AD vs Active Directory
Your estate runs Windows Server domain controllers and you are asking whether you can drop them. Samba AD suits Linux-heavy or file-serving estates with few Windows-only dependencies. Samba can run as an Active Directory compatible domain controller and supports the Windows Server 2008 R2, 2012 and 2012 R2, and 2016 functional levels, so a domain built on it can serve Kerberos, DNS and LDAP to a mixed client base. Microsoft Active Directory remains the better fit where Group Policy must behave exactly as Microsoft ships it, where DFS-R replication of SYSVOL is a hard requirement, or where a vendor application is certified only against Windows domain controllers. Before deciding, list every Group Policy object you depend on and every application that names a Windows domain controller in its installation requirements.
Replication is the first test. Samba does not support SYSVOL replication through DFS-R or FRS, and the Samba wiki points to rsync, Unison or osync based workarounds between Samba DCs, or a robocopy based workaround from Samba DCs to Windows DCs. The same wiki notes that a Samba AD DC has no automatic SYSVOL replication to other DCs, so non-default policies must be synced to each new DC by you. If your Group Policy estate is small and stable, that is a manageable runbook. If it changes daily, the workaround becomes a process you own indefinitely. Confirm with your Group Policy administrators how often policies change and which ones are scripted or file-dependent.
The decision turns on three things: SYSVOL and Group Policy needs, Windows application dependencies, and skills and lifecycle cost. Windows Server 2025 licensing is per core with a 16-core minimum per server, and Client Access Licenses apply to every user or device, so the saving from dropping Windows domain controllers depends on how many servers and users you can retire, not on the directory role alone. Check which Windows Server version your domain controllers run and its support end date in the Microsoft lifecycle pages, because a migration that stalls can leave you on unsupported hardware. Keep Windows domain controllers where your staff cannot support Samba's administration tooling and where the policy and application risk is high, and move the simpler estates first, starting with a lab domain you can break.
Which estates can drop Windows domain controllers and which should keep them
This table matches common estate types to the option that fits better, and names the condition that decides it. Read each row against your own client mix, replication topology and application list before deciding, because one blocking requirement usually outweighs the rest.
| Estate scenario | Better fit | Condition that drives the decision |
|---|---|---|
| Linux-only clients and servers with no Windows desktops | Samba AD | Clients join or authenticate through Kerberos, LDAP and DNS, and no Windows-only management tooling is needed. Confirm each Linux client's join method with your own testing. |
| Mixed estate with Group Policy-heavy Windows desktops | Keep Windows DCs | Samba AD does not manage Group Policy the way Windows domains do. Confirm which GPO settings you rely on and whether they can be replaced before you consider dropping Windows DCs. |
| Multi-DC sites that depend on SYSVOL replication | Keep Windows DCs | The Samba wiki states Samba does not support DFS-R or FRS for SysVol. Rsync, Unison or osync workarounds exist, but they must be designed, tested and monitored by your team. |
| Windows-only line-of-business applications that need AD schema or Windows-integrated authentication | Keep Windows DCs | Confirm with each application vendor that Samba AD is a supported directory for it. An unsupported directory can shift risk to you during a support call. |
| Single-site, small Windows-free environment where a Samba DC will be the first and only domain | Samba AD | Plan the domain from the start on Samba. The Samba wiki warns against provisioning a Samba AD DC and later joining it to an existing domain, so do not mix the two paths. |
| Existing Windows domain that will add Samba DCs for Linux workloads | Hybrid, with caution | Samba DCs can join an existing AD domain, but the wiki requires domain-integrated DNS with 2008 behaviour and notes SysVol must be synced manually to new DCs. |
| Estates that need Windows Server features or vendor support for domain controllers | Keep Windows DCs | Choose Windows DCs when your compliance evidence, vendor support statements or auditor expectations assume Microsoft-supported domain controllers. Ask assessors which evidence they expect. |
How a Samba AD domain controller is built and run
A Samba AD domain controller is assembled from a handful of components that Windows Server bundles into one role. Each card below covers one of them, from the Kerberos KDC and DNS backend to administration tooling and role separation, and notes what to confirm before you commit an estate to it.
Heimdal Kerberos key distribution center
Samba's AD DC runs the Heimdal Kerberos KDC, which issues the tickets that Windows and Linux clients use to sign in. Samba also documents experimental MIT Kerberos support in Samba 4.7 or later when built against the system MIT library. Check which Kerberos implementation your build uses, and test ticket behavior for every application that expects Windows Kerberos semantics, since Active Directory Domain Services runs its own KDC inside the Windows Server role.
SAMBA_INTERNAL DNS backend
SAMBA_INTERNAL is the built-in DNS server for a Samba AD DC, and it stores AD-integrated zones without a separate DNS product. It suits small or simple domains with no existing BIND investment. Confirm that your forwarders, reverse zones and any non-Microsoft DNS clients behave as expected, because DNS failures in an AD domain show up as logon and replication failures.
BIND9_DLZ DNS backend
BIND9_DLZ runs BIND with the dynamic loadable zone module so DNS data comes from the Samba directory. Choose it when your operations team already runs BIND and wants standard BIND tooling for forwarding, logging and zone management. The Samba wiki rules out the NONE backend, and BIND9_FLATFILE is not supported, so do not plan around either. Test dynamic updates from every DC and member before cutover.
samba-tool administration
Samba AD domains are administered with the samba-tool command, which creates users and groups, manages objects and raises functional levels. Windows administrators used to Active Directory Users and Computers and PowerShell will need a runbook for these commands, and any scripted provisioning or audit process must be rewritten against samba-tool rather than Windows tooling. Ask your team to document which tasks remain on Windows management hosts and which move to Linux.
Keep DC and file server roles apart
The Samba wiki advises against using an AD DC as a file server when a domain has multiple DCs, and recommends a separate Samba domain member for file serving. Plan file shares on dedicated member servers so that file load, patching and recovery stay separate from directory service availability. Estates that rely on a single Windows server for both roles will need to split them during any migration.
Active Directory Domain Services as a Windows role
Active Directory Domain Services is a Windows Server role that stores users, computers and other objects, replicates directory data to every domain controller in a domain, and provides a schema, a global catalog and a query and index mechanism. Samba AD implements the directory service and Kerberos behavior clients need, but the schema, global catalog and replication model are where compatibility gaps are most likely. Test the specific Windows features your estate depends on before assuming parity.
Samba AD and Active Directory compared on functional levels, SysVol and identity integration
This table compares what Samba AD supports against Microsoft Active Directory on functional levels, SysVol replication, Group Policy, Linux domain join and cloud identity integration. Read each row as a condition to verify in your own estate: a gap in one row can decide whether Windows domain controllers stay in the design.
| Capability | Samba AD | Microsoft Active Directory |
|---|---|---|
| Domain functional levels | Supports 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. Confirm the level your forest needs before committing. | Functional levels are set by the Windows Server version of the domain controllers. Confirm the levels your current forest runs before planning any migration. |
| SysVol replication | The Samba wiki states that DFS-R and FRS are not supported on Samba DCs. Workarounds use rsync, Unison or osync between Samba DCs, or robocopy from Samba DCs to Windows DCs. | SysVol is replicated between Windows domain controllers by the platform's built-in replication mechanisms, with no third-party workaround required. |
| Group Policy handling | A Samba AD DC has no automatic SysVol replication, so Group Policy objects beyond the defaults must be synced to each new DC by your own process. | Group Policy objects replicate to every domain controller and are managed with the standard Windows tooling. |
| Linux domain join | Samba is designed to let Linux and Windows clients join the same domain. Confirm the client distributions and Kerberos settings your team uses against the Samba wiki. | Linux machines need third-party tools or must be configured to authenticate as a Kerberos realm, according to Microsoft's comparison of Active Directory and Entra ID. |
| Entra ID sync | Entra Connect is designed for Active Directory organizations, so confirm its support path for your Samba domain before relying on it. | Existing Active Directory organizations use Microsoft Entra Connect to sync identities to Microsoft Entra ID. |
| SaaS app federation | Samba AD does not provide a federation service for SaaS apps. Plan a separate federation or identity provider layer and confirm how it reads directory data. | Active Directory needs a federation system such as AD FS for SaaS apps, according to Microsoft's comparison of Active Directory and Entra ID. |
| File serving on DCs | The Samba wiki advises against using an AD DC as a file server when there are multiple DCs, and recommends a separate domain member for file serving. | Windows domain controllers can be designed around the file and print roles your environment requires. Confirm the layout with your Windows administrators. |
What Windows Server licensing costs and what Samba costs to license
Windows Server 2025 is licensed per core, and the license count follows the physical hardware rather than the number of roles a server runs. Every server must carry at least 16 core licenses, and every processor must carry at least 8, so a lightly loaded domain controller on a small two-socket host still pays for the minimums. Microsoft's Windows Server pricing page suggests a list price of 1,176 US dollars for a 16 core Standard license and 6,771 US dollars for a 16 core Datacenter license. The same page notes that prices vary by region, so treat these figures as starting points.
- Per-server minimum: Each server needs at least 16 core licenses, which means a four-core virtual domain controller still counts toward the 16-core floor on its physical host.
- Per-processor minimum: Each processor needs at least 8 core licenses, which matters for older or low-core-count CPUs where the minimum exceeds the physical core count.
- Standard list price: The suggested price for 16 core Standard licenses is 1,176 US dollars, a one-time purchase line in most procurement models.
- Datacenter list price: The suggested price for 16 core Datacenter licenses is 6,771 US dollars, so the edition choice changes the purchase line substantially.
- Regional variation: Pricing differs by region and by reseller, so ask for a written quote in your currency and jurisdiction.
Before requesting a quote, count physical cores on every planned domain controller host, including spares and disaster recovery sites, because the minimums apply to each server.
Core licenses cover the server software, but both Windows Server 2025 editions also require a Windows Server Client Access License (CAL) for every user or device that accesses the server. CALs are a separate line from core licensing, so a team that buys sufficient cores can still face a sizable additional count. The count grows as staff, contractors and devices are added, which means it needs an annual review rather than a single purchase decision. Because the requirement applies to both Standard and Datacenter, picking the edition does not remove this line from the order.
- Per user or per device: You decide whether to count people or machines, and the choice changes the total; a shared kiosk and a worker with three devices produce different counts.
- Both editions: Standard and Datacenter each require CALs for every accessing user or device, so the CAL line exists regardless of the edition you buy.
- Growth with headcount: CAL counts follow the number of accessing users and devices, so onboarding waves and device refreshes change the total over time.
- Scope of access: Confirm which accounts and services count as accessing the server, including application accounts, external partners and service devices, before you agree a count.
- Terms check: Confirm with Microsoft or your licensing partner how the current terms apply to your use case, since the license terms govern what counts.
Build a CAL inventory from directory and device records before you request a quote, so the count you order matches the access your domain actually serves.
Microsoft offers Windows Server 2025 on a pay-as-you-go basis through Azure Arc at 33.58 US dollars per core per month, according to its pricing page. This converts the core license from a purchase into a recurring operating charge. The option changes how the budget looks in each year, but it does not change the underlying counting rules for cores, and it depends on connecting on-premises servers to Azure management. For regulated or air-gapped environments, that connection is the first question to settle with the platform, security and procurement teams.
- Published rate: The pay-as-you-go rate is 33.58 US dollars per core per month, so the monthly charge scales with the number of cores you register.
- Recurring cost: Charges continue for as long as the cores are licensed through the arrangement, which shifts spend from a one-time purchase into an ongoing line.
- Azure Arc dependency: The servers must be managed through Azure Arc, so review what management data flows back to Azure and whether your data residency rules allow it.
- Break-even analysis: Compare the total monthly charges across your planned holding period against the one-time purchase, including support and renewal assumptions your finance team sets.
- Quote questions: Ask whether the core minimums of 16 per server and 8 per processor apply under the Arc model and whether CAL requirements still apply.
Before choosing this path, model the recurring charges against the purchase price using your own core count and holding period, and confirm the arrangement with Microsoft or your licensing partner in writing.
Samba is licensed under GPL-3.0, according to the samba-team/samba repository mirror of the Samba git repository, so the software itself carries no per-core, per-server or per-user license fee. Licensing is not the cost driver for a Samba domain. The recurring and one-time costs sit in engineering time, testing, documentation, support arrangements and the upgrade effort that comes with each release. Your staff, any vendor support contract and any implementation partner are the parties paid for that work, and each cost line should be requested and compared separately from the Windows licensing lines.
- No license fee: The GPL-3.0 license means the software cost is zero in the license line, so the comparison turns on people, support and migration effort.
- Staff time: Engineers build, test, document and operate the domain, which is a recurring cost that grows with the number of domain controllers and the number of workarounds you run.
- Release windows: Each Samba series gets six months of full support, six months of maintenance and six months of security fixes only, and Samba's release planning page sets out the schedule. Samba 4.25.0 is the current stable release, and 4.24.8 is also available, so plan upgrades inside these windows.
- Support arrangements: Support is optional and quoted separately. Ask what is covered, who handles security advisories and how fast the provider responds to incidents.
- Fixed-scope implementation: DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that written scope.
Ask every proposal to separate one-time build work from recurring support and staff time, so you can compare the full cost of Samba with the Windows licensing lines on equal terms.
SysVol replication gaps and the workarounds Samba documents
The most consequential operational gap in a Samba AD domain is that Samba does not replicate SysVol automatically. Samba does not support SysVol replication through DFS-R or the older FRS, and a Samba AD DC has no built-in method to copy SysVol to other domain controllers. On a Windows domain, DFS-R handles this without administrator intervention. On Samba, anything beyond the default Group Policy objects must be synchronized to a new DC by a process you build and run yourself, so you should treat SysVol as a design decision before you add a second domain controller.
The Samba wiki page on SysVol replication) documents three families of workaround. Between Samba DCs, it describes approaches based on rsync, Unison or osync that copy the SysVol tree on a schedule or on change. From Samba DCs to Windows DCs, it describes a robocopy based approach. Each option needs a source of truth, a direction of copy, a schedule, permissions and ACLs that survive the copy, and monitoring that proves the copies actually completed. Ask who will own that job after go-live, how a failed copy is detected, and how a damaged or partially written policy is rolled back. Keep in mind that a copy tool does not understand Group Policy versioning the way DFS-R does, so verify that the policy version in Active Directory and the files on disk stay consistent after each run.
Every workaround adds operational ownership, and none of them should be accepted on the strength of a wiki page alone. Build a test domain that mirrors your GPO count, script content and any login or logon scripts, then exercise a policy change, a failed transfer and a restore on each DC. Confirm with your own security and change teams whether the chosen tool and its configuration meet your audit requirements for file integrity and change tracking. If your estate depends on many custom policies or on Windows DCs holding the same SysVol, this is the point to weigh keeping Windows domain controllers in the mix, as covered in the sections on mixed estates.
Moving domain controller roles from Windows to Samba safely
This sequence moves an Active Directory domain from Windows domain controllers to Samba AD controllers in an order that keeps authentication, DNS and Group Policy working at every stage. Each step ends with a check you can record before the next one starts.
Inventory dependencies and Group Policy
The directory team lists every application, service, script and device that authenticates against the domain, including LDAP binds, Kerberos service accounts, Windows-integrated logins, and printers or file shares that depend on specific DCs. Next, export all Group Policy objects and record which ones go beyond the defaults, because the Samba wiki states that a Samba AD DC has no method to automatically replicate SysVol, so non-default policies must be synced to a new DC by hand. The step is done when you hold a written dependency register and a complete GPO export that someone other than the author has reviewed.
Confirm functional level and DNS readiness
Check the current domain and forest functional levels against what Samba supports. Samba supports 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 confirm your target Samba version covers the level you run. Verify that the existing DNS is domain integrated with 2008 behaviour, as the Samba wiki requires for joining. The step is done when the functional level, the Samba version and the DNS configuration are documented side by side and the gaps are closed or accepted in writing.
Join Samba DCs before retiring Windows DCs
Build the Samba DCs and join them to the existing Windows domain as additional controllers, rather than provisioning a Samba domain and joining it later, which the Samba wiki warns against. Confirm that replication is healthy in both directions and that each new DC resolves the domain and answers Kerberos and LDAP queries. The step is done when replication reports no errors across all controllers over a period your team has agreed and each Samba DC has passed the same authentication tests as the Windows DCs.
Move FSMO roles deliberately
Transfer the flexible single master operations roles to Samba DCs one at a time, after confirming with the Samba wiki that apart from FSMO roles there is no difference between DCs in a forest. Transfer each role during a planned change window, then test the dependent function, such as schema changes, RID allocation or time synchronization, before moving the next role. The step is done when
netdom query fsmoor the equivalent Samba tooling shows every role on a Samba DC and each dependent function has been verified after its transfer.Migrate or rebuild SysVol content
Samba does not support SysVol replication through DFS-R or FRS, so the team must choose a workaround. The Samba wiki describes rsync, Unison or osync based approaches between Samba DCs, and a robocopy based approach from Samba DCs to Windows DCs. Compare the copied policy files on every controller against your GPO export from the first step. The step is done when all SysVol content matches on each DC, the chosen sync job has run and failed-sync alerting is in place.
Separate file serving onto domain members
Move file shares off the domain controllers onto dedicated Samba domain members, because the Samba wiki advises against using an AD DC as a file server when multiple DCs exist. Copy share contents, reapply NTFS-equivalent permissions and update drive mappings and login scripts. The step is done when every share resolves to a member server, access tests pass for representative users in each group, and no production file path points to a domain controller.
Retire Windows DCs last
Demote the Windows domain controllers only after every earlier step is recorded as complete and a rollback plan has been tested. Transfer any remaining roles, remove the Windows DCs from DNS and sites, and confirm that clients, servers and applications authenticate through Samba alone. Note what transfers: user and group objects, computer accounts and most directory data move with replication. What must be rebuilt: non-default GPOs, application integrations that depend on Windows-specific features, and any licensing or support contract that names the Windows servers. The step is done when a signed-off checklist confirms that no Windows DC remains in the domain.
Where Samba AD implementation projects usually run long
A Samba AD project usually starts with discovery: an inventory of domain controllers, FSMO role holders, DNS zones, Group Policy objects, scheduled tasks, service accounts and every application that authenticates against the domain over LDAP, Kerberos, NTLM or header-based methods. DeployOpen would scope the work around that inventory, then design DNS with the team, choosing the DNS backend (SAMBA_INTERNAL or BIND9_DLZ) and deciding how forwarding and zones will be managed day to day. Next come the join and test phases, where Samba domain controllers are joined to or built alongside the existing domain, replication and authentication are verified, and a rollback path is rehearsed. The Samba wiki advises against provisioning a Samba AD DC and then joining it to an existing domain, so the join method is a design decision to confirm before work starts, not a detail to settle during cutover. Run handover covers runbooks, monitoring, backup and restore procedures, and who administers the domain with samba-tool after the project closes.
Projects run long in predictable places. Group Policy sprawl is the most common: the Samba wiki states that a Samba AD DC has no method to replicate SysVol automatically, so every GPO beyond the defaults must be synced to each new DC by a workaround the team has to choose and operate. Estates with many GPOs, logon scripts or software deployment policies need an inventory and a clean-up decision before migration, not after. Windows-only applications are the second risk, because agents, installers and vendor software that expect Windows domain controllers, specific schema extensions or GPO-driven configuration can hold up a decommissioning date. DNS integration and skills gaps follow closely: DNS records, dynamic updates and reverse zones often span several teams, and staff who have run Windows domains for years may need time with Samba tooling and Linux operations. No duration can be stated from the supplied material, so ask any partner for a written scope that lists each of these items and the owner of each.
All DeployOpen engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope rather than from a published price list. When you request a quote, ask for the discovery findings, the DNS and join method, the SysVol and GPO handling approach, the list of applications to test, the rollback plan and the handover materials. Also ask which items are one-time work and which recur, such as patching, monitoring and retainer support. Confirm with your own change board and with the application vendors which Windows-only dependencies can be retired and which must stay on Windows domain controllers, since that answer determines whether the project is a full replacement or a partial one.
Questions buyers ask before dropping Windows domain controllers
Can Samba AD fully replace Active Directory in our estate?
Samba can run as an Active Directory compatible domain controller, but whether it fully replaces Active Directory depends on what your estate uses. 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. Before deciding, inventory every AD-dependent product, Group Policy use, certificate services, and third-party software that expects Windows-specific behavior. The Samba wiki also states that a Samba AD DC has no automatic SysVol replication, so Group Policy beyond the defaults needs a manual sync workaround. Confirm each dependency in a lab against the Samba release you plan to run.
What skills does our internal team need to run Samba DCs?
Your team needs working knowledge of Kerberos, DNS, LDAP, and Group Policy behavior, plus comfort with the samba-tool command for administering Samba AD domains. Someone must own the DNS backend choice, since Samba supports SAMBA_INTERNAL and BIND9_DLZ, and the wiki warns against the NONE backend and states that BIND9_FLATFILE is not supported. Your team also needs a process for SysVol sync, backups, and the Samba release cadence. Each release series gets six months of full support, six months of maintenance mode, and six months of security fixes only. Confirm these skills in-house before you commit to a migration date.
What drives the cost of moving off Windows domain controllers?
The main cost drivers are the number of domains and sites, the number of applications that depend on Windows-specific authentication, the volume of Group Policy you need to replicate by hand, and the testing effort for functional level changes. Recurring costs include staff time for patching, monitoring, and release upgrades. One-time costs include planning, lab validation, migration, and documentation. Ask any implementation partner for a written scope that lists each system in the move, the test plan, and the rollback procedure. Quotes follow from that scope, so a vague scope will produce a vague number.
Are Windows Server licensing savings the main reason to switch?
Licensing is one input, but it rarely decides the question alone. Windows Server 2025 is licensed per core with a minimum of 16 cores per server and 8 per processor, and Standard and Datacenter editions both need a Windows Server Client Access License for every user or device that accesses the server. Microsoft's pricing page lists a suggested price of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and notes that prices vary by region. Compare those figures with your actual core counts, CAL position, and the staff time a Samba estate requires. Samba itself is GPL-3.0 licensed, so software fees are not the cost driver.
How do we confirm Samba supports our functional level?
Check the functional level table on the Samba wiki page for raising functional levels, then match it to the Samba release you plan to deploy. The wiki lists 2008 R2 support from Samba 4.0, 2012 and 2012 R2 from Samba 4.19, and 2016 from Samba 4.20. Use samba-tool to view and raise levels in a lab first, because raising a functional level is generally a one-way change. Also confirm that your existing Windows domain controllers and DNS meet the requirements the Samba join guide lists. Record the results as part of your change plan.
Can our team run a Samba AD domain without outside help?
A team with Linux, Kerberos, DNS, and LDAP experience can run a Samba AD domain without outside help, provided it has time to build, test, and document the environment. The risks sit in the details: SysVol synchronization must be set up and checked on every DC, the Samba wiki advises against using an AD DC as a file server when multiple DCs exist, and a separate Samba domain member should handle file serving. Start with a lab, write runbooks for joins, backups, and recovery, and test a DC failure before going live. If any of these steps is new to your staff, budget for training or outside support.
When should we hire an implementation partner for this migration?
Hire an implementation partner when your team lacks the time, the skills, or the independent test capacity to carry the migration through to cutover. DeployOpen plans, implements, integrates, hardens, backs up, and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables, and timelines agreed in writing before work starts. DeployOpen does not issue audit reports or certifications, so compliance evidence still comes from your independent auditor. Ask for a written scope that covers the systems in the move, the SysVol workaround, the testing plan, and handover. Ongoing support and upgrades are available as retainers.
Official sources for Samba AD and Active Directory
Before you commit a domain to Samba, read the Samba wiki pages that define what an AD DC does and where it stops. The SysVol replication page is the first stop, because Samba does not support DFS-R or the older FRS for SysVol, and it sets out the rsync, Unison and osync workarounds between Samba DCs and the robocopy approach for copying to Windows DCs. Pair it with the page on joining a Samba DC to an existing Active Directory, which requires domain-integrated DNS at 2008 behaviour and warns against provisioning a Samba AD DC and then joining it to a domain. Ask your team to confirm each workaround against its own Group Policy footprint, since the wiki states that non-default Group Policy objects must be synced to a new DC by you.
Next, read the setup guide for Samba as an AD DC and the page on raising functional levels, which together define the Heimdal Kerberos KDC, the SAMBA_INTERNAL and BIND9_DLZ DNS backends, and the command-line workflow through samba-tool. The functional levels page is where you check whether a 2008 R2, 2012 R2 or 2016 level meets the features your estate relies on, because each level arrived in a different Samba release. Also check the release planning page, which describes the support windows for each Samba series, so your upgrade cadence matches a supported branch.
On the Microsoft side, the Active Directory Domain Services overview explains what a domain controller replicates, while the Entra comparison explains how Active Directory and Entra ID divide the work, including Entra Connect for syncing identities. For licensing and lifecycle, check the Windows Server pricing page and the Windows Server 2025 lifecycle page, and confirm current prices with your Microsoft reseller, since the pricing page notes that regional prices vary. Your procurement team should compare the Client Access License count and core count per server against your Samba hardware plan, and confirm the Windows Server 2022 end dates for any servers still in service.
How DeployOpen helps choose, implement or migrate Samba AD
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Samba AD versus Microsoft Active Directory, that starts with a written view of which domain controllers can move to Samba and which should stay on Windows.
How we scope
- Written scope covers which domains, sites and applications would move to Samba AD and which stay on Windows
- Scope lists SysVol replication workarounds, DNS backend choice and Group Policy handling as named deliverables
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
How we build
- Build a lab copy of the existing domain to test functional levels, joins and replication before any production change
- Validate Samba domain controller joins against the existing Windows forest, DNS and Group Policy objects
- Test file serving on separate domain members rather than on the domain controllers themselves
How we hand over
- Hand over runbooks for samba-tool administration, replication checks and SysVol sync jobs
- Document which Windows domain controllers remain, their roles and the rollback path for each change
- Deliver evidence of tests and configuration so your auditors and internal reviewers can verify the design
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainer scope can track Samba release series, since each series has a defined support window
- Confirm with DeployOpen which support hours, response levels and upgrade windows apply before signing
