[OpenAFS] Krb5 integration with AFS

[Ken Hornstein]

>It'd be nice to have the other user-level commands, principally kpasswd, 
>to avoid the krb5.conf problem I mention below.  But maybe the
>kaforwarders already implement them.

fakeka's, you mean; there is almost nothing to the kaforwarders.  They
just pass stuff off to fakeka.

And actually, that is the _one_ bit that you wouldn't want to implement,
since you can't do server-side password quality checking with the AFS
kpasswd, nor could you get any user enctypes stronger than DES.

>] >(2) pam libraries to handle krb5/kas transparently
>] 
>] There are some PAM libraries around, like the ones that come with Debian,
>] that seems to do all of the right magic today.
>
>I thought you had to decide between kas/krb5 (at least for Solaris),
>and then there's the krb5.conf PAM horribleness that neither of us
>like.

Well, certainly the krb5 ones exist ... what's the problem with having a
choice here?

>Currently aklog is orphaned: it needs to be properly supported by
>openafs.  if openafs can support krb5 in the kernel, why not have it
>support aklog (and ditch the superfluous "a-" prefix while we're at it.)

Let me correct you here; openafs DOES NOT support krb5 in the kernel.
What's really happening is rather complex, but it's a mis-mash of V4 and
V5 compatibility.  But the client-side cache manager has no idea that
you're using krb5 when you use aklog.  The cache manager can't tell the
difference between a klog and an aklog invocation.

The naming of aklog is historical (like so much else in AFS).  I personally
don't have a problem with it, and renaming "aklog" to "klog" at this point
would introduce more confusion than any possible gain, IMO.

>] If you don't like DNS SRV records, then you're using a CellServDB file,
>] which is maintained on every client machine.  Personally, I don't
>] consider the cost of maintaining two client-side files that much
>] greater than one.  
>
>krb5.conf is much more complex than CellServDB.
>I'm a volunteer administrator and can handle copying a CellServDB
>from grand central.org since I don't need to customize it at all.
>krb5.conf has a dizzying array of options.  I really doubt there can be
>a one size fits all.

Huh?

I think I have perhaps the largest krb5.conf I've ever seen.  It's got
over 25 realms in it.  I use this in Kerberos kits that are distributed to
end-user systems that access DoD supercomputer resources at twenty different
sites across the US.  But it's not really that more complicated than
CellServDB.  Sure, the _format_ is different, but the realm information
is really the same information than the CellServDB.  That's really the
critical part; the rest of it is really unnecessary in terms of aklog.
And really, _what_ is all of this wacky krb5 information you're talking
about?  If it's just KDC location, you can put that in DNS, the same as
you can with CellServDB.  And really, I have found that while maintaining
the krb5.conf file is a pain, it's no more painful than CellServDB, and
this one file really does work for 5000 users, no matter what realm they
are using.

>I'd like to hide the krb5 mess inside the data base servers for each
>cell.  Each cell knows its own krb5 info, and clients can find out
>what they need by contacting the souped-up kaforwarder.

I feel it's only fair to point out that for some of the more esoteric
options in krb5.conf (the ones you don't normally use), those are things
that generally only the client knows.

>Well, I agree that PAM + krb5 is pretty scary currently.  But (as a
>user) I find PAM very convenient.  I like being able to use my AFS
>password for CDE login, and for telnet and for ftp and for ssh (modulo
>the PAG problem that has not been fixed to my knowledge).  It seems a
>whole lot better than the old specialized login binary.

Certainly people disagree on whether the special login binary is better
or worse than PAM.  I can only say that I use a special login binary and
a modified XDM everywhere, and I don't have any problems.  Yet I hear the
PAM people scream all of the time about getting it working.  You be the
judge about which one is better.

>Presumably a well-written kaforwarder could keep the complexity in
>one (or three) cell-specific places.

Perhaps ... but you already said that you're not up to writing it, and if
you're not going to do it, I suspect the intersection of people who want
this and people who have the time/ability is currently the null set.

--Ken