I will sing Samba's praises, with caveats. If all you want is authentication, it's great. You can spin up RODCs very quickly for cloud stuff, and Samba consumes very little resources compared to Windows AD. Non-LDAP replication can be handled by simple rsync scripts run on cron/systemd timers, and basic group policy stuff works well. It's especially nice if you've got a mixed Windows/Linux environment, and want to simplify your authentication across OSes (you've got far more control over things like SSID-to-UID mapping with Samba than you do with AD).

The built in Samba DNS is very simplistic, and I would avoid it for any large deployment. Plan to use the BIND backend from the beginning (Samba takes care of GSSAPI/KRB auth for bind, and is very easy to deploy).

Modern samba-tool includes loads and loads of functions to fix a broken Samba install, and it's very unlikely you'll ever break it to a point where you can't recover, even if you avoid all of the best practices clearly laid out by the documentation.

Reasons to NOT use Samba: * You need complex device management / provisioning * You have lots of roaming users outside of your offices * You need sophisticated Windows application deployment * You want to use anything M365 related at all, no matter how simple or limited.

For all of these scenarios, pony up and pay for Entra/InTune. Yes, licensing sucks. But that's the cost of doing business with a large managed fleet. If you don't like that, use Chromebooks, in which case you're just changing the name on your monthly invoice from "Microsoft" to "Google" anyway.

Alternatively, go full zero trust / thin client, and force everyone in through RDP/Citrix/Parsec style setups, and entirely ignore end user devices. But again, there's unavoidable cost there too.

Doing large scale business means necessary cost in one way or another. Samba is great, but if you want all the corporate bells and whistles, you can't cut corners.