Proposal to build an alternative image (or the main one) of the AD Domain Controller with Heimdal

[robmv]

The current AD Domain Controller image use the distribution packages of Samba, those are built using the system MIT Kerberos (at least to my knowledge on Fedora). For production usage the embedded Heimdal Kerberos is recommended for AD by upstream.

I have built the Fedora RPMs without too much change with Heimdal for use on our customers. The scripts we use downloads the Fedora SRPM from koji, patch the spec file and built the RPMs on a buildah based container. Then another container install these RPM and we get a Fedora based AD domain controller image using the recommended configuration.

When running a full distribution that uses MIT Kerberos for everything, using a Heimdal Samba is problematic because there are many other processes linking to both, Samba and MIT Kerberos at the same time, so it is understandable that Fedora chooses to build with MIT Kerberos, and it is a good test for that backend. But in the case of running Samba AD exclusively as a container there isn't a conflict since the container will be running only Samba.

Having an alternate image with Heimdal, or maybe the main one until upstream can recommend using the MIT backend for AD tasks, could help a lot to many users that are currently dealing with building Samba AD locally and dealing with built conflicts and any other problem that could arise.

If there is interest in doing this I can dedicate time to merge something based on our scripts or re-implement the necessary changes to make the image a reality.

We choose Fedora because we like to be relatively cutting edge on Samba release for AD but not too aggressively, we are currently running F37 instances because it is just one release back of the latest a greatest Samba release, so I would like to have images for both supported Fedora releases.

[phlogistonjohn]

Thanks very much for the feedback. I'll try to write up a more complete reply soon! In the meantime,
CC: @obnoxxx @anoopcs9 for awareness

[gd]

Thank you from my side as well for the great input and the interesting proposal.

It is of course very true what you outline: the Samba upstream team still considers the MIT Kerberos support experimental, although recently the MIT Kerberos implementation really has recently received tremendous contributions that brought it much closer to feature parity with Heimdal Kerberos - if not even beyond that.

In Fedora on the other hand, as you point out as well, we (the Samba maintainers in Fedora) tried to push the adoption and drive the testing of the MIT backend by only building it with that backend. There are also technical reasons to support that decision of only supporting the system provided Kerberos variant: there is always a danger of symbol collisions when dealing with two sets of Kerberos libraries, e.g. openldap based client code with cyrus-sasl calling MIT Kerberos gssapi plugins AND samba with privately built Heimdal Kerberos bits.

Although I certainly can understand the interest of running a containerized Samba AD backed by a Heimdal KDC we did not want to make our work in the SINK project overly complex by building and having to maintain both variants in parallel for Fedora. Maybe just using a container based on a distro that uses Heimdal natively (Debian/ubuntu?) is a much cleaner and easier option for that purpose?

[obnoxxx]

@robmv , thanks for the feedback and idea!

@gd couldn't we change the nightly Samba RPM builds to use Heimdal instead of the disrto's MIT? The resulting nightly AD server container images would then use Heimdal. What do you think?
@phlogistonjohn ?

And I do like the idea of creating images based on Debian and/or Ubuntu. :-)

[phlogistonjohn]

I'm generally in favor of having a debian variant, last time I checked the debian builds used the Heimdal libs, but before committing to doing work we ought to double check. Until recently I think there were some issues around the up-to-dateness of debian builds but I think there's a new maintainer now.

Personally, I'm not against doing parallel sets of RPM builds - one MIT and one Heimdal - but I don't think we ought to switch from one to another. AFAIK one of the reasons Fedora ships with MIT is to help get it more mature and eventually to a point were it can be considered no longer experimental. However, I'm not the one who would be implementing these rpm build variants and in the last verbal conversation we had @anoopcs9 was not in favor of adding a parallel set of builds.

I wanted to mention this earlier but got distracted by other tasks: our build scripts have support for custom RPM repos. You can use our containerfiles and build scripts but inject your own rpms into them. This is actually how the "nightly" images get built. Pass --build-arg=INSTALL_CUSTOM_REPO=https://repos.example.com/my/fc37/samba/builds.repo to the podman/docker build command and it will download and use that named repo file automatically. (This should be documented!)

Lastly, while I am OK with adding a debian based variant I don't think we want to pull in a huge number of additional OS base image variants. At some point we have to limit what we can support with the CI/automation/team we have. This is the part where I call on anyone reading this to consider becoming a regular contributor to the project. :-)

[robmv]

It is sad that there is no desire to add a new variant, but it is understandable. I will take a look at the INSTALL_CUSTOM_REPO option, that will give users the same experience when deploying the container instead of a totally different container layout and mounts requirements like ours. I will try to build one that way and report how useful the option is.

[phlogistonjohn]

Thanks for the update. Please feel free to provide any feedback on the INSTALL_CUSTOM_REPO option!