Client keytab ignored when CC has expired

Michael Osipov 1983-01-06 at gmx.net
Thu Jul 31 03:24:34 EDT 2014


> 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


More information about the Kerberos mailing list