Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On ke, 12 helmi 2020, Dario Lesca wrote: Il giorno mar, 11/02/2020 alle 21.35 +0200, Alexander Bokovoy ha scritto: There are few more missing parts here and there that need to beimplemented. They might affect some use cases and not others. At thispoint, I'd suggest to open bugs as you see them, this will help us toclarify more use cases and see what can be supported or not (yet). There are a list of this missing, failings or simply testing parts that I can check and report on bugzilla? So far, it is 'test what you can, please report issues in bugzilla'. For now, the only problem I know on my little network is the w2w now solved. In my test environment also the update f-31->f-32rawhide, aka samba 4.11.6 -> samba-4.12rc2 it worked well without problem. Good to hear! -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
Il giorno mar, 11/02/2020 alle 21.35 +0200, Alexander Bokovoy ha scritto: > There are few more missing parts here and there that need to > beimplemented. They might affect some use cases and not others. At > thispoint, I'd suggest to open bugs as you see them, this will help > us toclarify more use cases and see what can be supported or not > (yet). There are a list of this missing, failings or simply testing parts that I can check and report on bugzilla? For now, the only problem I know on my little network is the w2w now solved. In my test environment also the update f-31->f-32rawhide, aka samba 4.11.6 -> samba-4.12rc2 it worked well without problem. Let me know and I will try to verify. Many thanks -- Dario Lesca (inviato dal mio Linux Fedora 31 Workstation) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On ti, 11 helmi 2020, Dario Lesca wrote: Il giorno lun, 04/11/2019 alle 08.38 -0500, Neal Gompa ha scritto: The problem with the Samba team's advice is that it essentiallyprevents the MIT Kerberos AD-DC implementation from getting anybetter. Without people using it, we can't know what needs to be fixed.The Red Hat FreeIPA team has been working on making this functionalitywork well with MIT Kerberos for nearly a decade. The main reason it'snot in RHEL/CentOS 8 is because the functionality is too new for themto turn it on. Also, declaring that it is experimental is meaningless. What definesit as experimental? Is there any particular known massive breakage?We're not going to ship Heimdal Kerberos because the two Kerberosimplementations are incompatible and supporting both would be amassive nightmare. At this point, the only way Samba Team will stop calling itexperimental is when lots of folks are using it. That's why Fedoraships with it enabled. We have the opportunity to help make thatbetter upstream. After last MIT Kerberos update, another big problem with samba is gone https://bugzilla.redhat.com/show_bug.cgi?id=1748860#c44 Perhaps the time has come to remove "experimental" from the use of samba + MIT Or there are yet some other serious reasons not to do it? There are few more missing parts here and there that need to be implemented. They might affect some use cases and not others. At this point, I'd suggest to open bugs as you see them, this will help us to clarify more use cases and see what can be supported or not (yet). Thank you very much for your patience and willingness to help improving both Samba and MIT Kerberos. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
Il giorno lun, 04/11/2019 alle 08.38 -0500, Neal Gompa ha scritto: > The problem with the Samba team's advice is that it > essentiallyprevents the MIT Kerberos AD-DC implementation from > getting anybetter. Without people using it, we can't know what needs > to be fixed.The Red Hat FreeIPA team has been working on making this > functionalitywork well with MIT Kerberos for nearly a decade. The > main reason it'snot in RHEL/CentOS 8 is because the functionality is > too new for themto turn it on. > Also, declaring that it is experimental is meaningless. What > definesit as experimental? Is there any particular known massive > breakage?We're not going to ship Heimdal Kerberos because the two > Kerberosimplementations are incompatible and supporting both would be > amassive nightmare. > At this point, the only way Samba Team will stop calling > itexperimental is when lots of folks are using it. That's why > Fedoraships with it enabled. We have the opportunity to help make > thatbetter upstream. After last MIT Kerberos update, another big problem with samba is gone https://bugzilla.redhat.com/show_bug.cgi?id=1748860#c44 Perhaps the time has come to remove "experimental" from the use of samba + MIT Or there are yet some other serious reasons not to do it? Thanks -- Dario Lesca (inviato dal mio Linux Fedora 31 Workstation) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
Il giorno gio, 07/11/2019 alle 10.27 +, Sérgio Basto ha scritto:
> I can help you here as I'm a Fedora packager maintainer .
>
> Have you Pull request and BugZilla reports with that information
Nico, have you filled the BugZilla Request suggested by Sérgio?
For rebuild last samba package with your samba.spec file I have must:
a) download (like you suggest) samba.tar.gz from original samba site:
wget https://download.samba.org/pub/samba/samba-4.11.2.tar.gz -O
rpmbuild/SOURCES/samba-4.11.2.tar.gz
b) do this patch
[lesca@addc-build ~]$ diff -Naur samba-kadel.spec rpmbuild/SPECS/samba.spec
--- samba-kadel.spec2019-11-06 18:27:37.981827244 +0100
+++ rpmbuild/SPECS/samba.spec 2019-11-07 14:11:03.504669234 +0100
@@ -1416,7 +1416,9 @@
%{_libdir}/samba/libcmdline-contexts-samba4.so
%{_libdir}/samba/libcmdline-credentials-samba4.so
%{_libdir}/samba/libcommon-auth-samba4.so
+%if %with_clustering_support
%{_libdir}/samba/libctdb-event-client-samba4.so
+%endif
%{_libdir}/samba/libdbwrap-samba4.so
%{_libdir}/samba/libdcerpc-samba-samba4.so
%{_libdir}/samba/libevents-samba4.so
Let us know
Thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Mon, 2019-11-04 at 20:45 -0500, Nico Kadel-Garcia wrote: > On Mon, Nov 4, 2019 at 8:39 AM Neal Gompa wrote: > > > The problem with the Samba team's advice is that it essentially > > prevents the MIT Kerberos AD-DC implementation from getting any > > better. Without people using it, we can't know what needs to be fixed. > > The Red Hat FreeIPA team has been working on making this functionality > > work well with MIT Kerberos for nearly a decade. The main reason it's > > not in RHEL/CentOS 8 is because the functionality is too new for them > > to turn it on. > > I've been using Samba effectively for multi-platform integration and > account manage since 1996. This is not quite before Red Hat existed, > but it's close. d. I have never found FreeIPA to be useful in a > personal or professional environment. It relies on Samba for > integration with AD. Without robust integration with AD, I have no use > for FreeIPA. And I don't know *anyone* who uses a FreeIPA server. > > Perhaps it's time to drop FreeIPA? Perhaps it's time to learn to behave. > > Also, declaring that it is experimental is meaningless. What defines > > it as experimental? Is there any particular known massive breakage? > > We're not going to ship Heimdal Kerberos because the two Kerberos > > implementations are incompatible and supporting both would be a > > massive nightmare. > > That aounsa like a question for the Samba lists. I'm active over > there. Want me to double check the status? > > > At this point, the only way Samba Team will stop calling it > > experimental is when lots of folks are using it. That's why Fedora > > ships with it enabled. We have the opportunity to help make that > > better upstream. > > I think they're confused by the fact that Fedora and Red Hat, for > *years*, shipped with a "samba-dc" suite of packages that didn't > actually contain any software. The samba-dc packages basically said > "go away you silly English knighits or I shall taunt you a second > time". Samba-dc packages shouldnever have been published this way: it > would have been saner and safer to set a "Conflicts: samba-dc*" with > the primary samba package if these features were not enabled, rather > than publishing empty and useless packages. This is, in fact, what I > do with my published backports of Samba to RHEL with the dc enabled > with Heimdal.. I've been having some adventures with building those > lately due to modularity and the activation of zstd for RPM and the > instability of Fedora 31 in virtualized environments, but I received > workarounds from mock developers for that a few days ago. > > If people want to play with packages with the Heimdal libraries > enabled, I publish my RPM building repos over at > https://github.com/nkadel/samba4repo/. It's dependent on other > compatibility libraries due to gnutls requirements and some missing > libraries in RHEL 8, but I've had good seccess with it on various > tests with Fedora 30. Fedora 31. has so far proven impossible for > me to keep alive in a virtualization environment long enough to > actually test. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Wed, 2019-11-06 at 23:28 -0500, Nico Kadel-Garcia wrote: > On Wed, Nov 6, 2019 at 1:00 PM Dario Lesca > wrote: > > Il giorno mer, 06/11/2019 alle 09.03 -0500, Nico Kadel-Garcia ha > > scritto: > > > > Can the Fedora samba maintainers do that? > > > > > > > > Thank > > > > > > > > > > They are very welcome to my work. > > > > > > > Then why do not use your samba.spec for build official samba > > package at > > least on Fedora? > > Because the last 3 times I tried to start submitting packages > directly > to Fedora I found the process very burdensome and frustrating, and > got > no meaningful help when I asked. I can help you here as I'm a Fedora packager maintainer . > Also, it seemed clear that actually > building Samba with Heimdal Kerberos was unwelcome to Fedora or Red > Hat. And the last time I spoke with any of the authors of Kerberos > about the mess, it took them a while to stop laughing about the mess. > And yes, I know a bunch of the original authors socially, though not > professionally. Have you Pull request and BugZilla reports with that information > > It already contain the MIT or Heimdal Kerberos flag: > > > > %global with_system_mit_krb5 0 > > > > Is sufficient set it to '1' for default packaging and who wants to > > use > > heimdal can rebuild it setting this flag to '0' via line command > > > > This is another way to resolve this issue > > > > Thanks > > Well, yes. That's why I publish the suite. I was under the strong > impression that it wouldn't be welcome due to the announced desire > "not to support another Kerberos" in Fedora or for Red Hat as a > company. But since it works, works well, and Samba supports it, I'll > continue to publish the updates for a while. I admit that my > packaging > relies extensively on Rawhide for updates, and I do resync > occasionally for maximum compatibility. > > If anyone can resolve the Kerberos discrepancies and get full domain > controller working well for Samba with MIT Kerberos, I'll be happy to > congratulate them and buy them beer or maybe even dinner. That is the (only) way > I''m in the > Boston area, and hey, maybe I even know them. I admit that I > anticipate that, with the recent purchase by IBM, that FreeIPA will > be > dropped as a non-viable project, which would allow a a switch to > Heimdal based Kerberos with a future Fedora release. Since FreeIPa's > creation in 2007, I've not seen a single case where Samba, especially > Samba in collaboration with Active Directory, wasn't a better choice. > > But I could be wrong. I've only been publishing Samba ports and > working with it professionally since. 1993? In networks up of to > 13,000 servers? So what do I know? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On ke, 06 marras 2019, Scott Schmit wrote: On Mon, Nov 04, 2019 at 03:14:34PM +0100, Dario Lesca wrote: Il giorno lun, 04/11/2019 alle 08.38 -0500, Neal Gompa ha scritto: > What defines it as experimental? https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Kerberos_KDC > Using MIT Kerberos is still considered experimental. I'd say you've buried the lede, as the rest at the link is much worse: Samba 4.7 and later versions have shipped with code to support building the Samba AD DC using MIT Kerberos. Since the time of the release a number of issues, *including security issues*, have been found by real-world use. However sadly the Samba Team has not been able to resource the resolution of these issues to a standard that we are happy with, and so Samba 4.9.3, 4.8.7 and 4.7.12 releases mark this mode more clearly as experimental. As an experimental feature, *we will not be issuing security patches* for this feature, including for: * S4U2Self crash with MIT KDC build [emphasis mine] (That said, the linked-to crasher was fixed about 3.5 months after the report. I have no idea how that compares to typical response times.) I find that text worrying. Of course, all software has the potential for vulnerabilities, and some software is better quality than other software in general. Still, it's not hard to imagine people relying on the security features in higher risk environments than they might otherwise because "of course Fedora is using high quality security code" and/or "it's Samba/MIT Kerberos, of course it's high quality" ... and then it isn't. From the wording above, it seems that Samba is no longer as confident as they used to be that their MIT Kerberos integration is solid (i.e., they weren't always calling it experimental), so they've (now) made the risks explicit in their documentation. Fedora doesn't appear to be passing that information along (yet). 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: - Local privilege escalation on Windows: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0734 - Unconstrained Kerberos S4U2Self delegation in Heimdal and Samba AD: https://www.samba.org/samba/security/CVE-2018-16860.html - Samba AD DC S4U2Self Crash in MIT Kerberos https://www.samba.org/samba/security/CVE-2018-16853.html - Reachable assertion in MIT Kerberos S4U2Self implementation before version 1.17 https://access.redhat.com/security/cve/cve-2018-20217 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. That's an easy thing to overlook -- I'm willing to assume that the Samba project didn't send out an all points bulletin to all the distros warning about it, but does it make sense to reconsider the default? Maybe not, for all the reasons already stated. In that case, I'd say the ethical thing would be to do *something* to make sure that users are participating in the experiment with full knowledge of the risks. I believe users have this information already since Fedora 29 release: https://docs.fedoraproject.org/en-US/fedora/f29/release-notes/sysadmin/File_Servers/#_samba_ad_dc -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On ke, 06 marras 2019, Nico Kadel-Garcia wrote: On Wed, Nov 6, 2019 at 1:00 PM Dario Lesca wrote: Il giorno mer, 06/11/2019 alle 09.03 -0500, Nico Kadel-Garcia ha scritto: > > Can the Fedora samba maintainers do that? > > > > Thank > > > > They are very welcome to my work. > Then why do not use your samba.spec for build official samba package at least on Fedora? Because the last 3 times I tried to start submitting packages directly to Fedora I found the process very burdensome and frustrating, and got no meaningful help when I asked. Also, it seemed clear that actually building Samba with Heimdal Kerberos was unwelcome to Fedora or Red Hat. And the last time I spoke with any of the authors of Kerberos about the mess, it took them a while to stop laughing about the mess. And yes, I know a bunch of the original authors socially, though not professionally. Nico, I appreciate your passion about the software in question. However, the problems you are keeping to ignore are very real and cause real problems on a distribution scale. I cannot say anything about your communication with Heimdal authors, but suspect there is clear misunderstanding of the problem domain. Loading two different implementations of the same API in the same address space is not going to provide a reliable and stable execution environment. I don't believe Heimdal authors don't know this. It already contain the MIT or Heimdal Kerberos flag: %global with_system_mit_krb5 0 Is sufficient set it to '1' for default packaging and who wants to use heimdal can rebuild it setting this flag to '0' via line command This is another way to resolve this issue Thanks Well, yes. That's why I publish the suite. I was under the strong impression that it wouldn't be welcome due to the announced desire "not to support another Kerberos" in Fedora or for Red Hat as a company. But since it works, works well, and Samba supports it, I'll continue to publish the updates for a while. I admit that my packaging relies extensively on Rawhide for updates, and I do resync occasionally for maximum compatibility. Fedora project infrastructure provides you enough possibilities to build your packages. Please use COPR to provide rebuilt packages the way you want. This is the most simple way to serve your users within Fedora infrastructure -- it doesn't require complaining that a distribution policy is contrary to your expectations. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Mon, Nov 04, 2019 at 03:14:34PM +0100, Dario Lesca wrote: > Il giorno lun, 04/11/2019 alle 08.38 -0500, Neal Gompa ha scritto: > > What defines it as experimental? > > https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Kerberos_KDC > > Using MIT Kerberos is still considered experimental. I'd say you've buried the lede, as the rest at the link is much worse: > Samba 4.7 and later versions have shipped with code to support > building the Samba AD DC using MIT Kerberos. Since the time of the > release a number of issues, *including security issues*, have been > found by real-world use. However sadly the Samba Team has not been > able to resource the resolution of these issues to a standard that we > are happy with, and so Samba 4.9.3, 4.8.7 and 4.7.12 releases mark > this mode more clearly as experimental. > > As an experimental feature, *we will not be issuing security patches* > for this feature, including for: > * S4U2Self crash with MIT KDC build [emphasis mine] (That said, the linked-to crasher was fixed about 3.5 months after the report. I have no idea how that compares to typical response times.) I find that text worrying. Of course, all software has the potential for vulnerabilities, and some software is better quality than other software in general. Still, it's not hard to imagine people relying on the security features in higher risk environments than they might otherwise because "of course Fedora is using high quality security code" and/or "it's Samba/MIT Kerberos, of course it's high quality" ... and then it isn't. From the wording above, it seems that Samba is no longer as confident as they used to be that their MIT Kerberos integration is solid (i.e., they weren't always calling it experimental), so they've (now) made the risks explicit in their documentation. Fedora doesn't appear to be passing that information along (yet). That's an easy thing to overlook -- I'm willing to assume that the Samba project didn't send out an all points bulletin to all the distros warning about it, but does it make sense to reconsider the default? Maybe not, for all the reasons already stated. In that case, I'd say the ethical thing would be to do *something* to make sure that users are participating in the experiment with full knowledge of the risks. (As a point of comparison, we've deferred to the btrfs upstream recommendation not to install Fedora on btrfs by default. How is this different?) smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Wed, Nov 6, 2019 at 1:00 PM Dario Lesca wrote: > > Il giorno mer, 06/11/2019 alle 09.03 -0500, Nico Kadel-Garcia ha > scritto: > > > Can the Fedora samba maintainers do that? > > > > > > Thank > > > > > > > They are very welcome to my work. > > > > Then why do not use your samba.spec for build official samba package at > least on Fedora? Because the last 3 times I tried to start submitting packages directly to Fedora I found the process very burdensome and frustrating, and got no meaningful help when I asked. Also, it seemed clear that actually building Samba with Heimdal Kerberos was unwelcome to Fedora or Red Hat. And the last time I spoke with any of the authors of Kerberos about the mess, it took them a while to stop laughing about the mess. And yes, I know a bunch of the original authors socially, though not professionally. > It already contain the MIT or Heimdal Kerberos flag: > > %global with_system_mit_krb5 0 > > Is sufficient set it to '1' for default packaging and who wants to use > heimdal can rebuild it setting this flag to '0' via line command > > This is another way to resolve this issue > > Thanks Well, yes. That's why I publish the suite. I was under the strong impression that it wouldn't be welcome due to the announced desire "not to support another Kerberos" in Fedora or for Red Hat as a company. But since it works, works well, and Samba supports it, I'll continue to publish the updates for a while. I admit that my packaging relies extensively on Rawhide for updates, and I do resync occasionally for maximum compatibility. If anyone can resolve the Kerberos discrepancies and get full domain controller working well for Samba with MIT Kerberos, I'll be happy to congratulate them and buy them beer or maybe even dinner. I''m in the Boston area, and hey, maybe I even know them. I admit that I anticipate that, with the recent purchase by IBM, that FreeIPA will be dropped as a non-viable project, which would allow a a switch to Heimdal based Kerberos with a future Fedora release. Since FreeIPa's creation in 2007, I've not seen a single case where Samba, especially Samba in collaboration with Active Directory, wasn't a better choice. But I could be wrong. I've only been publishing Samba ports and working with it professionally since. 1993? In networks up of to 13,000 servers? So what do I know? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
Il giorno mer, 06/11/2019 alle 09.03 -0500, Nico Kadel-Garcia ha scritto: > > Can the Fedora samba maintainers do that? > > > > Thank > > > > They are very welcome to my work. > Then why do not use your samba.spec for build official samba package at least on Fedora? It already contain the MIT or Heimdal Kerberos flag: %global with_system_mit_krb5 0 Is sufficient set it to '1' for default packaging and who wants to use heimdal can rebuild it setting this flag to '0' via line command This is another way to resolve this issue Thanks -- Dario Lesca (inviato dal mio Linux Fedora 31 Workstation) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
> Waiting for MIT kerberos to become stable and supported from samba > team, a simple solution is insert into official samba.spec, a flag for > easily rebuild it with heimdal kerberos, without substitute or modify > the .spec file. > > Something like this: > > $ rpmbuild --rebuild --with heimdal samba-.src.rpm I set up just such a flag in my public git repo, with_ststem_mit_krb5. > > Can the Fedora samba maintainers do that? > > Thank > They are very welcome to my work. I do make some other changes in my .spec files which may not be as welcome, such as splitting up contracts that obscure pretty formatting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
Il giorno mer, 06/11/2019 alle 08.52 +0100, Franta Hanzlík ha scritto: > If I can speak for myself and for the Linux people I know, nobody > needs a FreeIPA, and many need a Samba AD DC. And of course they want > a stable solution if possible. > > The current situation leads to either choosing a different > distribution > (the simplest solution), or compiling a Samba with Heimdal Kerberos > themselves; perhaps someone chooses a commercial solution also (which > is of course with Heimdal Kerberos). > > I am not saying that the FreeIPA is useless or has no users, but in > my > opinion the chosen attitude to the Samba AD DC was perhaps the worst > possible and IMO at least frustrated a lot of users (including me). > > For me, thanks to Nico Kadel-Garcia, for his work to make stable as > possible Samba AD DC in Fedora/Centos. Thank Franta, this is exactly also my opinion, and me too thank to Kadel-Garcia for his work. Waiting for MIT kerberos to become stable and supported from samba team, a simple solution is insert into official samba.spec, a flag for easily rebuild it with heimdal kerberos, without substitute or modify the .spec file. Something like this: $ rpmbuild --rebuild --with heimdal samba-.src.rpm Can the Fedora samba maintainers do that? Thank -- Dario Lesca (inviato dal mio Linux Fedora 31 Workstation) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Mon, 4 Nov 2019 20:56:13 -0600 Chris Adams wrote: > Once upon a time, Nico Kadel-Garcia said: > > Without robust integration with AD, I have no use > > for FreeIPA. And I don't know *anyone* who uses a FreeIPA server. > > > > Perhaps it's time to drop FreeIPA? > > Nope. You are assuming the everybody needs AD... lots of people have no > use for AD and just want a good IdM. > > Never assume your use case is the only use case. If I can speak for myself and for the Linux people I know, nobody needs a FreeIPA, and many need a Samba AD DC. And of course they want a stable solution if possible. The current situation leads to either choosing a different distribution (the simplest solution), or compiling a Samba with Heimdal Kerberos themselves; perhaps someone chooses a commercial solution also (which is of course with Heimdal Kerberos). I am not saying that the FreeIPA is useless or has no users, but in my opinion the chosen attitude to the Samba AD DC was perhaps the worst possible and IMO at least frustrated a lot of users (including me). For me, thanks to Nico Kadel-Garcia, for his work to make stable as possible Samba AD DC in Fedora/Centos. Regards, Franta Hanzlik -- I hope the Fedora will have a better init and no binary logs ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
Once upon a time, Nico Kadel-Garcia said: > Without robust integration with AD, I have no use > for FreeIPA. And I don't know *anyone* who uses a FreeIPA server. > > Perhaps it's time to drop FreeIPA? Nope. You are assuming the everybody needs AD... lots of people have no use for AD and just want a good IdM. Never assume your use case is the only use case. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Mon, Nov 4, 2019 at 8:46 PM Nico Kadel-Garcia wrote: > > On Mon, Nov 4, 2019 at 8:39 AM Neal Gompa wrote: > > > The problem with the Samba team's advice is that it essentially > > prevents the MIT Kerberos AD-DC implementation from getting any > > better. Without people using it, we can't know what needs to be fixed. > > The Red Hat FreeIPA team has been working on making this functionality > > work well with MIT Kerberos for nearly a decade. The main reason it's > > not in RHEL/CentOS 8 is because the functionality is too new for them > > to turn it on. > > I've been using Samba effectively for multi-platform integration and > account manage since 1996. This is not quite before Red Hat existed, > but it's close. d. I have never found FreeIPA to be useful in a > personal or professional environment. It relies on Samba for > integration with AD. Without robust integration with AD, I have no use > for FreeIPA. And I don't know *anyone* who uses a FreeIPA server. > > Perhaps it's time to drop FreeIPA? > Hello! FreeIPA user here. FreeIPA is one of the most popular reasons people run Fedora Server. The openSUSE Project's internal identity management system is FreeIPA on Fedora Server (there have been issues with porting it to openSUSE...). There are many other FreeIPA users, as well as downstream Red Hat IdM users. > > Also, declaring that it is experimental is meaningless. What defines > > it as experimental? Is there any particular known massive breakage? > > We're not going to ship Heimdal Kerberos because the two Kerberos > > implementations are incompatible and supporting both would be a > > massive nightmare. > > That aounsa like a question for the Samba lists. I'm active over > there. Want me to double check the status? > No need. Alexander Bokovoy has already answered that question upthread. > > At this point, the only way Samba Team will stop calling it > > experimental is when lots of folks are using it. That's why Fedora > > ships with it enabled. We have the opportunity to help make that > > better upstream. > > I think they're confused by the fact that Fedora and Red Hat, for > *years*, shipped with a "samba-dc" suite of packages that didn't > actually contain any software. The samba-dc packages basically said > "go away you silly English knighits or I shall taunt you a second > time". Samba-dc packages shouldnever have been published this way: it > would have been saner and safer to set a "Conflicts: samba-dc*" with > the primary samba package if these features were not enabled, rather > than publishing empty and useless packages. This is, in fact, what I > do with my published backports of Samba to RHEL with the dc enabled > with Heimdal.. I've been having some adventures with building those > lately due to modularity and the activation of zstd for RPM and the > instability of Fedora 31 in virtualized environments, but I received > workarounds from mock developers for that a few days ago. > I'm fully aware of how the Samba packaging is structured. I know exactly when the samba-dc packages stopped being empty, and I've been playing with samba AD-DC since it was activated in Fedora properly. That does not change the fact that the functionality is new and still needs time to bake. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Mon, 2019-11-04 at 20:45 -0500, Nico Kadel-Garcia wrote: > On Mon, Nov 4, 2019 at 8:39 AM Neal Gompa wrote: > > > The problem with the Samba team's advice is that it essentially > > prevents the MIT Kerberos AD-DC implementation from getting any > > better. Without people using it, we can't know what needs to be fixed. > > The Red Hat FreeIPA team has been working on making this functionality > > work well with MIT Kerberos for nearly a decade. The main reason it's > > not in RHEL/CentOS 8 is because the functionality is too new for them > > to turn it on. > > I've been using Samba effectively for multi-platform integration and > account manage since 1996. This is not quite before Red Hat existed, > but it's close. d. I have never found FreeIPA to be useful in a > personal or professional environment. It relies on Samba for > integration with AD. Without robust integration with AD, I have no use > for FreeIPA. And I don't know *anyone* who uses a FreeIPA server. Hi, I'm Adam, nice to meet you! Now you do. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Mon, Nov 4, 2019 at 8:39 AM Neal Gompa wrote: > The problem with the Samba team's advice is that it essentially > prevents the MIT Kerberos AD-DC implementation from getting any > better. Without people using it, we can't know what needs to be fixed. > The Red Hat FreeIPA team has been working on making this functionality > work well with MIT Kerberos for nearly a decade. The main reason it's > not in RHEL/CentOS 8 is because the functionality is too new for them > to turn it on. I've been using Samba effectively for multi-platform integration and account manage since 1996. This is not quite before Red Hat existed, but it's close. d. I have never found FreeIPA to be useful in a personal or professional environment. It relies on Samba for integration with AD. Without robust integration with AD, I have no use for FreeIPA. And I don't know *anyone* who uses a FreeIPA server. Perhaps it's time to drop FreeIPA? > Also, declaring that it is experimental is meaningless. What defines > it as experimental? Is there any particular known massive breakage? > We're not going to ship Heimdal Kerberos because the two Kerberos > implementations are incompatible and supporting both would be a > massive nightmare. That aounsa like a question for the Samba lists. I'm active over there. Want me to double check the status? > At this point, the only way Samba Team will stop calling it > experimental is when lots of folks are using it. That's why Fedora > ships with it enabled. We have the opportunity to help make that > better upstream. I think they're confused by the fact that Fedora and Red Hat, for *years*, shipped with a "samba-dc" suite of packages that didn't actually contain any software. The samba-dc packages basically said "go away you silly English knighits or I shall taunt you a second time". Samba-dc packages shouldnever have been published this way: it would have been saner and safer to set a "Conflicts: samba-dc*" with the primary samba package if these features were not enabled, rather than publishing empty and useless packages. This is, in fact, what I do with my published backports of Samba to RHEL with the dc enabled with Heimdal.. I've been having some adventures with building those lately due to modularity and the activation of zstd for RPM and the instability of Fedora 31 in virtualized environments, but I received workarounds from mock developers for that a few days ago. If people want to play with packages with the Heimdal libraries enabled, I publish my RPM building repos over at https://github.com/nkadel/samba4repo/. It's dependent on other compatibility libraries due to gnutls requirements and some missing libraries in RHEL 8, but I've had good seccess with it on various tests with Fedora 30. Fedora 31. has so far proven impossible for me to keep alive in a virtualization environment long enough to actually test. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On ma, 04 marras 2019, Dario Lesca wrote: Too many people (like also me) try to use samba-dc on fedora for deploy a production AD DC controller, without know that MIT kerberos is experimental and some useful things cannot work (es. win to win access). An recent last example: https://lists.samba.org/archive/samba/2019-November/226845.html On 01/11/2019 22:23, Vex Mage wrote: > The script is expecting dpkg however this is a Red Hat > derived distro (Fedora Server.) Where did you get the Samba packages from ? If they are the default OS packages, then you should stop using them, they use MIT kerberos and are experimental. There is many approach for resolve this issue: a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos. b) Produce a samba alternative package version (like, for example, firefox-x11) build it with Heimdal Kerberos (es samba-hk-*) c) Stop enable DC on Fedora, like RH/Centos do. d) Notify users at the end of the installation that Fedora Samba DC is experimental. e) Solve the problems that make MIT kerberos experimental and put us in a position to ask for help on the samba team. f) ... some other proposal ? What is the best approach chosen by Fedora ? As we discussed few months ago, our approach is (e). We are working already at both MIT Kerberos and Samba upstreams to solve the remaining bits that do not allow full productization of MIT backend. I can add a patch for (d) but it doesn't change the situation because a work still need to be done. The are only few people who have the knowledge to get it fixed and they are already involved in this work. And no, building a Heimdal version is not a solution for a distribution. Please look at the previous discussion for arguments. If somebody else wants to support that type of a build, there are already means within Fedora project infrastructure to be able to provide such builds. Availability is not an issue -- actual support of a build is what nobody is going to provide. I'd be glad to be mistaken but there is nobody who is willing to take that load on themselves. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
Il giorno lun, 04/11/2019 alle 08.38 -0500, Neal Gompa ha scritto: > What defines it as experimental? https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Kerberos_KDC > Using MIT Kerberos is still considered experimental. -- Dario Lesca (inviato dal mio Linux Fedora 30 Workstation) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Mon, Nov 4, 2019 at 8:33 AM Dario Lesca wrote: > > Too many people (like also me) try to use samba-dc on fedora for deploy > a production AD DC controller, without know that MIT kerberos is > experimental and some useful things cannot work (es. win to win > access). > > An recent last example: > https://lists.samba.org/archive/samba/2019-November/226845.html > > On 01/11/2019 22:23, Vex Mage wrote: > > > The script is expecting dpkg however this is a Red Hat > > > derived distro (Fedora Server.) > > > > Where did you get the Samba packages from ? > > > > If they are the default OS packages, then you should stop using > > them, they use MIT kerberos and are experimental. > > There is many approach for resolve this issue: > > a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos. > b) Produce a samba alternative package version (like, for example, > firefox-x11) build it with Heimdal Kerberos (es samba-hk-*) > c) Stop enable DC on Fedora, like RH/Centos do. > d) Notify users at the end of the installation that Fedora Samba DC is > experimental. > e) Solve the problems that make MIT kerberos experimental and put us in > a position to ask for help on the samba team. > f) ... some other proposal ? > > What is the best approach chosen by Fedora ? > The problem with the Samba team's advice is that it essentially prevents the MIT Kerberos AD-DC implementation from getting any better. Without people using it, we can't know what needs to be fixed. The Red Hat FreeIPA team has been working on making this functionality work well with MIT Kerberos for nearly a decade. The main reason it's not in RHEL/CentOS 8 is because the functionality is too new for them to turn it on. Also, declaring that it is experimental is meaningless. What defines it as experimental? Is there any particular known massive breakage? We're not going to ship Heimdal Kerberos because the two Kerberos implementations are incompatible and supporting both would be a massive nightmare. At this point, the only way Samba Team will stop calling it experimental is when lots of folks are using it. That's why Fedora ships with it enabled. We have the opportunity to help make that better upstream. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
