Looking to once again re-bundle LDB

[Rowland Penny]

On Wed, 14 Feb 2024 21:39:10 +0200
Alexander Bokovoy <ab at samba.org> wrote:

> On Срд, 14 лют 2024, Rowland Penny via samba-technical wrote:
> > On Wed, 14 Feb 2024 20:48:32 +0200
> > Alexander Bokovoy via samba-technical
> > <samba-technical at lists.samba.org> wrote:
> > 
> > > On Срд, 14 лют 2024, Michael Tokarev via samba-technical wrote:
> > > > 14.02.2024 20:21, Alexander Bokovoy via samba-technical:
> > > > > On Срд, 14 лют 2024, Michael Tokarev wrote:
> > > > > > 14.02.2024 17:46, Alexander Bokovoy wrote:
> > > > > > ..
> > > > > > > We do rebuilds of the whole stack in Fedora if bots detect
> > > > > > > samba ABI had changed. So for us it is not a problem.
> > > > > > 
> > > > > > It's easy to do with "current" Fedora release.  It's
> > > > > > entirely different question when you want to provide
> > > > > > current samba to a previous Fedora release.  And that's
> > > > > > where the problem is, - providing "backports" of current
> > > > > > samba to previous releases of distributions.
> > > > > 
> > > > > If you are building packages on top of RHEL by replacing
> > > > > existing packages there, you are responsible in fixing all
> > > > > breakage that new packages would introduce. It is maintenance
> > > > > work that one needs to consider when providing alternative
> > > > > builds, regardless of a distribution.
> > > > 
> > > > Exactly.  Ditto for debian. Even debian backports, while being
> > > > part of official debian and using debian infrastructure, needs
> > > > additional work. It is good if a new version does not introduce
> > > > incompatibilities, - this way it can be provided at less work to
> > > > previous releases.
> > > > 
> > > > ..
> > > > > > Yeah, it would be best to build samba against mit krb5, if
> > > > > > it were a supported way.
> > > > > 
> > > > > It is supported. It just provides a bit different set of
> > > > > features compared to Heimdal-enabled Samba builds. See our
> > > > > talk at SambaXP'23 for details.
> > > > 
> > > > I know it works, and it's kind of supported, with
> > > > --enable-experimental-mitkrb5-kdc or something.
> > > > 
> > > > The thing is: personally I don't have resources to support it
> > > > by my own in debian. Everything I do there, I do at my "free
> > > > from work" time, I don't know how all this AD-DC thing work.
> > > > After all, my only intention when I come here was to fix a bug
> > > > in samba form which I suffered in my work (had to restore lots
> > > > of user profiles lost due to samba data corruption), and am
> > > > still there because it was not "just flip this one bit and it
> > > > all works" thing :)  So I entirely rely on upstream samba for
> > > > almost all support work.  And there, MIT-Krb5 AD-DC is "not
> > > > supported".  Hence that's what I mean above :)
> > > 
> > > I think that statement of 'not supported' added more damage than
> > > helped. I hope we can move forward from that by acknowledging
> > > there are different use cases for Samba AD that involve
> > > configurations where one or the other Kerberos implementation is
> > > better suited. For example, not everyone needs read-only domain
> > > controllers in all environments. Or not everyone even need to use
> > > Windows (shocking, right?) as domain members. ;)
> > > 
> > > There are still issues at how to present two separate builds in a
> > > distribution but that's a different story, not an upstream
> > > problem. At some point we have to bite a bullet and move forward.
> > > 
> > 
> > Hi Alexander, I have nothing against using MIT on a Samba, in fact I
> > would welcome it, but according to this wiki page:
> > 
> > https://wiki.samba.org/index.php/Roadmap_MIT_KDC
> > 
> > These are things that Heimdal does but MIT doesn't:
> > 
> > Add auth logging support
> > Allow starting the MIT KDC with multiple worker processes
> > Define API for a libkdc in MIT Kerberos
> > Running as a Read only domain controller (RODC)
> > Support for Claims
> > 
> > Now the page was last updated on the 18 July 2023, so some of the
> > above may now work.
> 
> Audit logging is possible on MIT Kerberos side for years, it is not
> implemented fully on Samba side. libkdc is needed for RODC support but
> is unlikely to come without a serious investment from a party
> interested in it. Support for claims needs a small fix on MIT side
> and a minor effort on Samba side, it is in our plans.
> 
> Overall, it is better to define a focus for the specific use cases and
> admit they are being covered by these different implementations.
> 
> Samba AD/MIT Kerberos combination is far from being 'unsupported' and
> being 'experimental'. What was agressively enforced over mailing lists
> as an unsupported claim made more damage than helped, in my opinion.
> 
> 
> > It is my opinion that Samba has enough on its plate trying to get
> > the Heimdal version to the full 2016 functional level without
> > having to get the MIT version to the same level. 
> > 
> > If all the work is done to the MIT version and it comes up to the
> > same level as the Heimdal version, will RHEL ship a version of
> > Samba that can be provisioned as an AD DC ? (I think I know the
> > answer to that one) If this answer is no, then what is the point of
> > carrying out any work on the MIT version ?
> 
> In my opinion you are mixing completely different questions (and
> possible answers) together for no good reason. This does not help at
> all.
> 
> As an upstream contributor, I do not see a request for RHEL to ship
> (or not) Samba AD as a definitive reason to make (or not) Samba AD/MIT
> Kerberos 'supported' or 'unsupported' upstream. I am together with
> other fellow developers providing this support already: we do support
> Samba AD/MIT Kerberos in Fedora for years. As a major Linux
> distribution's package maintainer, I do have enough data to consider a
> distribution-wide context for this configuration being useful to be
> supported.
> 
> Heimdal is missing quite a few other features that make MIT Kerberos
> attractive for a distribution wide integration of Kerberos features
> in a modern world as well. Granted, most of that is not used or cannot
> currently be used directly by Windows and by extension of that might
> not be interested for Samba AD consumers willing to integrated with
> Windows systems directly. However, it does not mean Samba integration
> is not important in a pure Linux world.

As far as I understand it, the whole idea behind running Samba as an AD
DC is to be Microsoft AD compatible, so having the extra MIT
capabilities might be nice, but are not really necessary if AD cannot
use them. Can I also point out that Samba 4 was released 11 years ago
and, in all that time, MIT has been the coming thing, it still hasn't
arrived, there has to be a reason for this, could it be that people are
happy enough with Heimdal ?

I still think that Samba does not have the resources to use two
different KDCs and Heimdal seems to have the edge over MIT, if only
because it has been used for the last 11 years.

Rowland