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.com> wrote:
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