#1011 Local user login fails if sssd is not running
Closed: Fixed None Opened 13 years ago by myllynen.

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

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?

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

Fields changed

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

Fields changed

rhbz: => 0

Metadata Update from @myllynen:
- Issue assigned to jzeleny
- Issue set to the milestone: SSSD 1.5.16

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

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.

Log in to comment on this ticket.

Metadata