Re: Current ideas on kerberos requirements for Samba4

[Howard Chu <hyc@highlandsun.com>]

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