The challenge of trundling forward with Kerberos integration.

[g.w@hurderos.org]

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.... :-)

But there be the dungeons and dragons of semantic interpretation which
all good intellectual property issues are borne of.

Our intent, however, isn't to argue with the goals of Samba4.  We
actually support the work and believe rather fundamentally that our
identity models could play favorably with Samba.

But I think we can be realistic as a community and concede that Samba4
needs to be a complete functional clone of AD.  If not it will be
trivial for applications to be coded to differentiate between Samba4
and an AD implementation.

Tridge commented earlier in the Samba4 thread that one of the reasons
everything needed to be tightly integrated was to allow simple SOHO
type deployments of Samba4 in order to support applications which
require AD services.  The utility of Samba4 could be rather simply
defeated if the applications could be taught to differentiate what was
delivering the login and management services.

> The closely integrated KDC is not that way 'because Microsoft did it
> that way' (their KDC is different again), but for other reasons:
> 
>  - A more global design decision was taken describing how Samba4 would
> operate as a unix service (as a single binary, providing all integrated
> services)
>  - Because of the pain in doing portable dlopen() based plugins
>  - Because of the close integration between the protocols we support
> forced a common backend, and above two points clearly suggested a direct
> linking.
>  - Because it must 'just work', without the admin every knowing what
> kerberos is. =20

All valid and understandable reasons for your group choosing the
architeture that it did.  Once again to be realistic one needs to
assess globally why all this is happening.

Microsoft chooses to amalgamate functionality into an amomrphous
implementations for a variety of reasons.  In this case it may well be
due to the fact that the 'easiest' architectural approach, considering
the level of desired protocol integration, was to tightly integrate
all functionality into one glop.

An additional philosophy of Microsoft is to make all their technology
as easily deployable as possible.  Regardless of the technical merits
of doing so one of their strategic goals is to minimize the amount of
competency needed to deploy their architectures.

So from a realistic perspective Samba4's technical architecture is
being driven by AD's architectural and role choices.

> 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.

> Andrew Bartlett

Best wishes for a productive week for your project.

}-- End of excerpt from Andrew Bartlett

As always,
Dr. Greg 'GW' Wettstein
------------------------------------------------------------------------------
                         The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org