On Monday, May 23, 2005 11:18:00 AM -0400 Ken Hornstein
My current feeling is that Samba may well ship it's own KDC (based
either on Heimdal, our own code or potentially some other codebase) for
some time into the future. To whatever extent Samba includes a
derivative of another distribution of kerberos, the aim would be to keep
the 'diff' between the two projects as small as possible, while
integrating the code for minimum administrative and engineering pain.
Just my $0.02:
I already have a hacked KDC (based on MIT) that has a number of custom
extensions that I need. Running a Samba-supplied KDC is simply a
non-starter. I know plenty of people who are in the same boat. Just
as an aside - it seems when you do Kerberos for a while, you find that
you need to do some number of changes to make it fit better at your
site, so this sort of thing just tends to crop up. This probably
isn't an issue for smaller sites, or sites that just want to run a KDC
to suppot Samba.
If you provide a chunk of code and say, "You need to integrate this",
then that's fine with me (if it's Heimdal-only, then that will be a
pain, but I can deal). I know, I could always do cross-realm ... but
trust me, I have more experience with cross-realm than most people, and
I'm not going to run a seperate realm just for Samba
"What he said". Seriously, I have strong reservations about such an
approach from three standpoints:
(1) From the point of view of a software engineer and protocol designer:
Kerberos is not part of your (or any) application; it is a core
infrastructure service which must be shared among many applications.
Good design requires a certain amount of modularity, with separate
tasks being performed by separate components communicating through
well-defined interfaces. This allows each component to be managed
separately, and ensures that they will all interoperate.
Including the KDC in Samba will likely result in the two becoming
tightly coupled. It will make it easier for smbd to violate all
sorts of abstractions and to depend on private interfaces which make
it fail to interoperate with standard KDC's. If multiple applications
had such a requirement, they would be unable to coexist in the same
environment, because while a given Kerberos realm may support many
applications, it can have only one set of KDC's.
(2) From the point of view of a Kerberos administrator:
Like Ken, I run Kerberos and other infrastructure for a site with
fairly complex requirements. Like Ken, my KDC's run modified
software with a number of local extensions (not the same ones).
My KDC's are carefully managed and tightly secured. They run on
dedicated, locked-down machines in locked cabinets in locked rooms
with video surveillance and direct-to-paper logging. Both network
and physical access to the machines is tightly controlled, and only
about 5 people have the ability to log in to them. The KDC software
is based on a distribution signed by someone personally known to me,
and most of the other code has been carefully analyzed as well.
I'll admit that most sites probably aren't quite as paranoid as we
are, and certainly most don't chat with their KDC vendor on a daily
basis. But a good number of people are that paranoid, or more, and
even those who don't have custom KDC modifications are unlikely to
want to run some application-specific KDC with unknown properties.
As for Ken, that would be a total non-starter for me, due to both
security and maintainability considerations. I'm uninterested in
incorporating into my KDC's a large pile of code which has nothing
at all to do with Kerberos and serves only as a source of potential
vulnerabilities. I'm much more likely to run (or even port, if
necessary) a small, easily-analyzed plugin which provides only those
specialized Kerberos-related functions required by the application.
(3) From the point of view of someone who's faced similar issues before:
The primary purpose of OpenAFS is to provide a scalable, cross-platform
distributed filesystem. Unfortunately, the OpenAFS distribution has
traditionally included quite a number of tools which are not related
to this purpose. Among other things it includes an FTP server, inetd,
login, an NTP server, rlogin/rsh, a software maintenance tool (package),
and yes, an authentication service.
All of these components are old, poorly maintained, and have been
obsoleted newer, better software available elsewhere. Some of them
are downright dangerous, and building them requires the use of a
special configure switch (--enable-insecure). What's worse, most of
these packages have _always_ been this way, since day one. This
stuff was in the Transarc distributions over a decade ago, and it
was obsolete and insecure back then, too.
We recently decided to remove nearly all of these independent packages
from the OpenAFS tree, and concentrate more fully on our core purpose.
Of the components I mentioned above, the only ones we haven't thrown
away are package (which probably should be) and the kaserver, which
we've kept around only because there are a few sites out there who
still depend on it. Note that anytime someone comes to us with a
question of the form "we're running the kaserver and...", the answer
is "don't do that; go get a real KDC".
We want people to run a real KDC. We've been in the business of
supporting a KDC unique to our filesystem application, and we didn't
like it one bit. Just a friendly word of advice...