On Tuesday, 20. April 2004 19:52, Jan Harkes wrote:
> On Tue, Apr 20, 2004 at 03:33:59PM +0200, Ivan Popov wrote:
> > Hello Michael,
> >
> > > It seems as if there are still some bugs in krb5.c - as I just found
> > > out, the realm specified in the conf-files is not used - it is
> > > always determined from the hostname!
>
> The realm in venus.conf is just a hint used by clog and cpasswd (and
> au?) what the default 'Coda realm/cell' is whenever the user doesn't
> specify one. It isn't even used by venus at all, in this respect venus
> is totally realm agnostic.
Sorry, my question was not were precise - i was talking about the 
Kerberos-realm... 

In either case, it seems all not too complicated:
Let the coda-principal, allowing users to acces servers in a specified 
CODA.REALM, be coda/<CODA.REALM>. Thus a user would be able to log into a 
coda realm/cell if he had a valid kerberos TGT and coda/<CODA.REALM> existed 
in the kdc's database and in the coda-server's keytab. This, of course, means 
that you need to add each kerberos' realm's key to the keytab (e.g. 
CS.CMU.EDU und ANDREW.CMU.EDU).
You would then not even need to communicate any domain-specific information to 
the client.

If one wanted to avoid that (and instead allow cross-realm-authentication), 
the server needs to provide his kerberos-realm to the client, who in turn 
tries to get an appropriate ticket. But that makes me ask: Where would the 
server get his kerberos-realm from - accept only the default_realm or keep a 
list of acceptable realms? This would enable the above version too...

You were talking about domain-specific information - in the above case, 
calling it "domain-specific" might lead to the wrong end: kerberos-realm 
*should* match the domain-name, but this is not necessarily true! This is 
exactly the point the lead to the problems I had!

Best,
Michael