[36309] in Kerberos
Re: Re: Client keytab ignored when CC has expired
daemon@ATHENA.MIT.EDU (Michael Osipov)
Wed Jul 30 02:35:08 2014
MIME-Version: 1.0
Message-ID: <trinity-44f26e58-fe62-4dad-a37e-198e11320525-1406702091489@3capp-gmx-bs53>
From: "Michael Osipov" <1983-01-06@gmx.net>
To: "Greg Hudson" <ghudson@mit.edu>
Date: Wed, 30 Jul 2014 08:34:51 +0200
In-Reply-To: <53D80ACD.7030806@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
> On 07/29/2014 04:50 PM, Michael Osipov wrote:
> > my application tries to acquire a GSS credential with a client keytab:
> >
> > $ KRB_CLIENT_KTNAME=$HOME/client.keytab app
>
> The environment variable is KRB5_CLIENT_KTNAME, not KRB_CLIENT_KTNAME.
> Did you use the correct variable name?
I am sorry, that was a typo of course. I have set KRB5_CLIENT_KTNAME in my .profile.
> > No credential is obtained. At that time, the credential was already
> > expired.
>
> Was the credential acquired using the client keytab via GSSAPI, or by
> hand? The intent is that we refresh credentials obtained using the
> client keytab when they are halfway to expired, but that only works if
> they were acquired by GSSAPI from the client keytab in the first place.
The credential was acquired either by kinit password or by kinit -k -t.
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.
Why is there a difference in the first place?
Thanks,
Michael
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
