The challenge of trundling forward with Kerberos integration.

[Andrew Bartlett]

On Tue, 2005-06-14 at 10:10 -0500, g.w at hurderos.org wrote: 
> On Jun 12,  5:23pm, Andrew Bartlett wrote:
> } Subject: Re: The challenge of trundling forward with Kerberos integration.
> 
> Good morning to everyone, I hope the day is starting out well.
> 
> > On Sat, 2005-06-11 at 16:45 -0500, g.w at hurderos.org wrote:
> > > Good day to everyone, I hope the weekend is going well or the week is
> > > starting well depending on when you read your mail.
> > 
> > > With that said I understand the reasoning on which Tridge and company
> > > made their decision to move forward.  Our concerns with the direction
> > > of Samba4 are more in its general goal of trying to clone AD with its
> > > resultant architectural and potential IP problems.
> 
> > Just responding to this point first, because we need to be rather
> > clear on the point.  We are not trying to 'clone' AD (in particular,
> > there is no aim at duplicating the internal structure), and while a
> > goal of Samba4 is to implement management and logon protocols used
> > in AD, the server-side design is quite different.=20
> 
> Stated another way the desired goal is to produce an application which
> implements the complete functionality of another application in a
> manner which is transparent to any client wishing to interact with it.
> Including the faithful reproduction of all security authorization
> tokens (potentially proprietary) needed for the client to participate
> in controlled service delivery.
> 
> Sounds a bit like a clone to me.... :-)

Sorry to have to keep taking you to task on this, but this is *not* an
accurate description of what we do.  Our goal is to provide a network
implementation that is transparent to the client, however the means and
ways we provide that implementation are clearly different.  We do not in
any way wish to clone the MS internal design, nor their implementation.
A clone, which is originally a medial term with specific meaning implies
an identical DNA, but different external features.  We do not aim for
this at all.

If we are going to make a useful forward progress on this discussion,
then we will need to agree on this, as a clone of AD would indeed have
no useful role for your work (you would not be able to extend it).

> > In the long term, I see optional integration with other kerberos
> > projects as a viable and valuable option, but I'm keen to finish the
> > current KDC, and gain some real world experiences before I send
> > developers on wild goose chases for features we may find we actually
> > can't use.
> 
> Unfortunately there doesn't seem to be any type of ongoing discussion
> about how to properly implement extensibility architectures, at least
> for MIT Kerberos.  The primary purpose of my note was to try and
> stimulate some discussion on how that should be done.  I don't see
> such a discussion as a wild goose chase.
> 
> Hopefully such conversations will be forthcoming.  If not the Samba
> group would seem to be justified in their architectural decisions
> since there was little in the way of alternative choices available.

From Samba4's perspective, I am interested in seeing a pluggable
architecture as an optional way for specialist administrators to modify
the behaviour of their KDCs.  Be aware that we can't (due to portability
and manageability constraints) use a such plugin system by default, but
I see great value in allowing the option.

Samba has to be all over the KDC side of any such implementation, so the
plugins will indeed be large, but I hope it will allow interesting
experiments (such as alternate PKinit schemes) to be plugged into the
same KDC.  I don't know the exact interfaces we will need until I've
built the trial in Heimdal, but I'm happy to look at proposed designs
(and associated patches).

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050627/4b189b42/attachment.bin