Jeez, it’s not just implementation of a replacement solution, but also looking at migration of all our current installs.
Just wanted to thank everyone on this thread for the hard work they are putting into this future issue. If I may I’d like to confirm a few things.
- When potentially could the loss of AD in Nethserver become an issue, as in how many months or years could this become an issue?
- If support from Red Hat was removed from newer versions, and if Nethserver cannot find a resolution, could conceivably an upgrade to a newer version of Nethserver remove Samba if it was installed or would Samba still remain but just not be upgrade? I guess I’m wondering if Nethserver modules not supported any longer are automatically removed if they are installed.
I know you are all working hard to understand this issue and find resolution. From my standpoint I’ve recently implemented Samba 4 (LDAP with AD) in our small office using Nethserver and it’s working extremely well for us. But in order that I be aware of future issues that may affect our office I’d like to understand when support by Red Hat could begin to impact our use of Nethsever as our domain controller? I’ll be keeping my eye on this thread and will let people smarter than me continue their investigation, but I would like to ensure I know when this will become critical so I can plan for mitigation if the need should arise.
I agree, a migration path must be possible
They never offered support to Samba DC. It seems they won’t do it in the future too. Their decision has no impact on existing NS7 installations.
We’re only thinking what is the best choice for NS8.
The Samba Active Directory accounts provider will be available until NS7 EOL, around 2024. See the release notes for the exact date.
No, see above.
That shouldn’t happen. If that happens (see amavisd/rspamd) an equivalent replacement is provided. But I see no reason to remove Samba DC in ns7.
I must say that the discussion with Niels de Vos from RH/Storage group and the Samba guy was giving lots of hints opportunities and directions. But When reading some more about creating Samba packages, especially with MIT Kerberos, I feel we are diving in a very uncertain future.
A few things that I want to mention. From the Samba wiki I read that MIT Kerberos support is still experimental. Besides that there are quite some features still not supported. I know, they MAY be supported in the future, but currently they are not:
Known Limitations of MIT Kerberos Support in Samba
Samba DCs with MIT Kerberos KDC currently do not support:
- PKINIT support required for using smart cards
- Service for User to Self-service (S4U2self)
- Service for User to Proxy (S4U2proxy)
- Running as a Read only domain controller (RODC)
- Authentication Audit logging
- Computer GPO’s are not applied, see Bug 13516**
At first glance these unsupported features seem to be a showstopper.
On the other hand, I would like to raise the question: If we are to build the packages ourselves, Why not build them with Heimdal Kerberos (like the .deb distro’s are doing)? We currently run the linux container with the Heimdal packages and the .deb distro’s already have a few years of experience with this. You can consider MIT as superior any time, but if it lacks the features we need, we just can’t use it. (just being pragmatic here)
Alternatively we can keep things as we have now: a linux container running samba4 AD. But I understand it is quite difficult to develop using this option.
Another thing to consider is the problems when Samba4 AD and Samba FS are running on the same instance. @davidep mentioned that there were quite some stability issues and a server needed regular (service)restarts to remain stable. I think this needs more investigation before being able to make a weighed decision in what option to choose.
The last option: dropping Samba4 AD to me seems a showstopper too. We have a LOT of Windows (Small Business) Server replacements in our community. A lot of our members are going to or have migrated from an AD environment. Their client machines are mostly (probably 95%+) Windows based. UNLESS there is a viable windows client management option (I don’t know any I and I don’t think there is) I don’t see we can drop Samab4 AD support.
Some things that need to be investigated:
- Current status of MIT Kerberos implementation in Samba (some of the samba wikipages mentioning MIT kerberos date back to 2012)
- Impact on creating Samba4 packages ourselves (either MIT or Heimdal kerberos)
- Limitations for either MIT and Heimdal kerberos
any other thoughts?
Thank you @davidep for taking the time to answer my questions.
6 posts were split to a new topic: How many NS installations use Samba DC
That’s annoying but I don’t think they are real showstoppers. Should be fixed anyway…
I have one DC at our office, still struggling with a win2012-r2+sqls 2008-r2 to migrate on the new DC/NS.
I wonder if I need to begin to ask for quotes to M$.
Is sad to read about red hat and their decision.
Hopefully NethServer will stay on the way to support DC.
On the other edge of the blade: discontinue the Samba DC option will generate:
- fellows that will abandon the distro for some other one which provide it
- possible fellows who are looking for an upgrade/migration platform (like the 3-Sme server guy landed few days ago) from their current distro to another one with the same integration options will put out NS from the list (why they should migrate to something that will leave a feature that they have?)
- possible fellows that are running away from Microsoft solutions (and related privacy issues… Did you try recently to add an user on Win10 1803 or 1809? Security questions are not editable … and if you want add a user without store any information you have to deal with “old but gold”
NET USEsyntax… i’m afraid of the next version who could force you to register a Microsoft Account (as Android and MacOS/iOS currently do)
Leaving the feature will cut a bigger rope than IBM/RedHat’s sliced for RHEL8. They’re big enough for not being interested on SMB/Windows customers (potentially higher revenues).
But SMB seems core adopters for this distro, and core business for Nethesis.
IMVHO: leave AD Controller is not an option.
Or better: project should find/integrate a Killer Application that will make consider AD not that necessary. But i have no idea of what this could be…
To give up AD controller is not an option IMO.
If an LDAP account provider is selected or there is no account provider at all, any access to shared folders is considered as Guest access so that everyone is allowed to read and write its content.
That said, NS wouldn’t be able to provide ACLs to SMB shares. NS is meant for SME, Small and Medium Enterprises. I can’t imagine a SME, that has no need for any SMB-share with ACLs.
Sorry to resurrect this thread, just stumbled across it. Thanks for your good thoughts.
I feel your pain…
Our use case is that we’ve been limping along with a centos 6 build with an old version of sernet samba, like version 4.1.xx as a ADDC for our small business network. Works fine, but on ancient hardware, overdue to replace.
We’ve been looking for a replacement, waiting for Centos8 or Samba to support SambaAD on Centos, and was looking at nethserver, but it looks like I’m still caught out. I suppose we will try Ubuntu with Samba-dc, my impression is that it works and is supported. I guess that doesn’t help you.
A couple of thoughts, perhaps they are naive…
Firstly, there is a service and software company in France called Tranquil.it that supports a version of Samba as a Domain Controller. They apparently are building a Samba which works on Centos 7 and debian, and are maintaining rpms and debs, for their clients, and hosting it for the community version. They have a build of 4.8.9 as recently as May this year.
They are hosting the RPMs: http://azzurro.ezplanet.net/el7/
They have some support via a forum, wiki and mailing list (in French) Google translate helps with this.
There is very interesting documentation
Their wiki is a good link to their builds
The also have a discussion of how to compile for MITKerberos.
I’m not certain that they have gotten around the samba4 / MIT kerberos bugs and limitations such as of GPO’s not being applied.
They apparently have quite a bit of skill implementing Samba4AD as a solution, I don’t know how actively they are supporting Centos 7, let alone how they will handle Centos8.
Just thinking they may be a good resource, or possibly a partner that could build and support your samba4 rpms.
Good Luck, I would appreciate any feedback,
Hi Peter welcome to NethServer community and thank you for your post!
Why didn’t you consider NS7? What features are you lacking?
Hi Davide, thanks for checking in.
I guess I am considering ns7, though I haven’t really been concerned about a supported distro. We use the basics, DNS, DHCP, NTP, SMB, GPO, ADDC, MySql. all of which has been baked into Centos til this issue with samba-dc. We started with centos 4 and samba3 nt4 domains, then built a centos6 with samba4.whatever build sernet last released as open source. Webmin, whatever desktop, bash and rsync is plenty for our admin access. Truth is we hardly ever touch it, and the hardware we have it on barely runs at idle. We’ll probably run our next DC on a windows 10 hyper-v instance on a low power server, and maybe spin a backup DC on a cloud instance.
We have a couple of dozen windows desktops authenticating from a single physical location. We install a handful of apps on them with Group Policy, and set a few things like dsn’s and drive mappings, and we value centralized acl management. We have maybe a scant TB of files, mostly photos and video. The whole thing is behind a fire wall. Our email, backups, most of our shared files are mostly with google/ g-suite and and a hosted web server off-site which has cpanel and runs drupal and civicrm.
Our client hardware is any-old used $100 dell desktop with windows 10. We need windows for our in-house vba apps, quickbooks, adobe. When one craps out, we drop another on the user, join the domain, pull the memory and a few parts out of the machine and recycle it.
Our hardware is a 10 or 12 year old xeon superserver, which really needs replacing. It burns like 400 watts at idle, and sounds like a leaf blower. I figured we’d skip a generation, go to centos 8 since we’ve never really been able to get past the REHL7 / samba 4-dc / mit vs Heimdal thing for the DC.
Of course, even though we’re fairly snug behind the firewall, I shouldn’t be running unpatched apps, and I don’t really want to build my own Samba. so I should have a provider for samba security updates.
I think the conclusions of your users, above describes us also. I understand that those of us who are interested in an opensource alternative for domain authentication and provisioning of windows desktops are by definition technically capable, low profit, avoiding spending thousands a year to support through a var. I get that larger companies like MS, RH, Samba+ aren’t interested in supporting us.
I’m glad Nethserver is focused on the small business market, and I’d be glad to go with NethServer. I may be able to contribute a bit to the community as well.
How did you get around the ADDC thing with Centos 7?
We have two instances of Samba. The first upstream/rhel one is the file server, and the second one runs the DC in a Linux container with its own IP address.
There’s plenty of discussions in this forum about this choice. Just as a starter: I still don't get why Samba has to be run in a container
The file server receives official rhel patches. We recompile the DC from the Samba vanilla source code which ships all the security patches we need. Their dev lifecycle has been sustainable so far and even minor upgrades of the DC ran smoothly, far better than rhel minor upgrades!
Here we’re discussing two distinct levels of issues with AD:
- the complexity of our architecture, required to be an all-in-one distro, compatible with previous ns6 version
- the complexity of an AD network, a nightmare for a support team, even for Red Hat’s one
Very interesting. Thanks for pointing out that discussion. I’m also looking at your documentation. Sorry I don’t really have time to install and really look at it. I appreciate your help in understanding your environment.
It actually makes some sense to keep ADDC separate instance from file serving, its recommended by samba anyway.
I see you are nspawn for the container. Re-reading @robb post above I’m understanding you are using heimdal binaries on your fedora container, and robb is considering you use a debian container, and you could use debian packages for samba, without building from source.
Is that correct?
So you might have some support/ configuration issues related to the supporting a non-fedora container, but the advantage is if there are issues with the debian Samba-ad build, you know where to find bug reports (at debian/ubuntu/samba)
It seems to me that MIT support in Samba-AD is sitting dead in the water at this time, and RH’s position may mean that Samba has little interest in working much more on AD support for RH. It works fine on Heimdal, why take the time to fix for MIT/ RH who doesn’t care?
How does sernet get around this, they claim to have full ad on centos7. Do they have some way to have heimdal coexist with MIT, or do they have fixes to the bugs that they aren’t upstreaming, or are they just not reporting that GPO doesn’t work on their build?
Thanks again for your time helping me understand, Davide
I have also looked pretty closely at the freeBSD arena, freenas and whatnot. They have nice vm/jail web management, and ZFS is very interesting, but although they offer commercial support, it seems that their community user base are largely hobbyists and media-server guys, the community support may not provide many clues with SME use cases similar to ours. And FreeBSD seems to have a pretty grumpy developer base, is way big and scattered, and slow and political about moving forward. Since the license is totally free, I think many distros take the code, add their own applications and fixes, and never give back to the source. So far I’m opting to stay with a fedora or debian based system, namely CentOS and Ubuntu.
I suppose that my next step would be to try the debian side, say at ubuntu-bionic. I would probably use Hyper-v to host the vm for testing.
If you are considering using a debian nspawn container in the future for your samba-ad, I could of some help to you in testing our use-case, and helping with documentation. This assumes that spawning ubuntu-bionic, handling networking and management, upgrading and backup of the clients is straightforward.
This would give you an alternate module to FS7-DC for testing and consideration. If Samba or RH perfects and supports AD in the future on MIT, then the option exists to have your all in one server, but users who prefer to containerize their servers are free to do so. I pretty much like the idea of containerized services over an all in one solution.
Assuming that’s successful, over time, I’d be interested in getting BindDLZ in place on the DC, having BIND, DHCP, NTP modules where replication/ clustering and failover could be implemented.
I’m also interested in MySql or MariaDB servers, and i’m very curious about Percona, especially for their Backup, Monitoring and other tools.
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.
I’ve found an article on installing Samba on CentOS 8. Perhaps it could help.
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).