mit-krb5 and heimdal binaries

[Alexander Bokovoy]

Hi,

On su, 19 maalis 2023, Michael Tokarev via samba-technical wrote:
> Hi!
> 
> I already asked a similar question before, but it keeps popping up in different
> contexts and forms, and the more I use samba myself, the more often it comes to
> me too, especially in context of using various security tokens for auth.  And the
> more I think about all this, the more sane it looks to me.
> 
> The thing is: mit-krb5 has much better user-level support than heimdal. But samba
> does not fully support mit-krb5 as an active directory domain controller.  The
> AD-DC thing is server-side.
> 
> I can think of providing two builds of samba for a distribution (eg debian/ubuntu), -
> one implementing whole ad-dc, as a complete thing, using their own set of libs,
> linked with heimdal. And a usual set of more client-side packages, with their own
> libraries, built against mit-krb5.  Or maybe some other combination also has its
> right to be, - for example, smbclient built with mit-krb5, the rest is heimdal.
> 
> An essential part of this is that the two sets (built against mit-krb5 and heimdal)
> do not share any internal libraries, each has its own libraries. This way, there's
> no "mix" of differently built samba, each build uses only its own libs, so there's
> no clash here.  They share the same smb.conf though.
> 
> So far, I've seen requests to build two versions of the server (again, with mit-krb5
> and with heimdal), - and I faced the same issues too.  This is because a regular AD
> member server is also good to have mit-krb5 support to integrate nicely into the auth
> infrastructure. While for ad-dc, it is less often used as "end-user" server.
> 
> So I can think of a separate samba-ad-dc binary package providing whole samba suite
> built against heimdal (maybe without smbclient and some other minor things), and
> samba "file server" binary package providing regular server not suitable to use as
> an ad-dc, but conflicting with samba-ad-dc, so it is not possible to install one
> together with another.
> 
> This approach also has another good side effect, to discourage usage of samba-ad-dc
> as a regular file server.
> 
> Or maybe the whole thing is moot now, and we just can provide regular samba built
> against mit-krb5 to work as a good AD-DC?  That would be the best solution IMHO.

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

-- 
/ Alexander Bokovoy