Mail.app with multiple accounts using Kerberos

John Rudd jrudd at ucsc.edu
Thu Aug 25 20:55:51 EDT 2005


Jeffrey Altman wrote:


> The reality is that in the current day you either need to use
> cross-realm or your applications have to maintain knowledge of which
> principal should be used to access the given resource.
> 
> This is a non-trivial problem.


That seems almost like an "over-engineered" type response.

What is wrong with making the application maintain that knowledge? 
Afterall, that's exactly the purpose of preferences databases and rc-files.

Using your email example:

1) Have the application record:

    a) A default principle for the application,

    b) A default principle for each mail personality (which may itself 
default to "email-userid at defalt-realm" and let the user change that 
manually), and

    c) A specific principle for each folder/resource.

2) If none of those preferences exist, ask the user which of the 
principles in their cache is the right one to use for that resource (and 
offer a "none of these" option; if they choose that, then invoke your 
kinit type program, and update your list of choices to offer when it 
returns).  And give them a checkbox for "remember this principle for 
this resource".


If they end up with a lesser degree of access to a folder because they 
didn't specify 1c, then they need to specify 1c.

For AFS, access to the local cell is presumably going to happen at a 
point where you only have 1 principle to choose from (assuming you're 
doing a kerberos PAM and then an afs PAM that leverages your kerberos 
ticket;  otherwise, it should default to username@(an explicit realm 
setting for that AFS cell) ).  Once you've got a home directory that you 
can read from, have a .afsrc file in your home directory which tells AFS 
which principle goes with which cell (or even which principle goes with 
directory within a volume within a cell).  Same thing as for email, 
really, just a slightly different implementation.


As for multiple principles in one cache: if the limitation is that 
there's only one KDC time-offset entry in the cache, then extend the 
cache format so that it can have a different time-offset for each KDC 
that it needs to deal with.  (the idea that you would need to have a 
different cache file for each principle is rather repugnant)


More information about the Kerberos mailing list