Client keytab ignored when CC has expired

[Michael Osipov]

Am 2014-07-30 um 16:25 schrieb 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.

We/I have actually two use cases:

1. I am used to work over SSH with Subversion and Git over a SPNEGO 
protected proxy and/or with our HTTP served repositories, protected by 
SPNEGO too. Sometimes I do a kinit with my password but sometimes I 
simply forget that and svn reminds me although I assumed the client 
keytab should kick in. This is a mixed one. Client keytab kicks in when 
there is no credential cache or not expired.
The client keytab env var is set via .profile by default

2. We have several C and Fortran programs which need to call some REST 
services over HTTP, we therefore use libcurl with SPNEGO support. The 
automated/headless nature of those programs run under Unix account X and 
require a client keytab for the account Y from Active Directory. It 
might happen that me or someone else logs in into account X and performs 
some administrative tasks which require Kerberos, thus kinit. In that 
scenario, the client keytab is deemed to fail in some point in the future.

This case is currently assessed with version 1.12.1, that is why I have 
found this issue. client keytab env var is set before the program is 
forked from a shell script.

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

At least a hint in kinit's output for the user would be very helpful to 
determine the initiator source.

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

That sound very reasonable because the link above does not refer to an 
expired cache at all. I always assumed that keytab and 
principal+password are equivalent. You sketched approach should cover my 
usecase.


For what it's worth, I have compiled version 1.12.1 on HP-UX 11.31 
(which has only a stoneage version bundled) especially because of that 
client keytab feature. It is a key for automation (case 2) and I am very 
grateful for this. Case one applies to FreeBSD and RHEL at the moment only.
I am used to have this with JGSS by default.

Thanks,

Michael