Client keytab ignored when CC has expired
Michael Osipov
michaelo at apache.org
Wed Jul 30 17:52:33 EDT 2014
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
More information about the Kerberos
mailing list