Mail.app with multiple accounts using Kerberos

[David Botsch]

> 
> There are a couple of problems:
> 
> - There is something in the credential cache called the "primary principal",
>   or the "default principal".  It's the first thing printed out by klist.

I want to make sure we are clear here... I am dealing with the problem of > 1
principals in multiple realms (eg principal a in realm xyz.com and principal b
in realm abc.com) and not the same realm (eg principal a in realm xyz.com and
principal b also in realm xyz.com) -- 2 different problems.

At first glance, it would seem that given more than 1 principal w. each
principal in a separate realm, if you want to choose the default, well, there
is this "default_realm" value in the  kerberos config file. Otherwise, look at
the dns name of the server to which we want to connect.

> 
>   The Kerberos APIs need to have a client principal fed into them to
>   construct the service ticket request.  Virtually all code today gets
>   this principal from the primary principal in the credential cache.
>   While it's possible to put multiple TGTs in the credential cache today,
>   no apps will make use of them.  On some platforms you can have multiple

Does this no apps making use of the multiple TGTs have to do w. the design of
the credentials? Or just programmers making the assumption that no one would
ever want to, say, check mail in 2 different realms at the same time?


>   TGTs in seperate "sessions" and switch between them (MacOS X), but
>   when the "session" is switched, so is the primary principal.

And, interesting things happen if I, say, select the principal from a different
realm than the server to which I am trying to connect. I've seen it do things
such as take the principal and slap the wrong realm name on there and send that
to the server.

> 
> - Let's pretend this isn't a problem.  The problem then becomes ... how do
>   you decide what to do?  Do you attempt cross-realm authentication?  Do
>   you search the credential cache for a TGT in the foreign realm and use
>   that?  There is, unfortunately, no good answer ... although people are
>   exploring the options.
> 

The easy out is, what does the config file say to do?


> The sites that I've seen address this today do so by setting up cross-realm
> authentication.

Unfortunately, this has a whole slew of "do I trust the other realm?" problems
:(

> 
> --Ken
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

-- 
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
dwb7 at ccmr.cornell.edu
********************************