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(a)redhat.com
<mailto: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(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Jakub,
Does SSSD pass the password to the next PAM module? Can it be that this
is a bug?
We assume that SSSD is usually the last in the list so there is no need
to pass but there might be other modules that would want password after
SSSD for other unknown to us reasons.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.