#828 keep valid tickets on credentials refreshes
Closed: wontfix 3 years ago by pbrezina. Opened 13 years ago by simo.

When we refresh credentials after a successful authentication we also wipe out any existing valid ticket that was in the cache. We should avoid doing that unless those tickets are expired. And keep them. This will allow services to avoid having to ask for new tickets just because we refreshed the main credentials.

This is probably done by the krb5 libraries themselves, so we may need to work with upstream to properly address this (objectively minor) issue.
There are ways to workaround krb library issues by explicitly manipulating the credential cache file to insert/replace the new credentials instead of letting the library do that automatically, but this may complicate the code a bit.


FYI IIRC 'kinit -R' does the same, this is why I implemented it this way.

Yes we would behave differently than kinit, but I think it makes sense we do, as kinit is something the user has to run consciously, so the user will avoid calling it when not necessary, we are doing a renew of credentials under the cover instead, so we shouldn't wipe out tickets that are currently still valid IMO.

Maybe we could have an option to decide what to do in this case, the reason why I think we should at least have the option of not wiping out existing tickets is that it is surprising for users, and if the user can't reach the KDC, but can still reach the service it wants to talk to, then the user will be prevented from using GSSAPI auth (and thus possibly prevented from using the service entirely) even if the user just got a valid ticket recently.

This came out in a situation where a user had valid credentials but couldn't reach the KDC, after sssd successfully renewd credentials (and removed the valid tickets for the imap/ server which was reachable.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0
priority: major => minor

Fields changed

milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0

Discussing with MIT there are good reasons to nuked old tickets when the TGT is renewed.
Given this fact in SSSD we should behave in a smart way.
On authentication we should take a list of tickets currently valid (ignore already expired ones) and right after the new kinit is successfully performed and we have a new TGT (and nuked the cache), go back to the KDC and pre-fetch new tickets to replace the old ones we just nuked.
This should be done using a temporary ccache file so that the old a new content can be swapped only once all the tickets have been acquired to avoid races with applications if we nuke the ccache and then an app tries to access a ticket before we are finished fetching all new tickets.

rhbz: =>

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Kerberos improvements

Fields changed

priority: minor => major

Fields changed

priority: major => critical

Fields changed

rhbz: => 0

Fields changed

feature_milestone: =>
proposed_priority: => Important

Just a heads-up: when the library starts to offer an "in_ccache" get-init-creds option, passing in the old (soon-to-be-nuked) credential cache should help ensure that the new credentials are obtained in the same way (in terms of preauth mechanism, and perhaps also client credential selection) as the ones which are about to be replaced.

Please also take care to use the out_ccache option when it's available; this is how the library expects to be able to store configuration data to the cache. Right now it just stores a flag indicating whether or not the realm's KDC supports FAST, but in the future that's also going to be how the data that it will be attempting to read from the in_ccache (as above) gets stored to caches.

cc: => nalin

Fields changed

rhbz: 0 => todo

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: SSSD Kerberos Improvements Feature => SSSD 1.10 beta

Fields changed

priority: critical => major

Fields changed

priority: major => minor

Fields changed

priority: minor => major

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

It is OK as is. There is no compelling reason to do it any time soon. Moving to deferred.

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD 1.13 beta => SSSD Deferred
review: => 0

Fields changed

component: SSSD => Kerberos Provider
mark: => 0
sensitive: => 0

Metadata Update from @simo:
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1870

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata