Multiple principals in a single kerberos keytab file?

Discussion:

Srivatsan vn

2013-04-09 02:50:13 UTC

Hi
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?
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.

Do we ever put more than one principal in a single keytab file and maintain
it in an application env? If not, why there is an option to merge keytab
files? only to be used in kdc may be?
The reason why I want to maintain one keytab is, my applications rely on
Oracle OCI thick driver (sqlnet.ora) and I cant maintain multiple keytab
files and multiple sqlnet.ora,
as sqlnet.ora cannot be switched or changed in runtime.

I know I am missing something here, perhaps a flaw in my application design
using more than one service account in my application?

Please give me some directions, I dont find the right forum where I get my
queries answered. Thanks in advance.

-Srivatsan Nallazhagappan

Russ Allbery

2013-04-09 03:05:21 UTC

Permalink

Post by Srivatsan vn
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.

Post by Srivatsan vn
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/>

Srivatsan vn

2013-04-09 03:51:20 UTC

Permalink

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

Post by Russ Allbery

Yes. However, it doesn't work the way that you're hoping.

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/>

Srivatsan vn

2013-04-09 04:04:40 UTC

Permalink

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

Post by Srivatsan vn
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

Post by Russ Allbery

Yes. However, it doesn't work the way that you're hoping.

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/

Russ Allbery

2013-04-09 04:20:40 UTC

Permalink

Post by 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:-)?

The credential cache format problem is relatively easy to fix. (You can,
for example, just use a DIR cache without changing applications if the
applications link with the MIT Kerberos libraries.) The harder problem is
that Kerberos APIs have a notion of the default principal, which is
normally read from the ticket cache or otherwise specified to the
application. Since for many years it wasn't possible to have credentials
for more than one principal without maintaining separate ticket caches and
additional complexity, and since most applications assume they have a
single identity, application code generally just determines its identity
at startup and then has no mechanism for ever changing it.

There are some proposals to let a GSS-API client choose an identity based
on who it is connecting to, but I don't know if any of them have been
implemented.

--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>