SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hello, After a report of a problem with a Samba AD DC on Slackware 15, I thought I better see for myself. I have installed Slackware in a VM and it runs pretty well, so I moved to starting the process of joining Samba on Slackware to my Samba AD domain as a DC, to find two problems:
1) the latest version of Samba on Slackware is 4.15.13 (which I can live with)
2) I ran 'smbd -b | grep HAVE_LIBKADM5SRV_MIT' and got back 'HAVE_LIBKADM5SRV_MIT'. This means that Slackware is using the experimental version of Samba and I cannot have that in my domain.
Why is Slackware using MIT ?
Is there anywhere that I can obtain Slackware Samba packages that use the correct Heimdal ?
That doesn't answer my first question, why is Slackware using '--with-experimental-mit-ad-dc', didn't they notice the word 'experimental' ???
If they did, why don't they advise their users to not use their Samba packages as a DC in production ???
Does it create a problem? I went with MIT since that's what the rest of the system uses, and because Red Hat (who have several developers on the Samba team) also went with MIT and I trust that it works. But if using Heimdal is 1) compatible with having MIT Kerberos elsewhere in the system and 2) works as good or better, I could possibly see switching in -current, and will at least make this easily configurable in the SlackBuild.
IIRC the primary reason that Red Hat / Fedora are using MIT Kerberos is due to FIPS requiring it, which isn't an issue for us.
Realistically, given that Samba struggles with features such as GPO Security Filtering in larger scale applications, you're probably taking a risk using it in "production" anyway.
For the small office or home user, it is a trivial exercise to switch to the embedded Kerberos if the MIT Kerberos doesn't suit your application. Personally, I'm still experimenting with Samba in virtual machines, to try and work out how to get the best out of it for my use case. I still have a lot to learn. So far, due to time constraints, I've only managed to try the stock Slackware package which uses the MIT Kerberos. It seems to work OK... or at least, it has managed to do everything I've asked of it so far.
No, they just want you to use their product 'FreeIPA'
Quote:
Realistically, given that Samba struggles with features such as GPO Security Filtering in larger scale applications, you're probably taking a risk using it in "production" anyway.
GPO's with Samba are getting better all the time. Also there are some extremely large Samba domains being used in production. You can get SUSE, RHEL, Ubuntu and AIX Samba packages that can be used for an Heimdal based DC from Sernet.
Quote:
For the small office or home user, it is a trivial exercise to switch to the embedded Kerberos if the MIT Kerberos doesn't suit your application. Personally, I'm still experimenting with Samba in virtual machines, to try and work out how to get the best out of it for my use case. I still have a lot to learn. So far, due to time constraints, I've only managed to try the stock Slackware package which uses the MIT Kerberos. It seems to work OK... or at least, it has managed to do everything I've asked of it so far.
There is more to it than just using Heimdal instead of MIT, suppose that Samba found what they think is a security problem with MIT, Samba would have to convince the MIT maintainers that this was the case and then wait until they decided to fix it, whereas with the bundled Heimdal, they can and do work with the Heimdal maintainers and get the fix out the door very quickly.
There are problems with running a Samba DC with MIT, which is why you have to use the '--with-experimental-mit-ad-dc' ./configure switch to use it.
In my opinion (for what it is worth), Slackware should either go the RHEL route and provide Samba packages that cannot be provisioned as domain DC, or be honest and tell everyone that their Samba packages are experimental when used for a DC, or just use the bundled Heimdal.
Debian has supported running a Samba AD domain using Heimdal since Samba 4 was released.
Commercial support?
Quote:
Originally Posted by rpenny
In my opinion (for what it is worth), Slackware should either go the RHEL route and provide Samba packages that cannot be provisioned as domain DC, or be honest and tell everyone that their Samba packages are experimental when used for a DC, or just use the bundled Heimdal.
Per post #2, it is literally a <10 minute exercise to switch.
Per post #2, it is literally a <10 minute exercise to switch.
There are numerous providers of commercial support for Samba, amongst them are Catalyst and Sernet
Yes, but you shouldn't have to switch, either be honest and admit that Slackware packages shouldn't be used in production for an AD DC, or make them capable of being used in production.
There are numerous providers of commercial support for Samba, amongst them are Catalyst and Sernet
That is not exactly true.
Sernet provides custom samba packages for several distros that DON'T support samba as a AD DC, and sell you support for THOSE packages...
SAMBA+ introduces an Active Directory domain controller to RHEL and SLES.
Samba packages provided by Red Hat do not support a domain controller setup in RHEL. The same applies to SLES, which can be enabled to be an AD domain controller (AD DC) with SAMBA+.
Quote:
Originally Posted by rpenny
Yes, but you shouldn't have to switch, either be honest and admit that Slackware packages shouldn't be used in production for an AD DC, or make them capable of being used in production.
First, nobody is being "dishonest" by saying that Slackware's samba packages can be used to make an AD DC.
Second, you are unwilling to spend a few minutes of your time to change the slackbuild and recompile samba to suit your needs... yet you point to companies that do it for RHEL and SLES...
Why not contact Sernet and have them build a custom slackware samba package that does what you need?
That is not exactly true.
Sernet provides custom samba packages for several distros that DON'T support samba as a AD DC, and sell you support for THOSE packages...
First, nobody is being "dishonest" by saying that Slackware's samba packages can be used to make an AD DC.
Second, you are unwilling to spend a few minutes of your time to change the slackbuild and recompile samba to suit your needs... yet you point to companies that do it for RHEL and SLES...
Sernet will provide you with support (at a price) for Samba, even if you do not use their packages.
I never said that you couldn't use the Slackware packages to create a Samba AD DC, I said you shouldn't use a Slackware AD DC in production, there is a difference.
Who said I was unwilling to recompile the Slackware packages ? I said that I shouldn't have to, again there is a difference.
Does it create a problem? I went with MIT since that's what the rest of the system uses, and because Red Hat (who have several developers on the Samba team) also went with MIT and I trust that it works. But if using Heimdal is 1) compatible with having MIT Kerberos elsewhere in the system and 2) works as good or better, I could possibly see switching in -current, and will at least make this easily configurable in the SlackBuild.
IIRC the primary reason that Red Hat / Fedora are using MIT Kerberos is due to FIPS requiring it, which isn't an issue for us.
Wed Feb 1 05:29:53 UTC 2023
d/perl-5.36.0-x86_64-3.txz: Rebuilt.
Upgraded: IO-Socket-SSL-2.081, Moo-2.005005, Path-Tiny-0.144,
Sub-Quote-2.006008, Template-Toolkit-3.101, URI-5.17.
Added: JSON-4.10 (needed to build Samba with --bundled-libraries=heimdal).
kde/kstars-3.6.3-x86_64-1.txz: Upgraded.
l/gjs-1.74.1-x86_64-1.txz: Upgraded.
Compiled against mozjs102-102.7.0esr.
l/mozjs102-102.7.0esr-x86_64-1.txz: Added.
This is required by gjs-1.74.1 and polkit-122.
l/mozjs78-78.15.0esr-x86_64-1.txz: Removed.
l/polkit-122-x86_64-1.txz: Upgraded.
Compiled against mozjs102-102.7.0esr.
# This option may also be set to "heimdal":
KERBEROS=${KERBEROS:-mit}
if [ "$KERBEROS" = "mit" ]; then
KERB_OPTIONS="--with-system-mitkrb5 --with-experimental-mit-ad-dc"
elif [ "$KERBEROS" = "heimdal" ]; then
# Please note that this perl module will be required: https://metacpan.org/pod/JSON
KERB_OPTIONS="--bundled-libraries=heimdal"
fi
As previously stated, I'm still on a voyage of discovery with Samba. Unfortunately, work and family life means I don't have a lot of spare time to tinker, so my experience with Samba is quite limited... and the wheels of progress are turning slowly...
So consider these some observations on my quest for knowledge!
Quote:
Originally Posted by rpenny
No, they just want you to use their product 'FreeIPA'
You might be right, but I will note that that program is free to download and licenced under the GPLv3... so it's not necessarily going to bind anyone to Red Hat. In fact, they offer pre-compiled packages for several other distributions (and source code) on their website.
Quote:
Originally Posted by rpenny
There are problems with running a Samba DC with MIT, which is why you have to use the '--with-experimental-mit-ad-dc' ./configure switch to use it.
These words seem to fly around a lot, but if you keep reading those instructions (or whatever forum you're on) you will generally find that the highlighted issues are already fixed.
Further to Patrick's comment above about Red Hat developers, I found a post in this thread on the Fedora forums, dated November 2019 from a senior Red Hat engineer based in Finland:
Quote:
Originally Posted by Alexander Bokovoy on Fedora forums
The statement was made to make sure people who have no idea what various backends within Samba mean don't create environments that cannot be realistically supported by upstream right now.
There is ongoing work on making both MIT Kerberos and Samba to work together properly in Samba AD DC environment. This work continues for eight years already, sponsored by Red Hat, and shows the level of complexity that we have to deal with.
To get you a bit of understanding where we are in this area, Isaac Boukris found last year a number of security issues with Kerberos implementations in Windows, MIT Kerberos, and Heimdal that basically made all Active Directory implemenations broken:
Isaac also added support for constraint-based resource delegation to MIT Kerberos this year (https://github.com/krb5/krb5/pull/912) and is working right now on fixing remaining S4U implementation details to allow Samba AD DC with MIT Kerberos to be a thing. The latter spans to both projects. A note: Heimdal implementation misses protocol compatibility in this area by a long shot and Samba AD DC with Heimdal does not behave correctly in quite a number of places. It ignores some of the real checks required by the MS-KILE specification completely.
The opinions of senior engineers carry some weight, no?
Quote:
Originally Posted by rpenny
Yes, but you shouldn't have to switch, either be honest and admit that Slackware packages shouldn't be used in production for an AD DC, or make them capable of being used in production.
As per previous poster, nobody is making the claim that Slackware's standard Samba package can or should be used in production for an AD DC.
Secondly, perhaps the whole "incapable of being used in production" argument is somewhat dated now? I mean, the Samba wiki has a page explaining how to migrate to MIT Kerberos: https://wiki.samba.org/index.php/Run...he_Heimdal_KDC. Why would it be there otherwise?
As previously stated, I'm still on a voyage of discovery with Samba. Unfortunately, work and family life means I don't have a lot of spare time to tinker, so my experience with Samba is quite limited... and the wheels of progress are turning slowly...
As per previous poster, nobody is making the claim that Slackware's standard Samba package can or should be used in production for an AD DC.
Secondly, perhaps the whole "incapable of being used in production" argument is somewhat dated now? I mean, the Samba wiki has a page explaining how to migrate to MIT Kerberos: https://wiki.samba.org/index.php/Run...he_Heimdal_KDC. Why would it be there otherwise?
1) My experience of Samba is quite a lot
2) It doesn't state that they should be classed as experimental either.
3) Perhaps you should take a look at that Samba wikipage again, thanks for pointing out that omission, which I have now added.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
