Correct way of using SPNEGO OID with MIT Kerberos

[Arpit Srivastava]

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.orb at 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.
>