[36314] in Kerberos
Re: Re: Client keytab ignored when CC has expired
daemon@ATHENA.MIT.EDU (Michael Osipov)
Thu Jul 31 03:24:50 2014
MIME-Version: 1.0
Message-ID: <trinity-e3193417-fbb4-4b72-ab37-3dafbcb35a53-1406791474093@3capp-gmx-bs30>
From: "Michael Osipov" <1983-01-06@gmx.net>
To: "Greg Hudson" <ghudson@mit.edu>
Date: Thu, 31 Jul 2014 09:24:34 +0200
In-Reply-To: <53D96E04.5030907@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/30/2014 05:52 PM, Michael Osipov wrote:
> > 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
>
> I'm still confused about this use case. If the client keytab contains
> the key you need to authenticate to the HTTP server, is there a reason
> why you'd ever use kinit?
Human error. The best thing to do is probably stop doing that, isn't it?
> > 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.
>
> I would suggest setting KRB5CCNAME as well, so that these programs use a
> separate ccache from logged-in users. Unless the people logging in are
> always running kinit with a principal that the program can (and should)
> be authenticating with, you'll want to separate the ccache for those
> uses regardless of the client keytab design.
That sounds reasonable and should solve the issue. Albeit, I do think that the detection
algorithm could be better and pursue a best-effort/match/seldom-fail approach. It make the
entire process idiot-proof.
Thanks for your valueable advises,
Michael
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
