Learn Samba - Samba as a Domain Controller (AD DC)

#Introduction

Up to episode 8, Samba worked as a standalone file server — users managed locally. In episode 9 we climb to Samba's highest level: making it a full Active Directory Domain Controller. This feature, carried by Samba 4 since 2012, means you can replace a Windows Server DC — with DNS, Kerberos, and AD replication — all on Linux. This is the use case that keeps Samba from being dismissed as "just a file server".

#Concept: Samba AD DC

#What Is a Domain Controller

A Domain Controller is a server that stores the Active Directory database (users, computers, groups, policies) and provides domain authentication (Kerberos + LDAP) as well as AD DNS. A Windows computer "joining the domain" means trusting the DC for login and policy application.

#Different Operating Modes

Remember episode 2: in standalone mode we use smbd + nmbd. In AD DC mode, Samba uses a single samba daemon that runs everything — file server, authentication, and AD DNS — in one process. This isn't just a name difference; the internal architecture is specifically designed to serve the AD database and replication.

#Provisioning a Domain with samba-tool

#Preparation: Clean Configuration

Before provisioning, smb.conf must be reset to DC mode — Samba provides samba-tool domain provision, which writes the correct configuration for you. Start from a clean config:

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
sudo samba-tool domain provision \
  --use-rfc2307 --interactive

--interactive guides you through entering:

• Realm: the domain FQDN, e.g. LAB.LOCAL (UPPERCASE format).
• Domain: the NetBIOS portion, e.g. LAB.
• Server Role: choose dc.
• DNS backend: SAMBA_INTERNAL — AD DNS run by Samba itself.
• Administrator password: the initial domain admin password.

--use-rfc2307 adds the POSIX schema (UID/GID) to AD — required so AD users can be mapped to Unix identities in episode 10 (winbind). Without this option, integrating Linux logins into the domain will be difficult.

#Running and Enabling the DC

sudo systemctl unmask samba-ad-dc
sudo systemctl enable samba-ad-dc
sudo systemctl start samba-ad-dc

On Ubuntu/Debian systems, the smbd/nmbd services and samba-ad-dc are mutually exclusive — disable smbd/nmbd so they don't clash over ports 445/139 (both belong to the samba daemon in DC mode):

sudo systemctl disable --now smbd nmbd

#Integrated DNS and DHCP

#Internal AD DNS

DNS is the backbone of AD: clients find the DC via SRV records (_ldap._tcp.lab.local), not by guessing addresses. In DC mode, AD DNS is run internally by samba (the SAMBA_INTERNAL backend). Verify the AD DNS service:

sudo samba-tool domain info 127.0.0.1
samba-tool dns query localhost LAB.LOCAL @ A -U Administrator

domain info shows the domain name, forest, and functional levels. samba-tool dns query inspects records stored in AD DNS. For clients, point their DNS at this DC's address — that's the only way they find the domain.

#DHCP

Samba doesn't provide a DHCP server — that's outside its scope. The common pattern: a DHCP server (ISC dhcpd, dnsmasq, or a router) hands clients an IP along with DNS = the DC's address. So "integrated DNS/DHCP" means the architecture is designed so DHCP points clients at the DC's DNS — not that Samba runs DHCP.

#AD Replication

#Why Replicate

A single DC is a single point of failure. With two DCs, the AD database replicates automatically — a user created on DC1 appears on DC2 within seconds. To add a second DC:

sudo samba-tool domain join LAB.LOCAL DC -U Administrator --dns-backend=SAMBA_INTERNAL

After joining, check replication health:

sudo samba-tool drs showrepl

samba-tool drs showrepl shows the replication list with partner DCs, success status, and last sync time. This is the analogue of repadmin /replsummary in the Windows world — a tool you must know by heart when managing a Samba domain.

#Case: Replacing a Windows Server DC

The most common scenario: small-to-medium organizations (50-2000 users) that want to get off Windows Server licensing. The steps: set up a Samba DC as an additional DC in the same forest, let replication run, migrate objects, then decommission the Windows DC. An honest note on limitations:

• GPMC (Group Policy Management Console): Samba provides command-line tools for GPOs, but full GPMC belongs to Windows — most people manage it from one Windows admin machine.
• DFS and Exchange features: DFS-R and Exchange depend on Windows in many ways; evaluate before migrating.
• Feature speed: some new Microsoft AD features arrive later in Samba.

Samba AD DC isn't a replacement for Windows Server in every large enterprise scenario — but for small-to-medium scale with standard needs (domain login, files, DNS, basic GPOs), it offers significant license savings with manageable risk.

#Domain Verification

A complete verification package:

sudo samba-tool domain level show
samba-tool domain info 127.0.0.1
samba-tool user list -U Administrator
host -t SRV _ldap._tcp.lab.local

• domain level show: domain/forest functional levels.
• user list: stored users (should already include Administrator and krbtgt).
• host -t SRV: verify a client can find the DC via DNS — the final test of domain reliability.

#Closing

Key takeaways:

• AD DC mode uses the single samba daemon; smbd/nmbd must be disabled.
• samba-tool domain provision --use-rfc2307 creates the domain, DNS, and initial admin.
• AD DNS (the SAMBA_INTERNAL backend) is the heart of domain discovery; point clients at the DC for DNS.
• Replication is managed with samba-tool drs showrepl; a second DC is added with samba-tool domain join.
• A Samba DC is a good Windows Server replacement at small-to-medium scale, with an honest feature assessment.

In episode 10 next, we'll cover winbind: AD user integration — joining as a domain member with net ads join, AD → UID/GID mapping by winbindd, Linux login authentication with AD users, and the security = ads, realm, and winbind use default domain configuration. Your Samba server will accept users from the domain!