Samba as Active Directory: Replacing a Windows Domain

Running Windows Server as a domain controller has become a noticeable cost driver for small and mid-size companies: server license, client access licenses per user or device, plus the recurring upgrades every three years. If you only need file shares, sign-on, group policies and DNS, you are paying for features you never use. Samba 4 has for years implemented the AD protocol completely enough to run as a domain controller in an existing Windows domain — including multi-master replication, Kerberos, LDAP and GPO delivery.

This article covers when Samba is a realistic replacement for a Windows DC, where its limits are, and how to migrate without a weekend outage. We have deployed these procedures for years with SMB customers who run neither Exchange on-premises nor deeply integrated Microsoft 365 hybrid scenarios.

What Samba 4 delivers as an AD DC — and what it does not

Samba 4.20 (the stable release as of summer 2026) runs as a fully featured AD domain controller. Windows clients from Windows 10 upwards sign in, pull group policies, use Kerberos SSO for file shares and resolve names via Samba’s integrated DNS server or via BIND9. From the client’s perspective it is invisible whether the DC runs on Windows Server or on Debian.

The honest boundaries matter, though:

Feature	Samba 4 AD DC	Note
NTLM / Kerberos sign-in	Full	RFC-compliant implementation
LDAP directory service	Full	Compatible with Windows tools like ADUC
DNS (internal or BIND9)	Full	BIND9-DLZ recommended for complex zones
Multi-master replication	Full	DRSUAPI, works with Windows DCs
Group Policy (GPO)	Delivery yes, editing needs RSAT	No graphical editor on the DC itself
Exchange schema extension	No	Exchange requires Windows schema master
Entra Connect / Cloud Sync	Limited	Sync works, but support matrix favors Windows
Read-Only Domain Controller (RODC)	No	Read-write DCs only
PKI / Enterprise CA	No	Certificate Services stay on Windows

In concrete terms: a standard file-server scenario with 50 users, 20 mapped drives, a GPO-deployed printer, a WLAN certificate issued by a separate CA — that runs just as reliably on Samba as on Windows Server. As soon as Exchange on-premises, Entra Hybrid Join in production, or an Enterprise CA are in play, at least those roles must stay on Windows.

The target architecture: Samba with BIND9

For anything beyond the smallest setup we recommend Samba not with the internal DNS server, but paired with BIND9 via the DLZ backend. The reason: BIND9 handles complex split-horizon zones, DNSSEC and forwarders much more robustly, and you can use the same name server for internal AD zones and for public zones.

A typical two-DC setup looks like this:

dc01.company.local  (Debian 13, Samba 4.20, BIND9)  -- Site A
dc02.company.local  (Debian 13, Samba 4.20, BIND9)  -- Site B
FSMO roles: dc01 holds PDC Emulator, RID Master, Infrastructure Master
            dc02 holds Schema Master and Domain Naming Master
Replication: every 15 minutes intra-site, hourly inter-site
Backup: nightly samba-tool domain backup offline to TrueNAS share

Provisioning the first Samba DC is a single command. Set the DNS backend parameter correctly and raise the domain functional level to a value that matches your existing clients:

# Initial provisioning of a new DC (not for migration)
samba-tool domain provision \
  --realm=COMPANY.LOCAL \
  --domain=COMPANY \
  --server-role=dc \
  --dns-backend=BIND9_DLZ \
  --function-level=2016 \
  --use-rfc2307 \
  --adminpass='StrongPassword!2026'

# Wire up BIND9
echo 'include "/var/lib/samba/bind-dns/named.conf";' >> /etc/bind/named.conf.local
systemctl restart bind9 samba-ad-dc

The --use-rfc2307 parameter extends the schema with POSIX attributes — indispensable if you later want to authenticate Linux clients against AD via SSSD, which is the rule in mixed environments.

Migrating from an existing Windows domain

The proper path is coexistence: the new Samba DC joins the existing Windows domain as an additional domain controller, replicates the full directory via DRSUAPI, and then takes over the FSMO roles. Only once everything is running is the old Windows DC decommissioned. End-user downtime: zero.

The process in five steps:

1. Prepare the Windows side: check domain and forest functional level. Samba 4.20 supports up to Windows Server 2016. Higher levels are possible on Windows DCs but block a Samba DC from joining.
2. Join the Samba DC: on the new Debian system, run samba-tool domain join company.local DC -U administrator --dns-backend=BIND9_DLZ. The join takes a few minutes depending on directory size.
3. Verify replication: use samba-tool drs showrepl to confirm all naming contexts replicated successfully. Errors at this stage almost always trace back to DNS or time-sync problems.
4. Transfer FSMO roles: after 24 to 48 hours of stable coexistence, move the FSMO roles one by one with samba-tool fsmo transfer. Move the PDC Emulator last, because it is central to time sync and password changes.
5. Demote the old DC: on the Windows Server, use dcpromo (or on Windows Server 2025 the Server Manager wizard) to remove the DC role cleanly. Do not just power it off — metadata leftovers in the directory are painful to clean up.

For time synchronization we run chrony on the Samba DC with an external reference (e.g. the DFN NTP pool). AD is notoriously sensitive to time drift beyond five minutes — Kerberos tickets become invalid immediately.

Group Policy: what actually works

The most common concern in migration projects is GPO capability. To be clear: Samba delivers group policies fully. A Windows client running gpupdate /force applies password policies, MSI software distribution, drive mappings, firewall rules, loopback processing and Preferences exactly as against a Windows DC.

What Samba does not ship: the graphical editor. You still need a Windows client with RSAT (Remote Server Administration Tools) to create or modify policies via gpmc.msc. In practice this is not a limitation, because an admin laptop with RSAT is standard anyway — nobody sensibly edits GPOs on a Server Core install.

An often-overlooked detail: PolicyDefinitions (ADMX templates). They must live on the SYSVOL share under \\company.local\SYSVOL\company.local\Policies\PolicyDefinitions\. After the migration, verify the templates replicated in full, otherwise the GPO editor shows “Additional Registry Settings” instead of readable categories.

Backup and disaster recovery

Since version 4.11 Samba ships a clean offline backup via samba-tool domain backup, which writes the full directory including Kerberos keytab, SYSVOL and configuration into a tar archive. We schedule this nightly to a TrueNAS share and keep a 30-day history using ZFS snapshots. Quarterly restore tests in an isolated VM on the Proxmox cluster.

For a real site failure, two DCs at different locations with working replication are enough. If site A goes down, site B continues autonomously. When site A returns, Samba resynchronizes automatically. Caveat: USN rollback detection only helps with clean backups — never roll a running DC back from a hypervisor snapshot, that produces exactly the rollback state that wreaks havoc on the directory.

When Samba fits — and when it does not

After many migration projects, a clear pattern emerges:

• Clear yes cases: file-server-centric environments without Exchange on-premises, without mandatory Entra hybrid join, with classic GPO requirements. Typical: trade businesses, engineering offices, law firms, schools. Here Samba replaces the Windows DC one-for-one, saving license and support costs in the four- to five-figure range per year.
• Borderline cases: environments with an Enterprise CA, complex trust relationships to external forests, deeply integrated SCCM/Intune. Feasible, but operational effort rises noticeably.
• Clear no cases: Exchange on-premises as a production system, Entra Hybrid Join with Windows-Hello-for-Business certificates from AD CS, strict Microsoft support requirements in enterprise settings.

The staffing question matters too: Samba is open source and administered via the console. If your team knows only Windows GUIs, you first need to invest in know-how — or bring in external support.

---

DATAZONE helps evaluate whether Samba fits your environment, plans the migration including the coexistence phase, and on request takes over ongoing operations of the domain controllers including backup and monitoring. Get in touch — we will assess without obligation which roles make sense to move to Linux and where a Windows server remains the right choice. Contact us.