multiple principals in one cache?
Abe Singer
According to kinit(1), when doing a kinit "Any existing tickets for _principal_
are overwritten." However, we've found that *all* tickets are destroyed.
So if one does a kinit for user@REALM-1, then does a kinit for user@REALM-2, the
tickets for user@REALM-1 get deleted from the cache.
We'd *like* to be able kinit multiple principals for use with services
in different realms (e.g. working realm and test realm). Is the behavior
we're seeing intentional (an the documentation is buggy) or a bug?
Russ Allbery
It's just not supported by the ticket cache format and ticket manager that
is used by default on UNIX. The Kerberos implementations generally have
some support for this in other ticket cache types, and there have been
various proposals for how to store multiple principals in FILE caches, but
as yet I don't think any of that work is complete and usable.
The hard problem isn't so much how to store the data as it is how to
choose which ticket to use. If you have tickets for multiple realms, you
have to figure out, when accessing a service, which of them to use. I
think that's handled in the non-FILE ticket cache types, by recording a
current "default" identity somewhere, but I don't think any of that has
been implemented yet for the UNIX FILE ticket cache formats.
I may have missed a development in this area, though.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Ken Hornstein
>> in different realms (e.g. working realm and test realm). Is the
>> behavior we're seeing intentional (an the documentation is buggy) or a
>> bug?
>
>choose which ticket to use. If you have tickets for multiple realms, you
>have to figure out, when accessing a service, which of them to use. I
>think that's handled in the non-FILE ticket cache types, by recording a
>current "default" identity somewhere, but I don't think any of that has
>been implemented yet for the UNIX FILE ticket cache formats.
AFAIK, the FILE ticket cache has (and always has) the concept of
the "primary principal"; this is what prints out under "Default principal"
when you do klist.
It is possible (but not with the default tools) to put two (or as many as
you want) TGTs in one credential cache; I once had to deal with a bug
report with aklog from a site which did that (but my answer was, "uh,
how the hell is that supposed to work?"). But as Russ has already
alluded, none of the programs you want to use will work correctly when
you do this; they all use the default principal as the client principal
when requesting tickets, so if your primary principal is user@REALM-1,
even if you have a ticket for user@REALM-2 the client libraries will
use user@REALM-1 and will attempt to do cross-realm.
So, what are your options? Assuming you really want to use principals in
two different realms at the same time (or really, any two arbitrary
principals), I believe that your options are, in no particular order:
- Update the tools. Modify kinit so it doesn't clear out the credential
cache when you kinit, and then either create/modify a tool to
rewrite the credential cache with a new primary principal (but
keep all of the tickets) OR change all of the client tools to let
you specify an arbitrary client/realm name.
- Play some games with credential caches. Have two simultaneous credential
caches and switch between them via changing environment variables.
- Use a Mac, which already has support for this. Although what IT does is
a little bit funky: it keeps the tickets for the different principals
around in another credential cache, so the tickets for user@REALM-1
are segregated from the tickets for user@REALM-2 (see the -A option
to klist and kswitch under MacOS X). But it works and is probably
the most reasonable option that I know, given all of the issues that
are involved with it.
Most people I know pick the second option.
--Ken
Greg Hudson
> It's just not supported by the ticket cache format and ticket manager that
> is used by default on UNIX.
The cache format is fine with it, actually, and has been basically
forever as far as I know. What gets in the way is:
* kinit insists on overwriting the cache.
* kdestroy doesn't know how to destroy only one client principal.
* The krb5 GSS mech insists that the cache's default principal matches
the client name, not just that the cache contains an appropriate ticket.
And that's about it. If someone wanted to write their own code to
manage the cache, and swap around the cache's default client principal
for the sake of the GSS mech, I don't think anything in libkrb5 would
get in the way.
You can produce a ccache with multiple client principals using ksu.
Russ Allbery
> - Play some games with credential caches. Have two simultaneous credential
> caches and switch between them via changing environment variables.
> - Use a Mac, which already has support for this. Although what IT does is
> a little bit funky: it keeps the tickets for the different principals
> around in another credential cache, so the tickets for user@REALM-1
> are segregated from the tickets for user@REALM-2 (see the -A option
> to klist and kswitch under MacOS X). But it works and is probably
> the most reasonable option that I know, given all of the issues that
> are involved with it.
> Most people I know pick the second option.
Note that these two options are essentially identical, with kswitch on
UNIX being implemented as "change your KRB5CCNAME environment variable."
The second option (the first one I quote above) is basically a buggy
version of the third option.
Ken Hornstein
>the client name, not just that the cache contains an appropriate ticket.
It's not just the GSS mech that does this, though ... every raw Kerberos
program I've ever seen does the exact same thing. Unless you allow your
program to specify the client principal, I'm not sure what else you could do.
>You can produce a ccache with multiple client principals using ksu.
Didn't know about that; good to know! Although ... huh, I'm looking
at the man page for ksu (probably the ONE Kerberos program I've never
run), and my question is: how, exactly, do you do that?
--Ken
Ken Hornstein
>UNIX being implemented as "change your KRB5CCNAME environment variable."
>The second option (the first one I quote above) is basically a buggy
>version of the third option.
Oh, sure ... I just wanted to point out that if you wanted to do no work
at all AND if you have a Mac available (and it sounded like it was just
going to be for testing), then that's an easy option.
--Ken
Greg Hudson
> >You can produce a ccache with multiple client principals using ksu.
>
> Didn't know about that; good to know! Although ... huh, I'm looking
> at the man page for ksu (probably the ONE Kerberos program I've never
> run), and my question is: how, exactly, do you do that?
I don't think it can be used as a general tool for this purpose, but it
does produce such a ccache as a side effect of its regular function.
For example, if I'm logged in with tickets as ghu...@ATHENA.MIT.EDU and
I ksu to root by entering the password for ghudson/ro...@ATHENA.MIT.EDU,
I wind up with a new ccache containing all of my old tickets (for client
principal ghudson) plus a TGT and host service ticket for client
principal ghudson/root.
Ken Hornstein
>I ksu to root by entering the password for ghudson/ro...@ATHENA.MIT.EDU,
>I wind up with a new ccache containing all of my old tickets (for client
>principal ghudson) plus a TGT and host service ticket for client
>principal ghudson/root.
Hm. Fair enough. Dumb question: why does it do that? I mean, as we've
discussed on this thread nearly all applications can't utilitize such a
ccache.
--Ken