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 <[email protected]>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 <[email protected]> wrote: > >> Srivatsan vn <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/ >> > >> > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
