[OpenAFS] Krb5 integration with AFS

[John Tang Boyland]

Ken Hornstein wrote:
] John Tang Boyland wrote:
] >Here's what's missing with krb5 integration with afs:
] >
] >(1) Built in fakekaserver
] >    that handles all kas' protocol with a remote krb5 KDC
] >    (not part of AFS)
] >        (basically a souped-up kaforwarder.)
] 
] The two major open-source Kerberos implementations (Heimdal & MIT) ship
] with a fakekaserver, so this seems sort-of redundant.  No, they don't do
] the whole protocol, but that would be difficult, since some of what kas
] does can't be mapped into what today's krb5 KDCs do, unless you want to
] extend the kas protocol ... and I don't really see people lining up to
] do that.  What we have is enough to make "klog" work and that seems to
] be sufficient.

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.  It makes sense for openafs to
supply the kaforwarder executable since it is something that ideally
is started by bos etc.  The fakeka thing is not a forwarder and it
makes sense that it comes with kerberos 5, not openafs; despite my
wording, I wasn't talking about this.

] >(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.

] >(3) executables for klog and klog.krb that work with K5
] >    (as well as with K4)
] >        (fold aklog into klog.)
] 
] Ewww ... to me, that is going backwards.

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.)

] >In particular, it should be possible to use krb5 with AFS
] >by asking the kaserver/fakeka on the AFS database server
] >machine where the krb5 server is.  Ideally this would avoid
] >the need for a krb5.conf file on every single client machine.
] 
] 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.

In fact: I think that we could get rid of CellServDB in openafs 1.4.X
altogether, if we required cells to define a service on the machine
with the DNS of the cell.  This would also avoid the problem of
someone advertising XXX.com's cell while not being in XXX.com.

This is possible because CellServDB has very little information in it:
basically just a list of DB servers for each cell.

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.
Of course, I'm not up to implementing that. :-(

] >And the archive
] >of this list indicates you need lots of hairy things in
] >the krb5.conf in order to get PAM to work.
] 
] Well, to quote Derrick Braesher, "PAM sucks".

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.

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

John Boyland