dotnet
Force refreshing ticket near expiration?
Is your feature request related to a problem? Please describe. So currently as I am experimenting the ticket expiration is always the same even if you call renew/authenticate and getserviceticket multiple times. This makes me wonder what would happen if at the edge of expiration kerberos ticket is retrieved but used in the request a second after it has expired (due to just some delay).
Describe the solution you'd like To avoid this I would like to force refresh/generate new ticket that would have new expiration.
Describe alternatives you've considered I couldn't get this to happen any other way except when creating new instance of the KerberosClient. I obviously could just add some sleep if I can see that the ticket is about to expire, but that is not ideal.
Is this already possible in some way or maybe the usage of kerberos is incorrect here?
Calling RenewTicket() actually only renews the TGT, which isn't especially helpful in this case. A new API could be added that accepts an indicator to a specific ticket instead and that would help things.
However, the underlying issue is that the ticket cache just returns whatever is in the cache up until it's expired. If it's expired by the time the cache retrieves it, it'll request a new one, cache that, and return it. However, in the scenario you describe it'll return a valid ticket, and as it expires a few seconds later the service receiving the ticket will do one of two things: it'll either accept it as it's within the time skew window (+/- 5 min give or take); or it'll return a specific error message indicating the ticket expired and it needs a new one. Which option it chooses is application-dependent.
I see, so yeah, I managed to achieve behavior that I wanted by replacing default MemoryTicketCache with slightly modified one that allows to clear it on demand. Then as you mentioned, when it does authentication it has to get new ticket with which it then also gets new service ticket. I am not sure how common this use case would be for others, but being able to clear the initial authentication ticket to force new ticket generation might be beneficial to others.
I wouldn't recommend clearing the TGT. A simpler approach might be to just modify the cache behavior so it drops the ticket if it's going to expire in <5 min (or whatever set timeframe). That way the client is just forced to request a new ticket. The other bit of this though is that TGTs have fixed lifetimes, so they expire every 10 hours or so, but you can renew them before they expire for up to 14 days.
Well yeah, thats along the lines of how the overall logic works, if the ticket is near end of lifetime (~10minutes until expiration) then the entire cache is being cleared. Then reauthentication + get service ticket creates a fresh new pair. Also I believe when I tried keeping TGT ticket (or just not CacheServiceTickets which should always request new service ticket) even if it would request new service ticket, the lifetime of service ticket didn't seem to change (seemed like server just returns same valid ticket for current tgt).