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(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?
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.
There is a bit more to tell here. If pam_sss has to read to password
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users