On Sun, 2023-03-19 at 09:29 +0200, Alexander Bokovoy via samba-
technical wrote:> Hi,
>
>
> I would be against a blended build against both MIT Kerberos and
> Heimdal
> Kerberos in a distribution. It is not going to bring you anything
> good,
> support wise.
>
> Andreas and I have submitted a talk to SambaXP about MIT
> Kerberos/Heimdal Kerberos-based Samba AD DC configurations, where
> they
> stand against each other and what are perspectives. In short, both
> have
> unique features that do not exist in the other variant and both are
> close to being production-ready. We want to change the status for MIT
> Kerberos-based build from experimental to production. Effectively,
> actual decision for a version shipped in a particular distribution
> would
> need to be made by that distribution, of course.
>
> Distributions need to take into account security releases, as Rowland
> has pointed out as well. However, from my Fedora and RHEL experience,
> this is not a problem with MIT Kerberos -- certainly not more than
> with
> Heimdal. It is pretty much a coordination question and I believe we
> have
> very good coordination on that front with MIT Kerberos and
> distribution
> maintainers.
>
> If I was in Samba AD support for production deployments, I'd probably
> go with deploying DCs in a containerized image way to isolate
> completely
> from the rest of the OS. There are few images already that provide
> this
> setup: [1] was presented at SambaXP by Michael Adam and other folks
> now
> from IBM Storage, [2] is older and also active one.
>
> [1]
> https://github.com/samba-in-kubernetes/samba-container
>
> [2]
> https://github.com/instantlinux/docker-tools/tree/main/images/samba-dc
Regarding the support and stability of a Samba AD Deployment based on
MIT Kerberos, given the advances in testing over the past few years, I
have, in 2023, no major concerns. The features that are provided work
and can be expected to operate in production without concern.
The "experimental" designation is no longer correct, but it is not
clear to me what different word we should apply instead, the closest I
can come to is "unsupported".
Just as a distribution can and will ship a pre-release version of some
software, to meet that distributions overall goals, Red Hat is free to
ship the "experimental" MIT-based Samba AD DC, and provide the
security
support (in particular) for that configuration to its users. Red Hat
has the resources and ability to coordinate the release of patched
Samba and a patched MIT Kerberos simultaneously if required, for
example.
However, things are different upstream. I would suggest that, while
vendoring has well documented costs (as seen when we got stuck on 'old
Heimdal'), the choice to embed an copy of Heimdal has been a
significant advantage to upstream Samba.
As a current example, this is allowing Claims support to be added, with
the KDC-side changes (to link the device and user) recorded in
lorikeet-heimdal and proposed upstream but not required to be accepted
at the time that the patches land in Samba.
Likewise, security releases, which have been a significant burden of
late, can be made from Samba master and directly consumed by our users.
I'm very sorry I won't be at SambaXP this year, as I would very much
like to be part of the conversation around any changes we make here.
It is not that the the current situation is ideal, but it has come with
a number of significant advantages.
In both cases the development process includes tests, and these tests
are at least initially marked as knownfail for MIT Kerberos. This is
not as dire as it seems, because more then 50% of a Samba development
task is tests, those supporting the MIT KDC are presented with a full
set of tests and a list of know failures the address.
However that knownfail listing is the limit that the developers
providing new Samba AD features and providing the security support are
expected to provide.
This last point is critical, as only one of these Kerberos
implementations is funded, and currently the Kerberos distribution that
the developers involved are funded to provide is Heimdal.
This choice may of course change in the future, but as far as I see it
it will always be one or the other.
Andrew Bartlett
--
Andrew Bartlett (he/him) https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead https://catalyst.net.nz/services/samba
Catalyst.Net Ltd
Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company
Samba Development and Support: https://catalyst.net.nz/services/samba
Catalyst IT - Expert Open Source Solutions