On Sat, 2008-06-14 at 12:54 +0300, Sergey Yanovich wrote:
> Andrew Bartlett wrote:
> > On Thu, 2008-06-12 at 11:08 +0300, Sergey Yanovich wrote:
> >> There maybe a few points to consider:
> >> 1. Samba will probably be much happier in the long run, if it manages to
> >> put 'hdb_samba4.so' (and 'win_dc' plugin as well) into Heimdal's tree,
> >> so that it is updated/patched together with the rest of their code.
> > I don't expect this to happen. The reason these are plugins to
> > Heimdal's stable API and ABI rather than the other way around is because
> > they are better maintained in Samba (they use a *lot* of Samba) and
> > because we expect to maintain them as part of Samba into the future. A
> > good packaging will of course place them in the right filesystem
> > location to be used by Heimdal.
> If plug-ins use only stable ABI, this approach is fine.
> >> 3. Using external KDC is a solution that address both 1. and 2. from
> >> above. However, the solution seems to be in a distant future. However,
> >> there is a half-way solution: internally build the external KDC with
> >> proposed Samba-related patches. This will require an /etc/init.d-style
> >> script to launch that KDC after Samba, similarly to how smbd is launched
> >> after nmbd in Samba 3.
> > I do not expect this to happen, because I don't see what benefits it
> > brings us. One of the gains in Samba4 is that we don't leave the
> > administrator the launch interdependent services, but instead provide it
> > in one deamon. Samba may be a marvel of Software Engineering, but it
> > does not follow that our users should have to see it's internal
> > construction for it to start :-)
> The question is rather "see it's internal construction to use it". See
> Samba4 is on the linux server, and is using a linux KDC, it is natural
> to manage it in linux way.
But it is a very long way from a linux server in the services in
provides, and (more importantly) the integrated way they must be
> BTW, I don't see much difference from user's point of view between
> Samba4 *being* KDC and Samba4 *starting* KDC the same way Samba3 starts
I see that as a flaw in Samba3's design (based on it's history and with
good reason at the time), not an advantage.
> Samba4 and Kerberos may be managed by people in different organizational
> units, so having this option maybe useful.
Sadly due to Microsoft's design of AD, these must be co-located. That
said, I certainly understand where you are coming from - it mirrors many
of the discussions we had when Samba4 first started, and first looked at
using or building a KDC. People who understand Kerberos are naturally
very protective of their KDCs, and their initial comments were similar.
> However, I understand, that
> resources are always limited, and the only available path is the one of
> least resistance. With that said, as I stated before, the current path
> may result in certain adoption resistance. Samba3 isn't usually the
> central part of linux domain infrastructure, it simply provides one of
> the services. Samba4 is going to alter the things here significantly,
> and was thinking about ways to soften transition/interop issues.
It is an unfortunate part of the way AD is designed, and the overlap of
services. We hope to allow Samba4 to be a consumer of an external
directory (this is the purpose of the LDAP backend project), but it will
always be a big intrusion on the rest of the infrastructure, simply
because of the protocols it must serve.
I appreciate your comments, and don't mean to just push them aside. As
you have seen, we are looking to move to a system-provided KDC (in the
form of Heimdal libkdc, which smbd will link to), but I strongly believe
that Kerberos as-is is way to hard to manage, and that of the big things
Microsoft got right with AD is that kerberos is 'just there'.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com