On 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.

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@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