There is a bit more to tell here. If pam_sss has to read to passwordOn Mon, Apr 28, 2014 at 09:09:54PM +0200, Jakub Hrozek wrote:
> On Mon, Apr 28, 2014 at 01:40:01PM -0400, Dmitri Pal wrote:
> > On 04/28/2014 01:09 PM, kevin sullivan wrote:
> > >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 <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@lists.fedorahosted.org
> > > <mailto:sssd-users@lists.fedorahosted.org>
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >sssd-users mailing list
> > >sssd-users@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?
>
> The pam modules don't talk to other modules in the stack, that's the job
> of PAM itself. The PAM module 'just' returns an error code much like a C
> function and PAM (the subsystem) acts upon the error code based on the
> stack setup.
from the user, i.e. if it is the first module on the stack, it has to
explicitly set the PAM_AUTHTOK PAM item to make the password available
to other modules. By default pam_sss does not do it to avoid leaking to
password. You have to set the option 'forward_pass' in the pam
configuration in this case, see pam_sss(8) for details.
bye,
Sumit
>
> > 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.
>
>
> _______________________________________________
> sssd-users mailing list
> sssd-users@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users