Lukas,
Thanks for the response!
In his case, pam_sss will return PAM_AUTHINFO_UNAVAIL and not
PAM_USER_UNKNOWN
What I was referencing in my example wasn't that pam_sss is returning the wrong return code, it seems like pam is handling the return code correctly and falling through to the pam_unix module, however, pam_sss isn't forwarding the password to pam_unix. Which I believe is why I am seeing the following error in /var/log/secure:
Apr 25 16:01:28 localhost passwd: pam_unix(passwd:chauthtok): password - new password not obtained
That is why I was saying that pam_winbind seemed to be handling things as I would expect.
Thanks,
Kevin
On Mon, Apr 28, 2014 at 11:05 AM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (28/04/14 10:32), kevin sullivan wrote:
Thanks for the prompt and candid responses! I apologize for responding so slowly.
Here is what I am taking away from this email exchange:
SSSD supports caching and you should remove local accounts and not have
duplicates. If SSSD offline you can make it cache a hash of the user password for the cases when SSSD is offline.
So what I am doing is currently not supported and not recommended.
Although
I am not using caching, I can move pam_unix above pam_sss in the password section of my system-auth and things appear to work.
Password changes can't be done offline.
I guess I am just surprised that pam_sss doesn't fail gracefully when SSSD is offline. For example, if I replace pam_sss with something like pam_winbind, things work as expected:
password requisite pam_cracklib.so retry=3 minlen=10 password sufficient pam_winbind.so debug use_authtok password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password required pam_deny.so
Output from /var/log/secure:
Apr 25 16:01:21 localhost passwd: pam_winbind(passwd:chauthtok): [pamh: 07f987ac84ef0] ENTER: pam_sm_chauthtok (flags: 0x4000) Apr 25 16:01:21 localhost passwd: pam_winbind(passwd:chauthtok): username [user] obtained Apr 25 16:01:21 localhost passwd: pam_winbind(passwd:chauthtok): valid_user: wbcGetpwnam gave WBC_ERR_WINBIND_NOT_AVAILABLE Apr 25 16:01:21 localhost passwd: pam_winbind(passwd:chauthtok): [pamh: 07f987ac84ef0] LEAVE: pam_sm_chauthtok returning 10 (PAM_USER_UNKNOWN)
In his case, pam_sss will return PAM_AUTHINFO_UNAVAIL and not PAM_USER_UNKNOWN
define PAM_AUTHINFO_UNAVAIL 9 /* Underlying authentication service */ /* can not retrieve authentication */ /* information */
Apr 25 16:01:21 localhost passwd: pam_unix(passwd:chauthtok): username [user] obtained
And this is what I would expect SSSD to do, to return an error but not
make
it so other stacked modules wouldn't receive the password that it prompted for. Or maybe, like pam_winbind, it wouldn't even prompt for the password if it can't reach the server. Also, I don't use pam_winbind, I don't
really
even know what it does, and I don't know if it is a good example, but I am just using it to illustrate a point.
Thanks,
Kevin
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users