Running Active Directory at home or in a lab environment normally suggests Windows Server, but that also brings Windows Server licensing into the equation.
For a small lab, test environment, or isolated internal network, Samba can provide an Active Directory-compatible domain controller without requiring Windows Server.
In this guide, I build a dedicated Debian virtual machine on Proxmox, configure Samba as an Active Directory Domain Controller, and then manage the domain from a Windows client using Microsoft RSAT.
The end result behaves much like a traditional Windows Active Directory environment:
- Centralised user accounts
- Domain-joined Windows PCs
- Active Directory Users and Computers
- Group Policy
- DNS
- Kerberos authentication
- LDAP
- RSAT administration
The Linux server handles the backend, while most day-to-day administration can still be done from familiar Windows tools.
Why Samba AD?
I originally wanted a simple local Active Directory environment without needing to deploy and license Windows Server.
Samba includes an Active Directory Domain Controller mode capable of providing many of the core services normally associated with Windows Server AD DS.
This makes it particularly useful for:
- Home labs
- Test networks
- Training environments
- Isolated engineering networks
- Small internal domains
Once the domain is running, Windows clients largely do not care whether the domain controller underneath is Windows Server or Samba.
The Architecture
The setup used in this guide is deliberately simple.
Proxmox
|
└── Debian VM
|
├── Samba AD DC
├── DNS
├── Kerberos
├── LDAP
├── SYSVOL
└── NETLOGON
Windows Client
|
├── Domain Joined
└── RSAT
The important design choice is to give the domain controller its own dedicated virtual machine.
I would avoid combining this with Docker, web hosting, or other services because Active Directory relies heavily on DNS, Kerberos, LDAP and SMB ports.
Proxmox VM Configuration
I created a new Debian 12 virtual machine in Proxmox with the following specification:
CPU: 2 vCPU
RAM: 2–4 GB
Disk: 32 GB
Network: VirtIO
OS: Debian 12
A graphical desktop is not required.
I also recommend using a full KVM virtual machine rather than an LXC container.
Samba can be made to work inside LXC, but a VM avoids unnecessary complications with networking, permissions, DNS and Kerberos.
Choosing the Domain Name
Before provisioning Samba, decide on the domain name you want to use.
For this guide I will use placeholders:
DNS Domain: yourchosen.domain
Kerberos Realm: YOURCHOSEN.DOMAIN
NetBIOS Domain: YOURDOMAIN
Domain Controller:
adcu.yourchosen.domain
Replace these values with your own naming scheme.
It is worth getting this right before provisioning because renaming an Active Directory domain later is not something I would want to rely on.
Set the Server Hostname
Switch to root:
su -
Set the hostname:
hostnamectl set-hostname adcu
Check it:
hostnamectl
At this point the machine should report:
Static hostname: adcu
Configure a Static IP Address
A domain controller should have a static IP address.
First check the available NetworkManager connection:
nmcli connection show
Mine appeared as:
Wired connection 1
Before manually assigning the gateway, check the current DHCP configuration:
ip route
This is important because the gateway is not necessarily the first address in the subnet.
Once confirmed, configure the address.
Example:
nmcli con mod "Wired connection 1" \
ipv4.method manual \
ipv4.addresses 10.0.0.216/24 \
ipv4.gateway 10.0.0.1 \
ipv4.dns "10.0.0.10 10.0.0.11" \
ipv4.dns-search ""
Apply the changes:
nmcli con down "Wired connection 1"
nmcli con up "Wired connection 1"
Check the configuration:
ip -br a
ip route
cat /etc/resolv.conf
I also tested connectivity before continuing:
ping -c 3 10.0.0.1
ping -c 3 8.8.8.8
ping -c 3 deb.debian.org
Fixing the Debian DVD Repository
One small issue I encountered was Debian still attempting to use the installation DVD as an APT repository.
Running:
apt update
returned a cdrom:// error.
To fix this:
nano /etc/apt/sources.list
Comment out the line beginning with:
deb cdrom:
Then run:
apt update
apt full-upgrade -y
Install Samba and Kerberos
Install the required packages:
apt install -y \
samba \
winbind \
krb5-user \
krb5-config \
dnsutils \
acl \
attr \
rsync
If prompted for the Kerberos realm, enter your domain in uppercase:
YOURCHOSEN.DOMAIN
Check the Samba version:
samba --version
And verify the hostname:
hostname -f
Configure the Fully Qualified Domain Name
If:
hostname -f
only returns:
adcu
then /etc/hosts needs updating.
Edit:
nano /etc/hosts
Use something similar to:
127.0.0.1 localhost
10.0.0.216 adcu.yourchosen.domain adcu
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Now:
hostname -f
should return:
adcu.yourchosen.domain
Provision the Active Directory Domain
Stop the normal standalone Samba services:
systemctl stop smbd nmbd winbind
systemctl disable smbd nmbd winbind
Move the default Samba configuration:
mv /etc/samba/smb.conf /etc/samba/smb.conf.original
Now provision the domain:
samba-tool domain provision \
--use-rfc2307 \
--realm=YOURCHOSEN.DOMAIN \
--domain=YOURDOMAIN \
--server-role=dc \
--dns-backend=SAMBA_INTERNAL
Samba will now build the Active Directory database, DNS zones, SYSVOL, Kerberos configuration and domain structure.
Once complete, it should report information similar to:
Server Role: active directory domain controller
Hostname: adcu
NetBIOS Domain: YOURDOMAIN
DNS Domain: yourchosen.domain
Configure Kerberos
Samba generates a Kerberos configuration automatically.
Copy it into place:
cp /var/lib/samba/private/krb5.conf /etc/krb5.conf
Do not symlink this file.
Start the Active Directory Service
Enable Samba AD DC:
systemctl unmask samba-ad-dc
systemctl enable --now samba-ad-dc
Check the service:
systemctl status samba-ad-dc --no-pager
You should see:
Active: active (running)
Change the Administrator Password
If Samba generated the Administrator password during provisioning, change it immediately:
samba-tool user setpassword Administrator
This account will later be used to administer the domain.
Check the Domain
Run:
samba-tool domain info 127.0.0.1
A successful configuration should show something similar to:
Forest : yourchosen.domain
Domain : yourchosen.domain
Netbios domain : YOURDOMAIN
DC name : adcu.yourchosen.domain
DC netbios name : ADCU
Configure DNS Forwarding
Samba’s internal DNS server needs somewhere to forward queries that do not belong to the Active Directory domain.
Edit:
nano /etc/samba/smb.conf
Inside the [global] section, configure an upstream DNS server:
[global]
dns forwarder = 10.0.0.10
netbios name = ADCU
realm = YOURCHOSEN.DOMAIN
server role = active directory domain controller
workgroup = YOURDOMAIN
idmap_ldb:use rfc2307 = yes
The generated configuration should also contain:
[sysvol]
and:
[netlogon]
Do not remove these.
Make the Domain Controller Use Its Own DNS
Once Samba DNS is active, the domain controller should use itself for DNS.
Configure NetworkManager:
nmcli con mod "Wired connection 1" \
ipv4.dns "127.0.0.1" \
ipv4.dns-search "yourchosen.domain" \
ipv4.ignore-auto-dns yes
Apply:
nmcli con down "Wired connection 1"
nmcli con up "Wired connection 1"
Check:
cat /etc/resolv.conf
The result should resemble:
search yourchosen.domain
nameserver 127.0.0.1
Samba will answer queries for the local domain and forward everything else to the upstream DNS server.
Test Active Directory DNS
Restart Samba:
systemctl restart samba-ad-dc
Check the domain controller A record:
host -t A adcu.yourchosen.domain
Then LDAP:
host -t SRV _ldap._tcp.yourchosen.domain
And Kerberos:
host -t SRV _kerberos._udp.yourchosen.domain
Successful results should resemble:
adcu.yourchosen.domain has address 10.0.0.216
_ldap._tcp.yourchosen.domain has SRV record 0 100 389 adcu.yourchosen.domain.
_kerberos._udp.yourchosen.domain has SRV record 0 100 88 adcu.yourchosen.domain.
These SRV records are critical because Windows uses them to discover Active Directory services.
Test Kerberos
Request a Kerberos ticket:
kinit Administrator
Enter the domain Administrator password.
Then:
klist
You should see a ticket similar to:
[email protected]
with a valid krbtgt service ticket.
At this point the Samba domain controller is operational.
Joining a Windows PC
The Windows client must use the Samba domain controller as its DNS server.
For example:
Preferred DNS:
10.0.0.216
Do not leave the machine pointing only at the router, ISP DNS or a public resolver such as Google DNS.
Test the domain controller:
nslookup adcu.yourchosen.domain
Then join the Windows machine to:
yourchosen.domain
When prompted for credentials, use:
YOURDOMAIN\Administrator
Restart the PC.
You should then be able to log in using a domain account.
Managing the Domain with RSAT
This is where the setup starts to feel much more like conventional Windows Active Directory.
Install Microsoft RSAT on a Windows Pro or Enterprise client.
The main tools I use are:
- Active Directory Users and Computers
- Group Policy Management
- DNS Manager
- Active Directory Sites and Services
From here I can create users, groups, organisational units and GPOs without needing to manage Samba from the command line.
For everyday administration, the experience is very similar to managing a Windows Server domain.
Creating an OU Structure
One of the first jobs after bringing the domain online is to organise it properly.
For example:
YOURDOMAIN
│
├── Computers
│ ├── Workstations
│ ├── Engineering
│ └── Servers
│
├── Users
│ ├── Administrators
│ ├── Engineers
│ └── Service Accounts
│
└── Groups
This makes it much easier to apply Group Policy selectively later.
Group Policy
Samba AD supports Windows Group Policy through SYSVOL.
Using Group Policy Management from RSAT, policies can be created for things such as:
- Desktop settings
- Drive mappings
- Local security configuration
- Windows Update configuration
- Scripts
- Registry settings
- Password policies
- Firewall rules
The policy itself is created from Windows in exactly the way you would with a Windows Server domain.
Backing Up the Domain Controller
Because the DC is running on Proxmox, the VM can be included in normal Proxmox backup routines.
I would also document:
Domain name
DC hostname
Static IP
Gateway
DNS forwarder
Administrator credentials
Proxmox VM ID
For anything beyond a small lab environment, I would also deploy a second domain controller rather than relying on a single VM.
Useful Validation Commands
Check the Samba service:
systemctl status samba-ad-dc
Check domain information:
samba-tool domain info 127.0.0.1
List users:
samba-tool user list
List groups:
samba-tool group list
Check DNS:
host -t SRV _ldap._tcp.yourchosen.domain
Check Kerberos:
kinit Administrator
klist
Check Samba configuration:
testparm
Problems I Hit During the Build
A few issues were worth noting.
Proxmox VM Had No Internet Access
The VM had a valid-looking IP address but could not even ping the gateway.
The mistake was assuming the gateway address.
Temporarily returning NetworkManager to DHCP revealed the actual gateway:
ip route
Once the correct gateway was used, connectivity immediately returned.
Debian Was Trying to Use the Installation DVD
APT initially returned a cdrom:// error.
Removing or commenting out the DVD repository inside:
/etc/apt/sources.list
fixed it.
hostname -f Only Returned the Short Name
Active Directory needs the DC to know its proper FQDN.
Adding the server’s real IP and hostname to:
/etc/hosts
resolved this.
Windows Cannot Find the Domain
This is almost always DNS.
The Windows PC must use the Samba domain controller as its DNS server.
Active Directory relies on DNS SRV records to locate Kerberos, LDAP and the domain controller itself.
Final Result
The finished environment looks like this:
Proxmox
|
|
Debian VM
|
Samba AD DC
|
+-----------+-----------+
| | |
DNS Kerberos LDAP
|
|
Windows PCs
|
Domain Joined
|
RSAT
The result is a fully usable local Active Directory-style domain without needing Windows Server.
The part I particularly like is that Linux is almost invisible once the initial setup is complete.
Samba handles the domain controller services in the background, while Active Directory Users and Computers, Group Policy Management and the other RSAT tools provide the familiar Windows administration experience.
For a home lab, engineering environment or isolated test network, it is a surprisingly capable alternative to deploying Windows Server.