Setting Up a Raspberry Pi as a Samba4 Active Directory Domain Controller for a Small Shop Network

A shop with more than a couple of Windows-based CNC, laser, or print-farm control PCs eventually hits the same friction: every machine has its own local login, shared network drives need per-machine credentials set up by hand, and there's no central place to add or revoke a person's access when a collaborator joins or leaves a shared makerspace. Active Directory is the standard enterprise answer to exactly this problem, and Samba4 lets a Raspberry Pi run a real AD-compatible domain controller for a small environment — centralized users and groups, Kerberos authentication, and integrated DNS — without a Windows Server license or a dedicated rack machine.

What You Actually Get

Samba4 in Active Directory Domain Controller mode is not a file-sharing feature bolted onto Samba's classic workgroup mode — it's a from-scratch reimplementation of the AD DC protocols (Kerberos, LDAP, DNS, and the Active Directory schema), compatible enough that Windows machines join it exactly as they would a real Windows Server domain, and you manage it with the same `samba-tool` command-line utility or the standard Windows RSAT administration tools pointed at the Pi. For a small shop or makerspace — realistically under twenty or thirty joined machines — this is a legitimate, fully supported use case, not a hack. Group Policy support is more limited than a full Windows Server deployment, but centralized authentication, group-based permissions, and DNS integration all work as expected.

Hardware and Network Requirements

• Raspberry Pi 4 or 5, 4GB RAM minimum. The domain controller role itself is light on CPU for a small user count, but LDAP and Kerberos are latency-sensitive, so don't starve it on an older or lower-RAM board shared with other heavy services.
• Wired Ethernet, not WiFi. A domain controller's DNS and Kerberos roles are sensitive to network reliability in a way that makes WiFi's occasional drops a real problem — authentication failures that are hard to diagnose are a common symptom of running a DC over an unreliable link.
• A static IP address on the Pi, since every joined machine's DNS and Kerberos configuration will point at this specific address.
• A dedicated SSD, not a microSD card, for the same reason any frequently-written database service benefits from one — the AD database (sam.ldb) sees continuous small writes.

Provisioning the Domain

1. Install Samba4 (the AD DC-capable package, not just the classic file-server Samba package) on Raspberry Pi OS or a minimal Debian-based image.
2. Remove or disable any existing `smb.conf` and run `samba-tool domain provision`, specifying your domain name, realm, and administrator password — this creates the fresh AD database, Kerberos configuration, and initial DNS zone in one step.
3. Choose a DNS backend during provisioning: the internal SAMBA_INTERNAL backend is the simplest for a small shop and is sufficient unless you have an existing BIND DNS infrastructure you specifically need to integrate with, in which case the BIND9_DLZ backend is the alternative.
4. Configure the Pi's own `/etc/resolv.conf` to point at itself for DNS, since AD clients resolve domain services through the DC's DNS zone, and the DC needs to resolve its own records correctly to function.
5. Open the required firewall ports between client machines and the Pi (Kerberos 88, LDAP 389, DNS 53, SMB 445, and several others — a full AD DC port list is longer than a basic file server's) if you're running `ufw` or another firewall on the Pi.

Joining Windows Machines and Managing Users

Once provisioned, joining a Windows PC to the domain works exactly as it would against a real Windows Server DC: set the Pi's IP as the machine's DNS server, then join the domain by name from Windows' System settings, authenticating with a domain admin account. From there, create users and groups either from `samba-tool user create` / `samba-tool group create` on the Pi directly, or by installing RSAT (Remote Server Administration Tools) on a Windows machine and managing Active Directory Users and Computers against the Pi the same way you would against a Windows Server box.

Common Pitfalls

ProblemCauseFix Kerberos authentication fails intermittentlyClock drift between the Pi and joined machines — Kerberos tickets are time-sensitive and reject significant skewRun NTP on the Pi and ensure all joined machines sync time against it (or a common upstream source) reliably Machines can join but can't resolve domain services afterwardDNS not actually pointing at the Pi, or the Pi's own resolver misconfiguredVerify every joined machine's DNS server setting points at the Pi's static IP, and that the Pi resolves its own domain records correctly Everything stops working if the Pi is offlineSingle point of failure with only one DCProvision a second Pi as an additional domain controller once the environment is validated, giving you DC redundancy the same way a larger organization would

Backup

Back up the AD database and SysVol share regularly — `samba-tool domain backup` has built-in commands for this — and store the backup off the Pi itself. Losing the only domain controller in a single-DC setup with no backup means every joined machine's domain trust relationship needs to be rebuilt from scratch.

Safety

A domain controller holds the authentication secrets for every account on your network, which makes the physical Pi itself worth securing — don't leave it sitting exposed and unsecured if your shop has public or semi-public access, and never expose its AD-related ports to the open internet; this is strictly an internal-network service. Treat the admin credentials with the same care you would a Windows Server domain admin password, since compromising this one Pi compromises authentication for every joined machine.

For a shop running a half-dozen or more Windows control PCs alongside a Linux-based print farm, a Samba4 AD DC on a spare Raspberry Pi turns scattered local logins into one real, centrally managed identity system — at the cost of a few hours of setup and the discipline to keep its clock, DNS, and backups in order.