Samba Active Directory DC

Last reviewed Sep 13, 2026 · 913 words

Samba's Active Directory domain controller does what it says: Windows 10 and 11 machines join it, users log in with Kerberos, group policy applies, and the Windows admin tools (Users and Computers, Group Policy Management) manage it as if it were a Windows Server box. The catalogue rates it Hard, and the hardness is concentrated in one place. Nearly every broken Samba AD deployment I have looked at was a DNS problem, because a domain controller is a DNS server first and everything else second, and people keep trying to run it next to another resolver.

Whether you need a domain at all

The identity category has grown a lot of easier things. If the goal is single sign-on for web apps, Authentik does that with less pain and the SSO guide covers it. If the goal is a small LDAP directory for a NAS and a few services, lldap is 30 MB and a web form. If the machines are Linux and you want Kerberos, sudo rules and host-based access, FreeIPA is the larger project and better fit.

Samba AD is the right answer when you have Windows clients that need to be domain-joined: roaming profiles, mapped drives by group, password policy enforced at login, GPOs that lock down a lab. That is a real requirement in small businesses, schools and home labs that mirror them, and it is the only free software that meets it. Everything else in this guide assumes that is you.

Provisioning is one command, preparation is the work

The command is samba-tool domain provision, and on a clean Debian or Ubuntu install with the samba package it takes seconds:

samba-tool domain provision --use-rfc2307 --realm=AD.EXAMPLE.LAN \
  --domain=EXAMPLE --server-role=dc --dns-backend=SAMBA_INTERNAL

The preparation is what matters. The realm must be a DNS domain you control and will never need to rename; a subdomain of something you own is the convention, and .local collides with mDNS. The host needs a static IP and a hostname that resolves to it. The smbd, nmbd and winbind services must be disabled in favour of the single samba-ad-dc unit, which the packages do not do for you. And systemd-resolved or any other listener on port 53 must be stopped, because the internal DNS server is about to take that port.

The DNS rule

After provisioning, the DC's own /etc/resolv.conf must point at itself, and every domain member must use the DC as its only DNS server. Not "the DC and 1.1.1.1 as a backup": Windows will happily query the backup, fail to find the _ldap._tcp and _kerberos._tcp SRV records, and produce errors that look like authentication faults. Forward external queries from Samba to your usual resolver with the dns forwarder setting in smb.conf. Do that, verify with host -t SRV _ldap._tcp.ad.example.lan, and most of the "Hard" rating evaporates.

Time is the other silent dependency: Kerberos rejects tickets more than 5 minutes off, so run NTP on the DC and let clients sync from it.

What Samba AD does not do

Be clear-eyed about the gaps, because they surprise people who arrive from Windows Server. Sysvol, where group policy files live, does not replicate between Samba DCs on its own; with two DCs you set up a scheduled rsync or robocopy yourself. The default functional level is 2008 R2, which every current Windows client accepts but which rules out a few newer AD features. There is no Exchange, no ADFS, and no clustered file server, though plain file and print sharing on the DC works.

The catalogue lists Docker as a deployment option and technically it is, but a DC needs a stable IP, a long list of ports (53, 88, 135, 137 to 139, 389, 445, 464, 636, 3268 and 3269) and reliable time, and containers make each of those slightly worse. A small VM is the deployment I would defend. With 512 MB it runs; give it 2 GB so the LDAP database and the DNS cache never fight for memory.

Backups and the second DC

samba-tool domain backup online produces a restorable archive of the directory, and you should run it nightly and test a restore once, because a corrupted AD database is not a thing you can fix by hand. A second DC (samba-tool domain join ... DC) buys you availability and a live replica, at the cost of the sysvol sync above. For a household or a five-person office, one DC with nightly backups is the pragmatic choice.

The plain Samba file server is the same code in a different role and is worth knowing about if what you actually needed was a shared drive, not a domain.

What I'd do

Only build this for Windows clients that need domain join. Put it in a dedicated VM with a static IP, provision with the internal DNS backend, point every client and the DC itself at that DNS server and nothing else, and set a forwarder. Manage users and GPOs from a Windows workstation with RSAT installed rather than from the command line. Take nightly online backups. Run like that it is a free, durable replacement for a Windows Server licence that costs real money, and the Active Directory you replace will not notice the difference.