Rick --
I use cross-cell authentication all the time. It requires that the
two cell's authentication servers (KAServer or MIT Kerberos server)
have a shared key. It also requires a special pts group entry. This
is best explained by example:
COMP.COM and SITE.ORG want to share data via AFS. To make this
complicated, SITE.ORG is using MIT Kerberos, but COMP.COM is using
Transarc's KAServer.
Each site needs to create a principal for the other site. So,
COMP.COM will create [EMAIL PROTECTED], and SITE.ORG will
create [EMAIL PROTECTED] This principal must have the same
DES key and kvno in both realms! If both sites were running MIT
Kerberos or both were running Transarc KAServer, then they could
choose a password and insert that into the database. In this case,
they will have to choose a common DES key, which means they have to
choose both a password AND a string-to-key function to use!!! This is
what makes this complicated.
Luckily KAServer has the setkey option, so the site running MIT
Kerberos can add a password, and the site running KAServer can take
that password, use the MIT string-to-key to obtain the DES key, and
then use kas setkey to set the krbtgt key to that value!
At this point, authentication is present, now you have to generate the
cross-cell group. This is done by generating a group for
system:authuser@remote-cell. So, SITE.ORG will create the pts group
system:[EMAIL PROTECTED], and COMP.COM will create
system:[EMAIL PROTECTED]
Now users at the remote sites can generate PTS IDs for themselves by
authenticating (using either aklog from MIT or cklog from CMU) to the
remote site, and possibly generating an ID for themselves.
You can control the number of remote entries by setting the value for
the numgroups on the system:authuser@site group. Setting this, for
example, to 20 will allow 20 _more_ users to generate IDs. Setting it
to 0 will allow no one else to generate an ID.
Does this explain it well enough?
-derek
