Sumit,
Thanks for the response!
That was the thing that was odd to me, I had that option set and it still
wasn't forwarding the password. Here was my configuration for the password
management group:
password requisite pam_cracklib.so retry=3 minlen=10
password sufficient pam_sss.so *forward_pass* use_authtok
password sufficient pam_unix.so md5 shadow nullok try_first_pass
use_authtok
password required pam_deny.so
Thanks,
Kevin
First, forward_pass is not needed here, because it will only forward a
password which is requested by pam_sss. In your configuration
pam_cracklib will ask for the passwords and put them into the
corresponding PAM items. But in case of an error different from
PAM_USER_UNKNOWN during the password change pam_sss will explicitly
delete the PAM items. Iirc the reason for this was the idea that if SSSD
thinks it is responsible for the user but cannot change the password the
password should not leak to other pam modules. Unfortunately if SSSD is
not running the returned error code will trigger this as well.
So I guess should handle the case where SSSD is not running more
gracefully here. As an alternative I wonder if the current behaviour is
maybe too strict and does not offer additional security and can be
removed?
bye,
Sumit
On Tue, Apr 29, 2014 at 4:07 AM, Sumit Bose <sbose(a)redhat.com> wrote:
> 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(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
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)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