samba - Mar 2023 - mit-krb5 and heimdal binaries

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.

Thanks,

/mjt

On 19/03/2023 06:12, 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.
> 
> Thanks,
> 
> /mjt
> 
Please do not do this, you would only confuse people and they would try 
to use the wrong package, I suggest you stick to what Debian has been 
doing for the last 10 years at least.

For reasons why, see here:
https://lists.samba.org/archive/samba/2023-February/243970.html

Rowland

On 3/19/23 2:12 AM, Michael Tokarev via samba 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.
The Samba recommendation is to not use Samba in AD DC mode as a generic 
file server, so for that reason, even on pretty small installations (1 
server) I build Samba with Heimdal to be used exclusively on a container 
and use the distribution built Samba with MIT Kerberos without AD on the 
host as a joined server for all file sharing outside a DC role.

Previously I used the apt.van-belle.nl but as those aren't available 
anymore (thanks to the author for all that time he worked on it), I am 
patching the Fedora's Samba RPM  to be build it with Heimdal to be used 
as a container image. I am using Fedora as it is the best distribution 
to get the latest Samba release posible something I like on an AD DC, 
Still using a RHEL derived distro on the host.
> 
> 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.
> 
> Thanks,
> 
> /mjt
>