As I begin this email, remember that a) this was written a while ago, b)
we don't have resources to test K5 installs, and c) this code is all being
rewritten as part of the crypto/auth patches I am working on.  With that
in mind, continue reading.

> > > 2. setting up our stuff - this should become a short section in the Coda
> > > HOWTO. 
> > 
> > I've built coda with kerberos support (reasonably straightforward), and
> > kinit works nicely. However, I suspect there is something non-obvious that
> > I am missing.
> > 
> > I recall seeing something about mapping kerberos principals to users.. How
> > do I do this?? (it doesn't appear obvious from a quick inspection of
> > krbsupport.c)

The mapping occurs on the auth server in Krb5GetKeys, the function called
by RPC2 to retrieve a shared secret from the authenticator from the
client.  First, the realm is checked: if there is a localrealm, then the
realm of the authenticator must match it.  If there is not, we fail.  We
call krb5_unparse_name() to give us a string for the principal associated
with the authenticator.

Then we do the following:

        /* have the correct realm, so can move along */
        /* null terminate boring principals */
        if (cp[strlen(cp)-1] == '/')
                cp[strlen(cp)-1] = '\0';

        if ((at = strchr(cp, '@')))
                *at = '\0';

        /* should be room as it first got to us via cIdent anyway */
        cIdent->SeqLen = strlen(cp)+1;
        strcpy(cIdent->SeqBody, cp);

This code is essentially pulled code from the Krb4 code that does the
equivilent.  As a result, the logic may be wrong here.  The goal was to go
from 

principal/instance..._at_realm to

principal/instance... or
principal

Then, to return that as the identity to be authorized against the al
database that would allow us to generate a token based on a viceid.  Now,
the first string manipulation there (the remove a trailing /) is from the
K4 behavior where you would want to remove a trailing '.' for an
unqualified principal.  I don't know if this is true of K5.

> > How are the /vice/db/auth2.pw and related files set up for Krb5?

auth.pw is unecessary as it is only used to store passwords, but the
normal vice user files and group files are required to map principals to
vice ids, and for authorization stuff.

It has been a while since I worked with the kerberos code; with the
introduction of strong cryptography, a lot of the keying support has to
change throughout Coda, so I have been postponing rewriting it and
documenting it until that is ready.  For example, right now RPC2 supports
at maximum an 8-byte secret (64-bit).  Most people agree that is pathetic
and is fairly unsafe.  Similarly, the GetKeys functions in RPC2 don't have
reasonable arguments to allow the passing back of extended authentication
information.  What I'd eventually like to do is have a user-specified
mapping table to map identities in other mechanisms to Coda usernames (but
retain Coda viceids as the authorization mechanism).  For example, the
user might specify rules in a pseudo-regular expression:

KERBEROS5 $/*@krbrealm $
KERBEROS5 $@krbrealm $
KERBEROS4 $.*@krbrealm $
KERBEROS4 $@krbrealm $
CODA $ $

With rules for different authentication types.  However, this is a little
ways off, and without a better GetKeys interface, shouldn't be done yet.

Also, there are problems with the default Coda behavior of using
rcmd.hostname or host/hostname as the instance to provide Coda kerberos
support.  This is something that right now should not be done; originally
Peter and I selected this behavior for convenience to allow easy testing
of the kerberos code without additional steps, but my feeling is (in
hindsight) that this was a mistake.  Really, it should be coda.hostname or
coda/hostname with a seperate secret.  For those out there testing with
the rcmd or host instances, I advise you change to using the Coda service
instead.  This requires changing constants in the krbsupport.c file.

  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/