> 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 [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
