Client keytab ignored when CC has expired

[Greg Hudson]

On 07/30/2014 02:34 AM, Michael Osipov wrote:
> If I understood you correctly, the API makes a difference here. By hand or by
> cient keytab. The problem is that one has sometimes no control over, even worse
> I cannot check how the credential was obtained because klist does not reveil that
> information.

I agree that klist not revealing this information is unfortunate.  I am
not sure what you mean by "one has sometimes no control over" how the
credential was obtained.  I would like to hear more about your use case,
as it doesn't sound like one I had anticipated when designing keytab
initiation.

> Why is there a difference in the first place?

Acquiring GSS credentials is complicated, with lots of potential (but
usually unspecified) inputs.
http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation#Code_changes
describes the decisions we need to make.

In the current design, the default credential cache takes precedence
over the client keytab.  To solve the refresh issue in the anticipated
use case (where a client keytab is specified and the default cache is
left to be managed by the GSS initiator), the GSS code sets an explicit
refresh timer when we obtain credentials using the client keytab.  If we
see that refresh timer in the cache configuration, we know that this
cache is a derivative of the client keytab, and not an independently
obtained cache intended to take precedence over the client keytab.

There are probably design changes which would work better for your use
case.  For instance, we could assume that the client keytab should be
used to refresh the default cache whenever it has a key for that cache's
principal, and use the refresh timer only to prevent over-frequent
refresh attempts.