Great Lynx Designs

Samba Active Directory Homelab on Fedora
with Debian-Based Notes

This Dev Note documents a small homelab setup using Samba as an Active Directory Domain Controller. The primary path here is Fedora-based, with Debian / Ubuntu command equivalents included where helpful.

The goal is to create a local identity and authentication environment for testing domain services, DNS, Kerberos, client joins, and related infrastructure workflows without touching production systems.

Primary Platform

Fedora Server / Fedora VM

Secondary Notes

Debian / Ubuntu equivalents

Use Case

Homelab, testing, learning, infrastructure practice

What This Homelab Is Useful For

  • Learning Active Directory concepts in a Linux-based environment
  • Testing centralized authentication
  • Practicing DNS and Kerberos setup
  • Joining Linux or Windows clients to a domain
  • Building familiarity with small-network identity infrastructure

Planning Values for This Example

Hostname

dc1

FQDN

dc1.lab.example.internal

Realm

LAB.EXAMPLE.INTERNAL

Domain / Workgroup

LAB

Note: These values are examples only. Replace them with values that fit your own homelab. If you already have a naming convention, use it consistently.

Before You Begin

  • Use a fresh VM or clean system if possible
  • Set a static IP address before provisioning the domain
  • Make sure the server has a stable hostname and FQDN
  • Ensure system time is synchronized
  • Expect to do testing and troubleshooting in a local environment first
Important: Provisioning Samba AD before the hostname, IP, DNS, and time settings are stable is a classic way to summon avoidable chaos.

Step 1 — Install Required Packages

Package names can vary a bit by distro release, but the following gets the basic toolset in place for a typical lab setup.

Fedora

sudo dnf install samba samba-dc samba-client krb5-workstation bind-utils

Debian / Ubuntu

sudo apt update
sudo apt install acl attr samba winbind libpam-winbind libnss-winbind krb5-config krb5-user dnsutils python3-setproctitle
The Debian / Ubuntu package list is often a little more explicitly documented for Samba AD work, which is one reason Debian-based systems are a common lab choice.

Step 2 — Set the Hostname

Your domain controller should have a proper hostname and fully qualified domain name before domain provisioning begins. 

sudo hostnamectl set-hostname dc1.lab.example.internal

Verify:

hostname
hostname -f

Step 3 — Confirm Static IP and Basic Name Resolution

Make sure the server’s IP address is not changing unexpectedly and that local naming is sane before provisioning.

Useful checks:

ip addr
hostname -I
getent hosts dc1.lab.example.internal
For a homelab, it is often worth documenting the chosen IP, gateway, and DNS plan in a separate note or notebook page. That turns your setup from “a machine I configured once” into “a system I can reproduce.”

Step 4 — Ensure Time Synchronization Is Working

Kerberos depends heavily on correct time. If the clock is drifting or badly out of sync, authentication problems can show up later.

Fedora (chrony is common)

systemctl status chronyd
timedatectl

Debian / Ubuntu

timedatectl

At minimum, confirm that time synchronization is active and the clock is reasonable before continuing.

Step 5 — Provision the Domain

Samba includes a provisioning tool that initializes a new Active Directory domain. 

sudo samba-tool domain provision --use-rfc2307 --interactive

During setup you will be prompted for values such as:

  • Realm — example: LAB.EXAMPLE.INTERNAL
  • Domain / workgroup name — example: LAB
  • DNS backend
  • Administrator password
For homelab use, the internal Samba DNS server is often the simplest place to start.

Step 6 — Review the Generated Configuration

After provisioning, Samba writes configuration files that are worth checking before you move on.

Common files to inspect:

/etc/samba/smb.conf
/etc/krb5.conf

At this stage, the main thing is not deep customization. It is simply confirming that the generated configuration reflects your chosen realm, host, and domain values.

Step 7 — Start and Enable the Service

Service names can vary depending on how Samba is packaged on the distro, so check what your system actually provides.

Common service names to check

systemctl list-unit-files | grep samba

Examples you may use depending on packaging:

sudo systemctl enable samba
sudo systemctl start samba

or:

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

Verify:

systemctl status samba
systemctl status samba-ad-dc
Do not assume every distro uses the same service name. Check the available units on the actual machine first.

Step 8 — Make Sure the Resolver Points Where It Should

After provisioning, DNS resolution should be consistent with your Samba AD plan. A common source of trouble is the server still pointing first to some outside resolver instead of the local domain controller path.

Useful checks:

cat /etc/resolv.conf
resolvectl status

For a single-DC lab, your resolver strategy should be simple and intentional. Do not let it become accidental folklore.

Step 9 — Basic Verification

These checks help confirm that the domain was created correctly and that Samba is responding in the expected way.

Show domain level:

samba-tool domain level show

List users:

samba-tool user list

Check DNS SRV records:

host -t SRV _ldap._tcp.lab.example.internal
host -t SRV _kerberos._udp.lab.example.internal

Kerberos check:

kinit administrator@LAB.EXAMPLE.INTERNAL
klist

Step 10 — Firewall Notes

If the firewall is enabled, Samba AD needs the relevant traffic to be allowed. In a small lab, you may choose a quick broad rule first and refine later.

Fedora / firewalld example

sudo firewall-cmd --add-service=samba --permanent
sudo firewall-cmd --reload
That may be enough for early lab work, but production-style firewalling deserves more precision than “shrug and open samba.”

Common Mistakes

  • Provisioning the domain before setting the hostname
  • Using an unstable or DHCP-changing server IP
  • Ignoring time synchronization problems
  • Pointing DNS to the wrong place after provisioning
  • Forgetting that service names can differ by distro packaging
  • Trying to reuse an already half-configured Samba installation without cleaning it up

Where This Goes Next

  • Join a Fedora or Debian client to the domain
  • Join a Windows machine to the domain
  • Add shares and test access controls
  • Experiment with centralized authentication workflows
  • Document DNS and Kerberos troubleshooting as separate notes
This page is meant as a foundational homelab note, not the final word on Samba AD. The next logical notes would cover client joins, DNS troubleshooting, and resolver / Kerberos debugging.