Ok, consider following usecase which I am employing Negotiate tokens. - a service ticket obtained by calling gss_init_sec_context for a lifetime less than that of TGT. - Now, service ticket expires but TGT is still valid. - gss_init_sec_context called again and a new service ticket acquired.
Now here, the krb5cc cache would keep on accumulating service tickets of same name but different validity time stamps. Isn't that superfluous ? - Is there any way to renew service tickets the way TGT is renewed (atleast till the validity of TGT) using GSS/Krb APIs. - Is there any way to discard expired tickets from credentials because anyways they are unusable using GSS/Krb APIs. Arpit On Tue, Mar 25, 2014 at 9:26 PM, Greg Hudson <[email protected]> wrote: > On 03/25/2014 11:19 AM, Arpit Srivastava wrote: > > I call gss_init_sec_context with say, /time_req = 20 mins. /Every time > > the service ticket hence obtained expires, a new service ticket is > > obtained with 20 mins validity, instead of renewing the one already > > existing in the cache (so, there are two tickets of same SPN but with > > different validity time stamps). I observed that if I pass time_req = > > GSS_C_INDEFINITE, the same ticket is renewed and a new ticket is not > > created. It would be great if you can provide some insights. > > To the best of my knowledge, gss_init_sec_context has no support for > renewing service tickets, only getting new ones using a TGT. > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
