> > 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 [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility [EMAIL PROTECTED] ******************************** ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
