Learn more about these different git repos.
Other Git URLs
If sssd is not running login for local users fails with:
login[1234]: pam_sss(login:auth): Request to sssd failed. Connection refused [[BR]] login[1234]: pam_sss(login:account): Request to sssd failed. Connection refused [[BR]] login[1234]: System error
There are a lot of issues around return codes in pam_sss.c it looks like. The biggest problem is a mix of return codes in {{{sss_pam_make_request()}}}. Sometimes it returns PAM error codes, and sometimes NSS error codes.
The main problem is that we're returning PAM_SYSTEM_ERR when SSSD is unreachable, but this needs to be PAM_AUTHINFO_UNAVAIL.
component: SSSD => PAM description: If sssd is not running login for local users fails with:
login[1234]: pam_sss(login:auth): Request to sssd failed. Connection refused [[BR]] login[1234]: pam_sss(login:account): Request to sssd failed. Connection refused [[BR]] login[1234]: System error => If sssd is not running login for local users fails with: {{{ login[1234]: pam_sss(login:auth): Request to sssd failed. Connection refused [[BR]] login[1234]: pam_sss(login:account): Request to sssd failed. Connection refused [[BR]] login[1234]: System error }}} milestone: NEEDS_TRIAGE => SSSD 1.5.14 owner: somebody => jhrozek
If we end up doing this ticket in 1.5.x, we should backport commit 66e691c to 1.5. branch. It makes checking for the return codes much saner.
This issue is only triggered when the PAM stack is not configured properly. Moving to 1.7
milestone: SSSD 1.5.14 => SSSD 1.7.0
Offloading to Jan
owner: jhrozek => jzeleny
This is the pam stack they were using - http://paste.ubuntu.com/697877/
PAM config common-account
I discovered one error in the pam config. I changed the error code as Stephen suggested, but that made no change. After that I noticed that only user_unknown is checked in the config. That is generally OK I guess, but authinfo_unavail=ignore should be also added to make this work.
status: new => assigned
Note that you can hit this also on Fedora/RHEL. To reproduce, configure and enable Winbind authentication, make sure an AD user can login in. Then authconfig --enablesssd --enablesssdauth --update and stop sssd. Now the AD user can't login any more until you comment out account/pam_sss.so line in /etc/pam.d/system-auth.
If you have this setup on some machine, could you post the line with pam_sss.so?
account [default=bad success=ok user_unknown=ignore] pam_sss.so
Yeah, that's exactly the same case as the previously described. The correct solution would be to fix it in authconfig.
Fields changed
patch: 0 => 1
milestone: SSSD 1.7.0 => SSSD 1.5.16
Fixed by: - a63aee2 (master) - e0bdfb3 (sssd-1-6)
Backport for sssd-1-5 pending
Backported to sssd-1-5 as b9e5875 (along with cherry-picking e0a3894 as a dependency).
resolution: => fixed status: assigned => closed
rhbz: => 0
Metadata Update from @myllynen: - Issue assigned to jzeleny - Issue set to the milestone: SSSD 1.5.16
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/2053
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Log in to comment on this ticket.