[OpenAFS] Administrators with a slash

Benjamin Kaduk kaduk@mit.edu
Tue, 5 Mar 2019 23:16:45 -0600


On Mon, Mar 04, 2019 at 02:14:43PM +0200, Ciprian Dorin Craciun wrote:
> On Mon, Mar 4, 2019 at 3:35 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
> > > Perhaps the OpenAFS Quick Start UNIX chapters touching the Kerberos
> > > integration (http://docs.openafs.org/QuickStartUnix/HDRWQ53.html)
> > > should clearly state this issue with principals containing dots and
> > > using at the same time instances (i.e. slashes)...
> >
> > Patches welcome!  (XML sources browseable at
> > http://git.openafs.org/?p=openafs.git;a=tree;f=doc/xml/QuickStartUnix;h=9e4fbd3f23b81696d98b1fcb68519364fe365d3f;hb=HEAD
> > ; preferred submissions are as gerrit changes (docs on that at
> > https://wiki.openafs.org/devel/GitDevelopers/) but mailed patches and
> > similar are fine.
> 
> 
> I'll try to provide a patch to the documentation.
> 
> (I am aware that OpenAFS is an open-source, volunteer-based project,
> thus I was not "demanding" the update.)  :)
> 
> However on the same subject, is there a document describing how one
> should configure Kerberos (from MIT) to work flawlessly with OpenAFS?
> (I've tried searching for such a document, but found none, and
> moreover even "plain" Kerberos deployment tutorials are very
> scarce...)

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.  (MIT's is
called "Moira" and has a paper or two about it from the Project Athena
days.)

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.  (Well, other than it being a "clustered"
service where multiple locations share the keytab.)

> 
> 
> > > Moreover it's still unclear to me if in `pts createuser` I should use
> > > the `username.admin` or `username/admin` variants?  (It lets me do
> > > both, but I think only the former actually works.)  Could someone tell
> > > me the "correct" syntax for OpenAFS usernames?
> >
> > You should pts createuser the username.admin variants.
> 
> 
> I'll try to include this in that patch also.

Thanks!

> 
> 
> > 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 low-level technical spec would be at/nearby
http://afs3-stds.central.org/docs/draft-wilkinson-afs3-rxgk-11.txt which
uses the extended names from
http://afs3-stds.central.org/docs/draft-brashear-afs3-pts-extended-names-09.txt
.  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 (which itself would include the
Kerberos mechanism OID, as alluded to in Section 10.3.2 of the second
document).

But I probably was not talking about what you were actually asking about;
feel free to ask for more clarifications.

-Ben