Re: Current ideas on kerberos requirements for Samba4

[Ken Hornstein <kenh@cmf.nrl.navy.mil>]

>Now, I come at this whole area from rather a different direction than I
>suspect you do, because I'm not steeped in the history of Kerberos, nor
>do I run a large and complex site that uses it.  What is custom about
>your kerberos setup, and given that I realise that having multiple
>kerberos realms is the pits, what could we do to make your life easier?

In terms of our Kerberos KDC ... we have the following customizations
(these are the ones I remember off-hand):

- Support for hardware preauthentication
- Special code to disable _some_ users if they don't kinit with the right
  enctypes
- Extended logging
- A weirdo protocol to support the use of a hardware token combined with the
  local host key (we have a special version of sudo that uses that).
- Special enctype selection code (to deal with breakage from older clients,
  but I suppose we don't need that anymore).

Those are just the ones I remember right now; there are probably others.
Oh, and you _do_ support IPv6, right? :-)

Note that none of these change the core protocol (well, hardware preauth
does, but while that protocol hasn't gone through the whole IETF process
yet, let's pretend it's standardized).

I think I've got more changes to the Kerberos codebase than most people
(well, except maybe for those losers at Stanford :-) ), but I try to adhere
to some rules.  First, no changes to the core protocol.  No changes to
existing APIs (except maybe the adding of flags, if the function takes
flags).  Adding new API functions is okay, but I try to avoid it if possible.
Changes to the KDC behavior (e.g., what enctypes the KDC decides to use)
are fine.  Changes to application servers are okay, but I prefer changing
the KDC.  Changes to the clients are to be avoided unless there is no
other way to accomplish what I need to do.

I guess the best thing to do would be to explain what I (as a site) need
to add in terms of functionality to the KDC.  If I need to generate PAC
information (for example), then that's one thing.  If you have code to
get out the group membership from your LDAP server (and if it worked
with MIT Kerberos), hey, even better :-)

>My observation is that sites fit into one of the these three boxes:
>[...]

I could believe your numbers, if we're talking about _sites_.  However,
if we throw number of users in the mix, I suspect the numbers will be
different (my experience is that some larger sites want more integration
and have already figured out Kerberos already).  But, for the sake of
this discussion, let's take your numbers as correct (they're probably
not far off).

>My problem is that while I do *not* wish to exclude anybody, I need to
>care about the first two categories far more than the clued-in SysAdmin
>of a real kerberos site.  (Where I think that long-term, we can work
>something out).

Hey, I understand your pain.  I mean, I basically spent a YEAR
messing around with Kerberos before I understood it well enough to
deal with deploying it at our site (at the end of that year, I
understood it all the way from the protocol level down to the APIs,
and had probably seen every Kerberos error message under the sun).
Is it reasonable to ask your typical guy who wants to run Samba to
do that?  Hell no!

I think given your requirements, shipping a _basic_ KDC is probably
unavoidable.  I just wanted to point out that there is a number of
us who really want to use our own KDCs with Samba4, and we'd like
you to be able to deal with that at some point.  I don't think
there's a huge amount of work you have to do to make that happen
(at least, I hope not).

--Ken