|
|
Andrew Bartlett wrote:
On Mon, 2005-05-23 at 14:50 -0400, Sam Hartman wrote:
I think that Samba including a KDC based either on Heimdal or MIT is a
non-starter for several OS vendors. They need to be able to treat
Samba as one Kerberos service that provides authorization, group
membership, etc. However Samba will not be the only such service.
The OS vendors also have a strong requirement to have a single
Kerberos implementation.
That said, Samba needs to have a solution for users who are not OS
vendors. Also, it seems reasonable that Samba does not want to do the
OS vendors work for them.
Indeed, I'm not going to 'do the OS vendors work for them', as I have
enough work to do getting this ship sailing at all, let along dealing
with the particular requirements of unnamed 'vendors'. But I'm also at
a bit of a loss: aside from some desire 'not to ship more than one KDC',
I'm yet to hear what they feel 'they' need (or who these vendors are).
The most fundamental principle of working in the Unix programming
environment is to create efficient single-purpose tools that play well
with other tools. The desire "not to ship more than one KDC" is not just
a petty foible, it's a key to efficiently deploying whatever limited
resources you have. Nobody wants to be wasting resources maintaining two
separate items with overlapping function.
And strange as it may seem, there will be plenty of sites out there that
want a KDC but don't want or need an SMB service. Moreover, there are
plenty of sites out there that already have a KDC that works for them.
It would be a waste of their resources to have to learn how to
use/administer yours. As Ken said, it would probably be more effort than
any sysadmin is willing to invest, to set up a cross-realm trust with
yours, when there should only be one realm in the first place. And they
may be stuck with something (like a DCE installation) where they already
have an irreplaceable KDC, and don't want to go through that heartburn
again. (Of course, a site running DCE won't play well with Samba4
anyway, since it will have its own rpc listener.)
Indeed, one should take a good hard look at DCE (and MS AD) and learn
from them, not make the same stupid mistakes over and over. It is
certainly important that your services are so well integrated that using
them is seamless. But it is also important that your services'
boundaries are so well defined that you can remove one component and
replace it with another one, at will.
It would be great if they could join in the discussion on samba-
technical. Perhaps their requirements are more easily addressed than I
fear.
I would also like to see how this compares or contrasts with a desire to
'only ship one LDAP server', where we do hit a similar issue. This is
something where we have had recent discussion.
Yes... And as LDAP is a major piece of core infrastructure, it's another
example of "I have one working already, don't make me use another one."
People thought that meta-directories would be the solution to the
directory proliferation problem, but experience has shown that they just
turn the N-directory management problem into N+1. With that said, I'm
less worried about LDAP because there are valid reasons for keeping a
security management directory isolated from a general whitepages
directory, even if that creates redundant, overlapping directory namespaces.
I honestly don't see what we (or indeed an OS vendor) gains using a
'native' KDC (whatever that means). Can you outline that in something
more concrete?
But I do by linking inside smbd (or other very close tying) we get to
control:
- Startup/shutdown
- network interfaces
- configuration
all inside Samba itself. This is perhaps the most tempting part -
knowing that the administrator cannot 'forget to start the kdc', or
'forget the magic lines in the /etc/krb5.conf'. This makes our KDC fit
quite well with the overall design of Samba4 (one smbd to rule them
all...)
Like I said, seamless operation is an admirable goal, but crossing
component boundaries and breaking abstraction layers is a mistake. The
biggest problem with asserting all the control you want here is that
Samba is not the only consumer of Kerberos service in a network. Also,
the simple reality of software complexity dictates that an integrated
KDC+SMB server will crash more frequently than separate standalone KDC
and SMB servers. It is inappropriate to deny Kerberos service to the
network due to an SMB failure.
Finally, if we ship our own KDC, we know what is on the other side of
the interface. Vendor-supplied Kerberos libraries have been a nightmare
for us over the life of Samba3, I can't imagine what dealing with
plugins for an arbitrary vendor-supplied KDC would be like.
I am not tied permanently to this direction, and good software
engineering arguments (preferably backed with patches) or unexpected
research results may certainly change my view.
Good software engineering practice dictates that when you have problems
working with someone's interface, the solution is to fix the interface,
not replace their backend with your own. I'm rather surprised that even
needs to be said, but apparently it does.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
|
|