[OpenAFS] Administrators with a slash

[Benjamin Kaduk]

On Wed, Mar 06, 2019 at 03:28:10PM +0200, Ciprian Dorin Craciun wrote:
> On Wed, Mar 6, 2019 at 7:16 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
> > To a large extent, getting Kerberos set up is pretty much drop it in and
> > switch it on, but there's a lot of flexibility about principal names,
> > especially for administrative operations.  Getting it integrated with
> > OpenAFS is mostly about having the right 'pts createuser's happen to
> > register users, and creating the afs/cellname.fqdn principal to go in the
> > rxkad.keytab and/or KeyFileExt -- at this point, AFS is just a regular
> > kerberized service and doesn't require special treatment on the Kerberos
> > side for the service principals.
> 
> Indeed this was my experience also, the Kerberos deployment was quite
> trivial (once I've done it);  however in seemed (and still seems) that
> I've "lost" something along the way because I lack the proper know-how
> and expertise with Kerberos.
> 
> 
> > I don't know of specific documentation for this, no.
> > I think that many sites running Kerberos+AFS have some homegrown database
> > management system that handles both and keeps them synchronized.
> 
> And this is unfortunate, especially since deploying OpenAFS "seems" a
> daunting task for the small cell operator, or one that just wants to
> "play" with the technology.  I say "seems" because deploying an
> OpenAFS server can be done quite quickly with a couple of copy-pastes.

Indeed.

> Perhaps (if I'll have time) I will prepare a small hands-on tutorial
> on deploying OpenAFS on a Linux server.  (I know that there already
> exists the "Quick Starting UNIX Guide", however it is far from
> "quick"...)  :)

I think there's definitely room for a tutorial as well as the quick-start
guide, as some general encouragement for you.

> 
> > > > Of course, rxgk will let us use fancier names for things, so we'll have to
> > > > get used to a whole new world order when that finishes landing...
> > >
> > > Could you elaborate more on this?
> >
> > The short form is that we'll be able to use (encoded) GSS principal
> > names in the UserList file.  It looks like the details haven't made it into
> > the UserList.pod documentation yet (unsurprising, since the code to
> > authenticate as them isn't in place yet), but the format includes a base64
> > encoded version of the GSS exported name.
> 
> Basically it means one could use something alternative to Kerberos for
> authentication?  (Something that is GSS-compliant?)

It's still going to be Kerberos, but will look more like a native Kerberos
5 setup (the current thing was originally Kerberos 4 and had some Kerberos
5 tacked on as an emergency patch, basically).  In particular, it will use
non-broken crypto for the actual encryption operations for data on the
wire, and have an integrity-only scheme that would actually be useful.

-Ben