> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> 
...
>  For example,
> 
>      ka_GetAdminToken("adm", "admin", "mcc.ac.gb",
>        &keys.key[keys.nkeys - 1].key, 90000, &token, 1);
> 
> does not get a token, and does return the value 180490, which I
> presume to be an error message.  Can anyone explain this?

Probably the best place to ask about ADM is in the ADM mailing list,
which this is not.  But answering some of the AFS Kerberos issues --

180490 is an AFS error code -- there's library code "char *error_message(long);"
that you can use to expand these things out to an ascii string.  The easiest
way to find out what the message is though is to grep through the afs include
files.  In this case, afs/kautils.h defines KABADREQUEST to be 180490L.
The english message you'd get would be 'request packet in error'.

That's not a very helpful message -- but it looks like one
of the causes would be if you supplied the wrong password.
Just as a shear guess, I'd say you probably supplied the wrong
key.  Perhaps you supplied the key for "afs" instead of "adm.admin"?

> 
> Incidentally, it is not clear to me what the difference is between
> an admin token and an authentication token.
> 

In AFS Kerberos, there are 3 important sorts of tokens / what
MIT calls tickets.  You could have a ticket granting ticket
(sealed under the key of "krbtgt.<REALM>"), a ticket for AFS
(sealed under the key of "afs"), or an "admin" ticket (sealed under
the key of "AuthServer.Admin").  A ticket granting ticket
is only good for requesting additional service tickets.  In
this case, the only interesting service ticket is one for AFS.
An AFS ticket is good for file system requests, PTS commands,
and most other basic AFS services.  An admin ticket is necessary
to make requests of kerberos.  Such requests include setting one's
key -- ie; changing one's password.  Only an admin ticket
works for this, an AFS ticket won't; so this keeps anyone from walking
up to your unattended terminal and changing your password.  As a further
guarante of thise, one of the few services you can't request a ticket
for with a ticket granting ticket is an admin ticket.  That's what
the "NOTGS" bit does for the AuthServer.Admin key.

The AFS kernel extension can only remember one token
per cell; normally that's a ticket for AFS.  The AFS kerberos
library routines can maintain additional tokens, but they
only stay in memory.

With AFS, the ticket granting ticket is only necessary for getting the
key of AFS, and then is thrown away.  With MIT Kerberos, it's
in fact possible to get a service ticket for "afs" directly, in one
step; but it's usually more attractive to get a ticket for
"krbtgt.<REALM>" and put it into a ticket file, which can then be
used to request multiple additional service tickets later on
in the session.

                                -Marcus Watts
                                UM ITD RS Umich Systems Group



Reply via email to