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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
