Description of problem: When configuring PAM to use pam_sss.so, following parameters are used: default=bad success=ok user_unknown=ignore This causes error when SSSD daemon is not running and authinfo_unavail code is returned by pam_sss.so module. The argument list of pam_sss.so should also contain authinfo_unavail=ignore to fix this issue.
No, this would not be correct. Use the --enablelocauthorize option to achieve the same result. Perhaps we could make the --enablelocauthorize on by default.
Thanks for looking into this. If setting it as "on" by default won't have any other side effects, I believe it's the right choice.
Actually this option is already on by default in the current releases. Is there 'account sufficient pam_localuser.so' line in the /etc/pam.d/system-auth before the account ... pam_sss.so line?
(In reply to comment #3) > Actually this option is already on by default in the current releases. Is there > 'account sufficient pam_localuser.so' > line in the /etc/pam.d/system-auth before the account ... pam_sss.so line? Yes, there is, on both RHEL 6 and Fedora 16. However, I'm wondering why having authinfo_unavail=ignore would be an incorrect solution for the cases like SSSD and Winbind where the daemon might be running for some reason? pam_localuser.so sounds unrelated to the case where both SSSD and Winbind are running on the same system. This is related to bug 760109 where there's an issue with authconfig generated PAM configuration with SSSD+Winbind but it seems that it might be better fixed in Winbind not in authconfig. Thanks.
> where the daemon might be running for some reason Obviously: "where the daemon might /not/ be running for some reason"
Well there is albeit small race condition where an authentication might succeed and then the authorization would not be done due to the daemon stopping/crashing although in case it would be running it would reject the user. Also the configuration with both sssd and winbind is really a borderline one and I'd expect users with such configurations to be able to adjust the configuration to their needs. Some might prefer more tight security and others availability.