Looking to once again re-bundle LDB

[Alexander Bokovoy]

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.

Hopefully, I'll be able to show something concrete this year's SambaXP
as well.

-- 
/ Alexander Bokovoy