mit-krb5 and heimdal binaries

Rowland Penny rpenny at samba.org
Sun Mar 19 08:51:45 UTC 2023



On 19/03/2023 08:04, ronnie sahlberg wrote:
> On Sun, 19 Mar 2023 at 17:52, Rowland Penny via samba-technical
> <samba-technical at lists.samba.org> wrote:
>>
>>
>>
>> On 19/03/2023 07:29, Alexander Bokovoy via samba-technical wrote:
>>> 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.
>>
>> I do not think this is a good idea, Samba should use one or the other,
>> not both. If you do use both, to a certain extent you will nearly double
>> the support required.
>>
>>>
>>> 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.
>>
>> That is strange, from what Andrew wrote, he appears to think the opposite.
>>
>>>
>>> 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
>>>
>>
>> I personally have no axe to grind over the matter, I do not care which
>> kdc is used, just as long as it is only one, if only from the support
>> point of view.
>> I also only say that using MIT is experimental because other wiser (at
>> least I hope they are wiser than me) people say it is, if this changes
>> then so be it.
>>
>> I still do not think it is a good idea for a distro to provide two
>> versions of Samba, one using Heimdal and the other using MIT.
> 
> Distros are always going to ship with MIT as that is the default.
> Distros might also have to ship Heimdal but that will double the
> support and maintenance cost
> of Kerberos support at distros.
> Forcing distro to ship Heimdal is not a zero-cost decision.

That isn't what I said, I said that I do not think it is a good idea for 
a distro to ship two versions of Samba.

Rowland




More information about the samba-technical mailing list