SambaDC is Not a Good Active Directory Replacement

It’s time to cut my losses. Ten years ago I setup Samba as a Domain Controller in my lab so I could learn Group Policy things. At the time I was scared of Windows Licensing, already comfortable with Linux, and didn’t know any better (GPO support was never 1-for-1 with Microsoft). I recall that setup fondly, but that’s probably the nostalgia talking. In my previous update I mentioned that my new scripts might build a good license-free solution for a small business that needs Active Directory. In an attempt to downgrade my home lab, I planned on installing two Samba domain controllers on a Raspberry Pi 4 and managing them with Incus. The more I learned about the limitations of Samba as an Active Directory domain controller the more I understood why I wouldn’t ever want to do this outside a lab. Today is the day that I abort the project. I have successfully installed a single Samba as a domain controller on Debian Trixie, but I will not be continuing my adventure to add a second DC and here’s why.

Samba DC feels outdated

The latest and greatest version supports forest functional level 2016, but the docs say it’s a work in progress and shouldn’t be used in production. After install, the functional level was listed as 2008, which isn’t a deal breaker because most features are going to work, but compatibility with actual Windows servers can be a headache and some features, like AD recycle bin, are missing from 2008. The docs say the default is 2008r2, but that’s not what the RSAT tools reported. In this project I did not attempt to raise the functional forest level of my newly deployed Samba DC, but that leads me to the next thing which is version availability.

Samba DC is a Pain to Install

Higher functional levels became available in versions 4.19 and above. As I mentioned, I built a script that takes care of the install process on Debian Trixie but finding the right distribution that allowed me to do this from default repositories was a challenge. Debian and Ubuntu had different versions with no easy way to update with Apt, and RedHat variants had no domain controller packages. I know I could have compiled my own from source, but in my opinion that’s a very old way of doing things. In today’s environments technology changes quickly, cyberthreats evolve continuously, and employee turnover is high. Building a custom domain controller for every upgrade can be cumbersome and error prone. I’m not saying it’s impossible, but I am saying there’s a steep learning curve and I wouldn’t recommend it for the faint of heart, or a modern busy admin. Perhaps I’ll revisit this later.

Samba DC Does not Have Built-in Replication

Quite honestly replication is one of my favorite AD features. I can stand up two domain controllers almost simultaneously and they automatically replicate data across the two. The directory, DNS, files, and policies replicate between the two so if one server goes down, the end users and devices are not affected at all. When I discovered that I would need to setup replication manually with Samba I was not very happy. I don’t know the file structure or database well enough to feel confident that I’m replicating EVERYTHING and I could tell it was just going to be time consuming. Then imagine if I setup a third domain controller. I’d have to do it all over again. This is where I nearly quit.

Samba DC Does not Support PowerShell (ADWS)

I continued on. Samba-tool gave me errors (vague non-actionable errors) related to my password when I tried to change the admin password. I was frustrated and did not troubleshoot. I joined a Windows 11 workstation to the domain and browsed the directory with RSAT tools. Finally, I exported a list of organizational units from my old domain and attempted to import them into the new domain with PowerShell. Samba does not support Active Directory Web Services which means PowerShell cmdlets will not work. And that’s where I stopped. I know I could probably Script this with samba-tool in bash, but this was the straw that broke the camel’s back.

I Had the Wrong Idea

As a Windows Admin I wanted to emulate AD functionality without worrying about Server Licensing or CALs, but the lift is too heavy at a small scale. After this experience, I’m struggling to find the benefit for using a Samba server as a domain controller. FreeIPA feels like a better directory/ldaps/domain solution, and Microsoft’s Active Directory is superior to both. Group policy parody was my initial desire, but features aren’t one-to-one with Microsoft, per Samba docs, and since remote Admin is more complicated and replication is not built-in I see very little benefit. I didn’t even tackle compatibility with other Microsoft features like PKI, or the nearly deprecated Exchange Server. In fact, the more I think about it, the more I believe a small business would benefit from something cloud hosted like M365 because then email, identity (Entra), configuration (Intune), file shares (OneDrive) and Office licensing would all be under one subscription with no infrastructure, albeit expensive.

Opinions, please!

Is anyone using the functionality in a production environment? Does it work for you? Are you up to date? What’s your environment look like (all on-prem I presume)? Have you heard of sambabox? Sambabox looks like a paid solution, cheaper than Microsoft, and with plenty of built in features.