Modifying description, {{{cached_credentials}}} -> {{{cache_credentials}}}

description: This ticket is inspired by the discussion on the Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1039151

Right now, whenever SSSD goes offline, it internally sets a timer to operate in offline mode for one minute before attempting to reconnect. This behavior is sensible for the ID provider, but it's not terribly useful for the PAM provider, especially in the case of Kerberos.

A common use-case for using kerberos for login is to gain access to kerberized home directories. In such situations, offline login is not useful or desirable, and the admin would likely set {{{cached_credentials = false}}} so that users would not get into a confused situation where authentication succeeded but they couldn't access their home directory.

It's not uncommon for SSSD to end up in offline mode during startup, especially when a startup service makes a request before the network is fully up[1]. Such race conditions are generally not an issue in the ID provider, because they'll be answered by the cache. This does produce a race-condition where a user would not be able to login immediately upon system start.

I recommend that the behavior of the PAM provider be modified so that if {{{cached_credentials = false}}}, it should ALWAYS attempt to re-establish the connection to the LDAP and KDC servers upon receiving a PAM conversation request (of any type; not just authentication).

[1] On Fedora systems, we minimize this by detecting both network link changes and resolv.conf updates, but such events are not always sufficient to re-establish the connection in time. => This ticket is inspired by the discussion on the Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1039151

Right now, whenever SSSD goes offline, it internally sets a timer to operate in offline mode for one minute before attempting to reconnect. This behavior is sensible for the ID provider, but it's not terribly useful for the PAM provider, especially in the case of Kerberos.

A common use-case for using kerberos for login is to gain access to kerberized home directories. In such situations, offline login is not useful or desirable, and the admin would likely set {{{cache_credentials = false}}} so that users would not get into a confused situation where authentication succeeded but they couldn't access their home directory.

It's not uncommon for SSSD to end up in offline mode during startup, especially when a startup service makes a request before the network is fully up[1]. Such race conditions are generally not an issue in the ID provider, because they'll be answered by the cache. This does produce a race-condition where a user would not be able to login immediately upon system start.

I recommend that the behavior of the PAM provider be modified so that if {{{cache_credentials = false}}}, it should ALWAYS attempt to re-establish the connection to the LDAP and KDC servers upon receiving a PAM conversation request (of any type; not just authentication).

[1] On Fedora systems, we minimize this by detecting both network link changes and resolv.conf updates, but such events are not always sufficient to re-establish the connection in time.

Fields changed

milestone: NEEDS_TRIAGE => Temp milestone
proposed_priority: Undefined => Important
rhbz: => todo
type: enhancement => defect

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

milestone: Temp milestone => SSSD 1.10 beta

Fields changed

priority: major => minor

Fields changed

priority: minor => major

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=869143 (Red Hat Enterprise Linux 6)

rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=869143 869143]

Fields changed

design: =>
design_review: => 0
fedora_test_page: =>
type: defect => enhancement

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

Fields changed

mark: => 0

Fields changed

changelog: =>
owner: somebody => preichl
review: => 0

Nice to have, not critical for 1.13

milestone: SSSD 1.13 beta => SSSD 1.13 backlog

Mass-moving tickets not planned for the 1.13 release to 1.14

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

This makes total sense, but the 1.14 bucket is too bing, so I'm moving the ticket to 1.15.

milestone: SSSD 1.14 beta => SSSD 1.15 beta
sensitive: => 0

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.

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/2535

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.