7:32 a.m.
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 ?
Many thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
7:38 a.m.
On Mon, Nov 4, 2019 at 8:33 AM Dario Lesca <d.lesca(a)solinos.it> 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!
8:14 a.m.
New subject: 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)
10:39 p.m.
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?)
2:14 a.m.
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-20...
- 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/Fi...
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
7:45 p.m.
On Mon, Nov 4, 2019 at 8:39 AM Neal Gompa <ngompa13(a)gmail.com> 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.
7:51 p.m.
New subject: 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 <ngompa13(a)gmail.com>
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
8:10 p.m.
On Mon, Nov 4, 2019 at 8:46 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Mon, Nov 4, 2019 at 8:39 AM Neal Gompa <ngompa13(a)gmail.com> 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!
8:56 p.m.
Once upon a time, Nico Kadel-Garcia <nkadel(a)gmail.com> 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 <linux(a)cmadams.net>
1:52 a.m.
New subject: Please, IMHO, resolve in some way the Samba MIT kerberos
problem.
On Mon, 4 Nov 2019 20:56:13 -0600
Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Nico Kadel-Garcia <nkadel(a)gmail.com> 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
7:50 a.m.
New subject: 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-xxxx.src.rpm
Can the Fedora samba maintainers do that?
Thank
--
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
8:03 a.m.
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-xxxx.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.
noon
New subject: 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)
10:28 p.m.
On Wed, Nov 6, 2019 at 1:00 PM Dario Lesca <d.lesca(a)solinos.it> 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?
1:56 a.m.
On ke, 06 marras 2019, Nico Kadel-Garcia wrote:
On Wed, Nov 6, 2019 at 1:00 PM Dario Lesca <d.lesca(a)solinos.it>
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
4:27 a.m.
New subject: 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
<d.lesca(a)solinos.it>
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
2:53 a.m.
New subject: Please, IMHO, resolve in some way the Samba MIT kerberos
problem.
Il giorno gio, 07/11/2019 alle 10.27 +0000, 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.spec 2019-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)
7:14 a.m.
New subject: 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 <ngompa13(a)gmail.com>
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
9:44 a.m.
New subject: 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)
1:35 p.m.
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
3:16 a.m.
New subject: 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)
4:54 a.m.
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
9:49 a.m.
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
1533
days inactive
1633
days old
22 comments
10 participants
participants (10)
-
Adam Williamson -
Alexander Bokovoy -
Chris Adams -
Dario Lesca -
Franta Hanzlík -
Neal Gompa -
Nico Kadel-Garcia -
Scott Schmit -
Simo Sorce -
Sérgio Basto