TGT for principals getting destroyed automatically

[Gaurav Dasgupta]

Hi,

I have setup Kerberos in my CentOS cluster, added principals and modified
their ticket_lifetime and renew_lifetime for 1 year. From "kadmin.local", I
entered the command "getprinc <princ>" to get the setting details for the
pincipal and verified the modifications.

Doing "kinit" and the "klist" for the principal, I can see the ticket
lifetime and renewal lifetime - both are set to 365 days. Hence, TGT for
the principal should be valid till 1 year, and I need not kinit before that.

But all of a sudden, after few days, the TGT got destroyed automatically
for the principal. I confirmed it with the "klist" command. I had to do
kinit again for the principal. The principal got valid TGT near about same
time across the cluster. Only in 1 machine, it got destroyed. Again after
few days, TGT got destroyed in 2 other machines for a principal (This time
for a different principal), but in other machines they are alive.

This is a strange behaviour as I am manually not using the "kdestroy"
command. Has anyone faced a similar issue? How can I track what's going
wrong with the TGT? Which logs will tell me that when and how the TGT is
getting destroyed?

Thanks,
Gaurav

[Greg Hudson]

On 05/02/2013 06:31 AM, Gaurav Dasgupta wrote:
> But all of a sudden, after few days, the TGT got destroyed automatically
> for the principal.

It sounds like the file containing the credential cache was removed by a
/tmp cleaning job or something similar.

[Gaurav Dasgupta]

Thanks very much Greg.
Can you please tell me which configuration file needs to be edited and what
should be edited in order to change the location of credential cache for
all the principals?

Thanks,
Gaurav

[Greg Hudson]

On 05/03/2013 02:17 AM, Gaurav Dasgupta wrote:
> Can you please tell me which configuration file needs to be edited and
> what should be edited in order to change the location of credential
> cache for all the principals?

Prior to the 1.11 release, there is no config file setting for the
default credential cache. The only discovery mechanisms are the
KRB5CCNAME environment variable (which is often set by the login system,
if pam_krb5 is in use) and the hardcoded default of /tmp/krb5cc_NNNN.

In the 1.11 release, the default credential cache can be specified in
the [libdefaults] section of /etc/krb5.conf with the default_ccache_name
variable. The value is subject to parameter expansion as described here:


http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#parameter-expansion

[Russ Allbery]

Greg Hudson <ghu...@MIT.EDU> writes:

> Prior to the 1.11 release, there is no config file setting for the
> default credential cache. The only discovery mechanisms are the
> KRB5CCNAME environment variable (which is often set by the login system,
> if pam_krb5 is in use) and the hardcoded default of /tmp/krb5cc_NNNN.

> In the 1.11 release, the default credential cache can be specified in
> the [libdefaults] section of /etc/krb5.conf with the default_ccache_name
> variable. The value is subject to parameter expansion as described here:

> http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#parameter-expansion

Note that if you're using a Kerberos PAM module, you will probably need to
separately configure its cache location, since most Kerberos PAM modules
don't use the library default. The library default has been
/tmp/krb5cc_NNNN for ages, and that default cache naming doesn't allow for
a separate ticket cache per login session (which is normally the behavior
people want). Therefore, most PAM modules have their own independent
defaults.

For mine, for example:

When pam_setcred() is called to initialize a new ticket cache, the
environment variable KRB5CCNAME is set to the path to that ticket
cache. By default, the cache will be named /tmp/krb5cc_UID_RANDOM
where UID is the user's UID and RANDOM is six randomly-chosen letters.
This can be configured with the ccache and ccache_dir options.

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