Temu AD

🤣

It's funny because it's true!

Seriously though, OP.

Just don't.

It was fine for NT domains and got along ok for a while until MS started giving a shit about hardening things that had been allowed to go lax in the name of NT4 compatibility and who knows what else for so long. It does not make for a good time in a modern AD environment, if operating as a legit domain controller.

So don't do it unless you're enough of an AD (and Linux, and Samba) guru that you don't need to ask the question you asked.

Group policy is painful.

You really need to not run SMB on a Samba DC other than the netlogon and sysvol for the dc.

Replication is painful.

Kerberos support is not actually supported in Windows-compatible form (MS uses MIT Kerberos), is rickety, and has big gapscin features, capabilities, and basic functionality you have out of the box in windows, including credential guard.

Documentation is even worse than Microsoft Server documentation for being randomly and painfully out of date. Blogs around the net are just as bad (or worse), plus a heaping helping of cargo cult administration in those.

It still accepts blank machine account passwords.

LAPS is broken past windows 10.

Linux is incapable of faithfully representing NTFS ACLs, which causes all sorts of fun edge cases issues with all sorts of things that mostly manifest as security holes you are not aware of or annoying but not show-stopping random access denied responses to normal system operations from windows domain members. It fakes it entirely through Samba itself, which also cant do the job fully because SMB ACLs are also not the same as NT ACLs (but at least are closer than Unix file modes, so get most of the job done most of the time). It makes heavy use of extended attributes to replicate as much of Windows ACL behavior as possible, and it REALLY amplifies the volume of tiny random IO for all operations (ZFS can actually help reduce the IOPS pain of that and supports NFS ACLs, too, which were based on NTFS ACLs...but linux does not natively support them, so you have some difficult hoops to jump through to make that all happen...).

Today, it is ok-ish as a print server or light duty file server, but really is woefully and dangerously inadequate in modern AD as a DC and is a nightmare to install, troubleshoot, configure, troubleshoot, test, troubleshoot, actually set up in production trusting that things will be ok, troubleshoot, find 50cworkaroubds for things that all just slightly don't work quite right, troubleshoot, authoritative ntds restore on your PDCe when you hose the production directory, troubleshoot, take a cold shower, troubleshoot, and drink yourself into an early grave, after the next monthly windows security update makes the Samba DC that you just finally got barely working kinda (a little) becomes unusable again due to a change announced years ago that Samba never had support for hacked into it despite the increasingly urgent announcements from MS along the way.

Shit, you can't even audit smb1 snd ntlm usage, on Samba today, as "well" as windows only recently got somewhat better audit log text descriptions for. And that's a looowwww bar.

Anyone who claims with their whole chest that Samba can participate in modern AD as a domain controller without introducing serious security issues doesn't know they've already been pwned.

Just use Windows for AD. Let Linux boxen join AD via kerberos and LDAP. That works well.