Multiple principals in a single kerberos keytab file?

[Srivatsan vn]

And just out of my curiosity, is this not a limitation on cache
credential format
to support multiple principals? if yes, any plans to address this in the
near future:-)?

Thanks,
Srivatsan


On Mon, Apr 8, 2013 at 11:51 PM, Srivatsan vn <srivatsan.vn at gmail.com>wrote:

> Hi Russ,
>             Thanks for for your response, this is helping me greatly
> pointing me in the right direction. I can see your point of using kswitch
> and KRB5CCNAME to maintain single keytab, but more than one cache
> credential file. Unfortunately, I cant make a cache file switch, because
> its one running process that's going to make multiple connections with
> different principals (yes, at the same time in a running process) and
> within a running process, oracle OCI does not allow you switch sqlnet.ora
> (contains the keytab and cache file path configuration). I thought I
> avoided the problem of switching keytab by merging them into one, but looks
> like I am back to square one as I cannot have one cache file and I will
> have to switch (which unfortunately I cant as I rely on sqlnet.ora).
>             Looks like my only option is to consider not using more than
> principal account in the application.
>
> Thanks again for you help,
> Srivatsan
>
>
> On Mon, Apr 8, 2013 at 11:05 PM, Russ Allbery <rra at stanford.edu> wrote:
>
>> Srivatsan vn <srivatsan.vn at gmail.com> writes:
>>
>> > I have a situation where I have multiple keytab files (different
>> > principal accounts) and my application is going to use these different
>> > service principal accounts and connect to one or more Oracle databases
>> > (all kerberos enabled). Can I maintain only one keytab (merging all into
>> > one)in my application environment?
>>
>> Yes.  However, it doesn't work the way that you're hoping.
>>
>> > If I merge all keytabs into one using kutil and issue kinit (or okinit)
>> > using keytab and service principal, I could see the command runs
>> > successful and see the cache credentials getting updated. But I am not
>> > sure if the single cache file is actually storing tickets for all the
>> > principals. When I issue klist (or oklist), I could only see the last
>> > issued service principal's ticket.
>>
>> You can store keys for multiple principals in one keytab file.  However,
>> you can't store multiple tickets for different principals in one ticket
>> cache file (at least with the default format).  Also, kinit only gets
>> tickets for one principal at a time.  Putting multiple identities in one
>> keytab doesn't get you credentials for all of those identities; it just
>> means that you can use that keytab to get credentials for any (one) of
>> those identities.  You have to pick.
>>
>> Does your application need tickets for multiple principals at the same
>> time?  If so, your application is going to have to be aware of one of the
>> newer ticket cache formats (such as DIR) that can do this, and will need
>> to switch between identities.  It's fairly rare for applications to
>> support this sort of thing.
>>
>> If you want to experiment with DIR caches, you can create an empty
>> directory, set KRB5CCNAME to DIR:/path/to/directory, and then run kinit
>> multiple times with different principal names.  You can then switch your
>> default identity with the kswitch command.  It's pretty neat, but it's
>> also pretty new, and most applications only use the default identity and
>> don't know that ticket caches can store multiple identities.
>>
>> --
>> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/
>> >
>>
>
>