You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/828
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.
Comments
Comment from sbose at 2011-03-23 12:08:36
FYI IIRC 'kinit -R' does the same, this is why I implemented it this way.
Comment from simo at 2011-03-23 14:16:08
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.
Comment from sgallagh at 2011-03-24 13:46:30
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.7.0
priority: major => minor
Comment from dpal at 2011-07-22 22:10:24
Fields changed
milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0
Comment from simo at 2011-08-04 21:30:28
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: =>
Comment from dpal at 2012-01-16 16:44:56
Fields changed
blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Kerberos improvements
Comment from dpal at 2012-01-16 17:19:02
Fields changed
priority: minor => major
Comment from dpal at 2012-01-16 17:26:04
Fields changed
priority: major => critical
Comment from dpal at 2012-02-10 23:45:57
Fields changed
rhbz: => 0
Comment from dpal at 2012-08-16 23:10:46
Fields changed
feature_milestone: =>
proposed_priority: => Important
Comment from nalin at 2012-08-16 23:26:12
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
Comment from jgalipea at 2012-08-20 16:20:28
Fields changed
rhbz: 0 => todo
Comment from dpal at 2012-09-04 23:20:21
Moving all the features planned for 1.10 release into 1.10 beta.
milestone: SSSD Kerberos Improvements Feature => SSSD 1.10 beta
Comment from dpal at 2012-09-04 23:47:52
Fields changed
priority: critical => major
Comment from dpal at 2012-09-04 23:50:12
Fields changed
priority: major => minor
Comment from dpal at 2012-09-04 23:52:14
Fields changed
priority: minor => major
Comment from dpal at 2012-12-20 23:33:42
Fields changed
selected: => Not need
Comment from dpal at 2013-01-02 15:32:08
Moving tickets that are not a priority for SSSD 1.10 into the next release.
milestone: SSSD 1.10 beta => SSSD 1.11 beta
Comment from dpal at 2013-07-30 10:34:41
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
Comment from jhrozek at 2016-11-08 22:27:27
Fields changed
component: SSSD => Kerberos Provider
mark: => 0
sensitive: => 0
Comment from simo at 2017-02-24 14:57:17
Metadata Update from @Simo:
Comment from pbrezina at 2020-03-24 14:22:43
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.
Comment from pbrezina at 2020-03-24 14:22:45
Metadata Update from @pbrezina:
The text was updated successfully, but these errors were encountered: