I am now facing another problem: The lifetime of my TGT is 1 hrs. After doing kinit, I call gss_acquire_cred to get clientCredential handle and then use it in gss_init_sec_context (with spnego as OID). If ticket is valid - it works fine.
But, after 1 hrs, the TGT expire. However, now gss_init_sec_context() is still generating the token (I was expecting it to return cred_expired minor status - but now it returning 0 for minor status - is it expected behaviour ?). And this token when used with HTTP negotiate - gives 401 unauthorised due to invalid credentials error. Earlier, when I used to pass NO_OID in gss_init_sec_context, it used to return the expected minor status. How to get correct minor status from gss_init_sec_context api after ticket has expired. Please help ! Arpit On Thu, Jan 30, 2014 at 9:32 AM, arpit.orb <arpit....@gmail.com> wrote: > Thanks Greg..I figured out the problem. > > I was not calling gss_acquire_cred beforr calling gss_init_sec_context. As > client cred, I was simply passing NO CREDENTIALS. > > So, it is important to call acquire_cred api for client credential handle > and then use that in context establishment. > > Arpit > > > -------- Original message -------- > From: Greg Hudson > Date:28/01/2014 4:03 AM (GMT+05:30) > To: Arpit Srivastava ,kerberos > Subject: Re: Correct way of using SPNEGO OID with MIT Kerberos > > (I removed krbdev from the CC list in this reply because this isn't > about the development of MIT krb5. Please pick just one list when > sending mail.) > > On 01/27/2014 01:01 PM, Arpit Srivastava wrote: > > However, when I use OID of SPNEGO by passing it as parameter to > > gss_init_sec_context() method, the library tries to acquire creds for all > > the mechanism available but fails to do so in all three attempts, perhaps > > for each mechanism (in spnego_mech.c). Call to gss_init_sec_context fails > > with minor status 100004. > > I'm not sure why credential acquisition in the krb5 mech would work > directly but not through SPNEGO. Unfortunately, the minor code is not > useful since it's just an entry in a mechglue map; you must pass it to > gss_display_status in the process which produced the code to find out > what it means. > > > I can also not figure out how to give my preference for supported > > mechanisms. > > gss_set_neg_mechs, as described in RFC 4178. > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
