mit-krb5 and heimdal binaries

Rowland Penny rpenny at
Sun Mar 19 10:01:51 UTC 2023

On 19/03/2023 09:45, ronnie sahlberg wrote:
> On Sun, 19 Mar 2023 at 19:15, Rowland Penny via samba-technical
> <samba-technical at> wrote:
>> On 19/03/2023 09:05, Alexander Bokovoy wrote:
>>> On su, 19 maalis 2023, Rowland Penny via samba-technical wrote:
>>>> On 19/03/2023 08:07, Alexander Bokovoy wrote:
>>>>> On su, 19 maalis 2023, Rowland Penny via samba-technical 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.
>>>>> I did say exactly that: I am against blended build. Not sure what made
>>>>> you think otherwise.
>>>>>>> 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.
>>>>> I am one of developers and one of maintainers for both Samba and MIT
>>>>> Kerberos in Fedora and RHEL (as well as few other relevant projects). I
>>>>> personally see no issues with MIT Kerberos upstream collaboration.
>>>>> Things get discussed and fixed when needed, contributions get accepted.
>>>>> Our willingness to move Samba AD/MIT support from experimental forward
>>>>> to supported is based on that factor as well.
>>>>>>> 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]
>>>>>>> [2]
>>>>>> 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.
>>>>> Yep. However, tools we have in most distributions allow to provide more
>>>>> flexibility. It all needs maintainers, though. Without maintainers there
>>>>> is just an illusion that someone could depend on a package that is in
>>>>> reality not supported well -- whether it is built with a single scenario
>>>>> in mind or set up to handle multiple approaches.
>>>> Alexander, as I said, I do not have an axe to grind in this, if Samba
>>>> decides to move to MIT, then so be it. You however, do have  an axe to
>>>> grind, you work for red-hat, who are on record as saying that there will
>>>> never be an AD DC on RHEL. Are you now saying that, if Samba moves to MIT,
>>>> there will be ?
>>> I don't say that. What I said is that I am responsible for both Fedora
>>> and RHEL. Fedora does provide Samba AD DC already for several years,
>>> using MIT Kerberos backend. That's what I stand behind and will continue
>>> to support.
>> Yes, Fedora has provided an AD DC for sometime, but it could be honest
>> about it and say:
>> A) Samba has marked the use of MIT as experimental, so you shouldn't use
>> this in production (even if you think they could be)
>> B) RHEL will never provide an AD DC
> This has been a topic for well over a decade, from well before I left
> the CTDB team.
> And a decade and a half later there is still the same issue.
> If no one has cycles to work on fixing it proper. Maybe the solution
> is to fork samba into two or more related but independent projects
> that can each decide what external libraries to use?
> I mean the current situation has been ongoing for well over a decade
> and no solution in sight. Maybe more drastic and pragmatic solutions
> are called for?
>> Rowland

I personally do not care which kdc is used, but I do not think that 
Samba has the resources to support two. I also do not know why Heimdal 
was chosen over MIT, but that is how it has been since Samba 4.0.0 (at 
least) was released. If Samba is now going to use MIT instead of 
Heimdal, then it should provide what Heimdal does now and Samba should 
stop supporting Heimdal. However, Samba being Samba, it cannot stop 
supporting Heimdal, there are enough problems trying to get deprecated 
things removed now, for reasons that I can understand.

To try and support two KDC's will, in my opinion, be like trying to ride 
two horses in the same race.

You also have to understand that, again in my opinion, if Debian hadn't 
produced Samba packages that could be provisioned as an AD DC, then 
Samba probably wouldn't have gained the traction as an AD DC that it 
has. Everyone would have had to compile Samba themselves and few people 
really want to do that.


More information about the samba-technical mailing list