I have read a couple of threads where the domain controller appliance cannot be used as a domain controller in Server 2019 network due to the outdated Samba configuration. Which is understandable.

However can someone clarify if the file server appliance can be joined to a Windows domain and act as a simple file server and it would be transparent to users. For example you can map a network drive in Windows client and set up permissions.

Thanks
Paul

Forum: 
Jeremy Davis's picture

Windows AD is a closed source application that is not fully documented publicly. So Samba's AD support is reverse engineered. As such it will always lag behind Windows. The most recent release of Samba is fully compatible with the Server 2012r2 AD schema (version 69). It's quite possible to use Samba as a Domain Controller for AD and connect Windows 10 desktop computers to it. You even should (at least in theory) be able to connect it to an existing Windows Server 2019 AD domain, so long as it is using the Server 2012r2 schema. If you already have an AD with a newer schema version, then you would need to downgrade that first. I have no experience with that, but personally must say that it sounds dangerous and probably wouldn't recommend it unless you know what you are doing...

Having said the above, the version of Samba in TurnKey Linux (v4.9) is getting a bit dated and doesn't have full support for Server 2012r2 AD schema (it's classified as "experimental support"). The next major release of TurnKey Linux (v17.0 - based on Debian 11/Bullseye once it becomes stable and we've completed the required upgrades to our build code) will have a much newer version of Samba (v4.13) which will provide full support for Server 2012r2 AD schema/v69.

As for actually answering your question, TBH I don't know. I suspect that it would work fine, but I can't be 100% sure. At least in theory, you could start with any of our servers which include Samba (e.g. Domain Controller, or Fileserver appliances), then you could reconfigure it as a domain member?!

If you give it a go, I'd be really interested to hear how it works out.

EMMANUEL CASTRO NETO's picture

Hey guys. I'm new to the Linux world. But I'm having the exact same problem with our colleague Paul. I want to include a samba server as a member of an existing Windows 2019 AD. As a member he enters normally. I tested the connections and everything works perfectly. However, no member of windows can access the shared parts. Prompt for authentication password as if kerberos could not authenticate the domain user. I did this in debian11  I'll try now on ubuntu, but I confess I think it's the incompatibility of Samba x Windows 2019 Server. If you find any solution I'm happy if you share. If successful, I'll come back with another post.
Jeremy Davis's picture

Samba does not support Windows 2019 AD schema. As I noted above, the latest schema it supports is 2012r2 (version 69).

I'm not sure if your password issue is related to the mismatched AD schema versions but I suspect so.

Good luck with it.

Any news on when V17 will be out ?

Thanks


Jeremy Davis's picture

Short answer is how long is a piece of string? ;)

We release when ready and we don't yet even have a clear idea of exactly how much work will be required. So it's really hard to even guess when it might be ready; let alone give a realistic estimate. Regardless, I'll share a quick update and give you my current guess (please be warned that I'm an optimist and am usually wrong by a large factor).


I have built a v17.0beta ISO (using default v16.x custom TurnKey components) and it appears to work fine. So the core of the OS appears to be pretty solid (as you'd likely expect from Debian).

So the next steps are for us to update our custom TurnKey components (i.e. the code that we develop/maintain to make our and/or our user's lives easier).

I'm currently working on di-live (our ISO installer). There are likely plenty of other bits and pieces that will be required, but that is the largest piece of v17.x that is blocking a Core v17.0rc ISO. The main thing I'm looking to add for v17.x is (very belated) EFI boot/install support and it's currently WIP (work in progress).

Currently blocking the v17.0rc of TKLDev (and stable release of any v17.x appliances) is a major upgrade of our build infrastructure components in TKLDev; in particular Fab (builds the OS and packages as ISO) and Pool (builds our custom deb packages) and dependencies. Stefan is currently working on these and is having some great progress.

As per v16.x (and v15.x), once we have the Core and TKLDev components is working order, we'll publish v17.0rc1 versions of Core and TKLDev.

After the RCs are released, we'll test buildtasks and update as required to build the alternate build types (AWS AMI, OVA, Proxmox LXC, etc). We'll also continue making updates to Common build code and start updating the individual appliance build code.

Once we have all the build types (or at least AWS AMI, OVA & Proxmox LXC) working, and we're happy with Core and TKLDev, we'll build an initial "almost-stable" TKLDev v17.0. We'll then use that to (re)build our stable v17.0 releases of Core, TKLDev and any other appliances we have ready by then.


So there is still lots to do, but considering that until this week, I've really only been dabbling (whilst tying up loose v16.x ends), progress is going pretty well IMO. Fingers crossed and a smooth run, I hope to be publishing the (first?) RCs within a few weeks, to a month. Then stable apps within a few weeks, to a month of that. Hopefully that is a realistic guess, but there are many unknown unknowns.

If you would like to speed things up and help out with some development (even just some testing and bug reporting) then that'd be cool! Things are moving pretty fast at the moment though, and lots of stuff is broken. So unless you really want to get your hands dirty, then you might need to be patient for a little longer. Once the v17.0 RCs are published, then testing ISOs of appliances (that you build yourself on TKLDev) can start if you're keen?!

Add new comment