I don't know how sane this might be, but you don't find out of if you
don't ask, right?

I run into lots of problems trying to use smbclient in my workplace.
They boil down to the fact that Samba's bundled Heimdal library has a
number of missing features compared to MIT Kerberos, including:

 * Support for DIR, KCM and KEYRING credential cache types. These are
   improvements upon the FILE type (all support multiple credential
   caches, as opposed to FILE; KEYRING keeps credentials off disk as
   opposed to DIR; KCM stores credentials in a daemon (UNIX socket
   access isolated by mount namespaces)).
 * Support for includdedir directives when reading configuration.
   Files in /etc/krb5.conf.d and /var/lib/sss/pubconf/krb5.include.d
   (created by freeipa-client and sssd) are ignored.
 * Support for locator plugins. In a multi-site Active Directory
   environment, this causes Kerberos clients to talk to the local site's
   KDCs. This might also apply to FreeIPA multi-location environments
   too.
 * Support for other plugin types. sssd provides localauth, authdata and
   preauth plugins. Admittedly I don't think these would be used by
   smbclient.

For a long time I figured there was nothing to be done about this--Samba
is pretty tightly wedded to Heimdal. However I recently noticed that
Fedora build Samba against krb5, and I figure it should be possible to
do this in Debian.

Since running Samba AD DC built with MIT Kerberos is still an
experimental feature, it's not a good idea to switch the whole source
package over wholesale. But I wonder if it would be possible to build
only smbcliennt with the system libkrb5, so that it can take advantage
of these features (in particular, credential cache types other than
FILE)?

On Sun, 28 Jun 2020 16:39:44 +0100 Sam Morris <sam@robots.org.uk> wrote:
...

Currently, this is not possible, because almost all binary packages built
from samba source in Debian depend on common samba-libs package, and the
dependency is strict (= exact binary version).

This is because samba-libs is a massive thing which contains everything,
all libraries needed by any other binary in samba, including all internal
libraries.

In particular, smbclient and libsmbclient both depends on samba-libs (of
the exact binary version of samba-libs).

And samba-libs package highly depends on the configuration.

In 4.16 I tried to move libraries which are only used in a single binary
package, to that package out of samba-libs. This way, for example, winbind
package got a few libs. Bit this is nothing really.

But samba-libs needs to be split further, into something like samba-common-libs,
samba-client-libs, and so on. This way, we may have some of them independent on
the kerberos implementation used - say, samba-common-libs, whicih can be used
by both heimdal-using samba server packages and mitkrb5-using smbclient.

Or alternatively, another set of samba-libs - ie, another package of samba-libs,
say, samba-libs-mitkrb5 - needs to be created.  This quickly becomes rather
ugly and unmanageable.

I think the only more or less realistic way to go is to split samba-libs into
subcomponents.  Actually, samba-common-bin and samba packages also needs to
be split further into multiple pieces.  For example, that needs to be
samba-ad-dc, samba-ad-dc-provision (for /usr/share/samba/setup/*), maybe
samba-krb5-printing, maybe python3-samba-ad-dc (from python3-samba) and
so on.  This is not a huge work really, but it needs to be done in order
to allow to mix and match things.

Besides, I implemented pkg.samba.mitkrb5 build profile for samba package,
maybe this one will help somehow. But it builds everything with mit-krb5,
including the experimental ad-dc code.

Thanks,

/mjt

The Samba Team will never support an install of Samba that is built up
of parts built with different options. 

I can only strongly advise against mix and match.

This is the only approach, a separate build profile.  If there is the
motivation, the user could be allowed to install one suite or the other
I guess.

Andrew Bartlett