I guess people just use samba 3.x as a shorthand for NT4 domains, and samba 4.x as Samba-ADDC domains (server2003/2008/2012) all are available from a single samba 4.x codebase. I also think people often confuse file/ Printer / acl sharing (which is about the same from nt4 to AD) with domain management and provisioning of windows clients.
Domain management has a couple of parts: Authentication and rights (operate about the same from the admins perspective from NT4 to AD, but provide the security enhancements of kdc and the convenience of central database with LDAP) compared to client provisioning parts (central management of GPO’s, software installation, etc) The client provisioning parts (With a LDAP/ Kerberos foundation) and the concepts of Member servers, replication with FSMO roles which define AD server hierarchy, replication, and provide methods for the admin to build redundancy and recovery options.
NT4 server used PDC/ BDC roles which are more limiting. AD uses dns rather than netbios.
I suspect that the fact that RH/Centos 6 never built Samba4, then Centos7 supplied samba 4x (but without DC) makes it that much more confusing. Centos 6 users could rely on sernet’s 4.x rpm repos until they made them payware and stopped supporting security changes freely at that level.
I think neither of us considered that path, to avoid dealing with two different upstream/ecosystems.
Instead we’re already building Samba DC with default builtin Heimdal libraries. It is even possible to make them co-exists on the same system with a MIT install, thanks to samba build --prefix= option: this possibility could even simplify the current nspawn container by removing the need of a complete filesystem / dir for it. That would simplify system upgrades.
The technical challenge is preserving simplicity and backward compatibility of the ns8 architecture.
BIND could be considered, but it’s too early to say it: a working prototype is needed, preferably running on a CentOS 8.
RH decision on Samba is a well known POLITICAL decision.
Nothing else is involved.
For projects like NS I say AD is vital for their target audience. So a better solution has to be found.
I wonder if the project needs to keep being based on CentOS (but I open another can of worms I know).
We know it very well, but without CentOS/RedHat support this is not an easy choice.
We should start a new journey alone and we have to be aware of what it really means
Sticking to CentOS is anyway a quite good path, even with bad/not shared decision who took.
But we have to face that “shared folders” suits homes, maybe small offices, because it does not scale well, or scale at all.
It don’t scale for outsourcing. And it don’t scale for setup outside premises. Or mobile devices.
Yes, you can make it work (VPN and fast connections) but the current status is that applications (web or not) are the day-to-day use.
Even Microsoft faded to something different (SharePoint has its own success, just like Exchange, which now is quite more reliable and functional as mail/application server), still offering shared folders.
I hope that nethserver will persist with container for let users still have that option. But the LDAP-Centric current structure is the key to evolve without revolution the project.
Because authentication can be delivered via LDAP to any kind of authentication server, currently (better using TLS).
Don’t mind to keep track of the evolution of X500 too…
Hi to all,
it looks like CentOS 8 isn’t supporting samba active directory and won’t support it at the future.
I think there are several servers out there which run samba active directory with Nethserver 7.
I created this thread to collect ideas, how to solve this. Here should erase a list of these ideas:
a container with debian and samba ad at the Nethserver8 installation (best way choosing it from software-center)
a second virtual machine with debian or nethserver 7 (till it’s not supported anymore)
another base for Nethserver 8 (I think that’s not so easy, because everything must be “converted” to the new distro and every developer has to do a lot of extra work)
Thanks to all who will spend their ideas here. Perhaps it can be a solution implemented by the @dev_team without loosing the advantage of using upstream-updates.
Hi Michael, the current Samba AD implementation of NS7 is not using an RPM from CentOS: I think it’s possible to continue like we are doing it right now…
We could ask ourselves if going on by this way is enough, or bad or whatever.
I’ve been using Nethserver as my primary domain for our small office and I do use GPO’s for various rules we need for our domain connected users/computers. I would prefer to use Nethserver as my primary domain if I was to use Nethserver 8. My Webop and Nextcloud access is all based on domain user access.
I’m not clear on my understanding this conversation of RHEL 8 and samba active directory. Is it still be discussed in the building the roadmap for RHEL 8 if Nethserver will be a domain controller like it was in Nethserver 7? Or is there a chance that Nethserver will drop Samba AD from Nethserver 8?
It’s a bit early to give an answer IMO. However saying if AD is useful or not is important to design NS8.
Here I see many people that want AD in NethServer and they hope it will be available in the future too. This is a clear direction that conflicts with the complexity of AD. I hope we’ll find a good solution for everyone!
I think many installations are using authenticated access to shares, at least in a office environment.
To have only public access to shares is not an option IMO.
Nethserver calls itself a “perfect solution for small and medium enterprises”.
If there’s no other way to have authenticated access, the AD is a must have I think.
Even in a privat environment it would be a must have, or do you want to have your kids access to your data? I swear you, you don’t want it, when they are grown up to 15 or 16years!
)
