I am seeing an issue when I try to change a local user's password when SSSD (1.9.2-82.el6) is not running. I have two sets of users: users stored in ldap and users stored locally on my RHEL 6.4 machine. When able, I want to login as the ldap users and only fallback to the local users when I can't contact the ldap server. This is why I have pam configured like this: 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 When SSSD is running, I can change the password of local users and ldap users. However, when I try to change the password of a local user when SSSD is not running, I see this error: Changing password for user. passd: Authentication token manipulation error. I then added 'audit' and 'debug' options to the pam_unix module and saw this output in /var/log/secure: Apr 25 16:01:21 localhost passwd: pam_sss(passwd:chauthtok): Request to sssd failed. Connection refused Apr 25 16:01:21 localhost passwd: pam_unix(passwd:chauthtok): username [user] obtained Apr 25 16:01:28 localhost passwd: pam_sss(passwd:chauthtok): Request to sssd failed. Connection refused Apr 25 16:01:28 localhost passwd: pam_unix(passwd:chauthtok): username [user] obtained Apr 25 16:01:28 localhost passwd: pam_unix(passwd:chauthtok): password - new password not obtained Apr 25 16:01:28 localhost passwd: gkr-pam: couldn't update the 'login' keyring password: no old password was entered I know that I can comment out the password line in /etc/pam.d/system-auth-ac that references pam_sss, and the password change will work correctly. Also, I know that I can login using a local account when SSSD is stopped. Here is the auth section of my system-auth-ac: auth required pam_env.so auth sufficient pam_sss.so forward_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so Am I misconfigured somehow? Does pam_sss support forwarding passwords when SSSD is stopped?

Thanks, Kevin _______________________________________________ sssd-users mailing list sssd-users(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

I am seeing an issue when I try to change a local user's password when SSSD (1.9.2-82.el6) is not running. I have two sets of users: users stored in ldap and users stored locally on my RHEL 6.4 machine.

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)

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

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

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 > &gt;&lt;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 > &gt;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.

> 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

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

On Tue, Apr 29, 2014 at 4:07 AM, Sumit Bose <sbose(a)redhat.com&gt; 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 > > > &gt;&lt;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 > > > &gt;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

On Tue, 2014-04-29 at 13:48 +0200, Sumit Bose wrote: > 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. This is a bug we should fix > 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? At most we should make it possible to change with an option, but I think it is totally appropriate.

Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-users mailing list sssd-users(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

I am seeing an issue when I try to change a local user's password when SSSD (1.9.2-82.el6) is not running. I have two sets of users: users stored in ldap and users stored locally on my RHEL 6.4 machine. When able, I want to login as the ldap users and only fallback to the local users when I can't contact the ldap server. This is why I have pam configured like this: 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 When SSSD is running, I can change the password of local users and ldap users. However, when I try to change the password of a local user when SSSD is not running, I see this error: Changing password for user. passd: Authentication token manipulation error. I then added 'audit' and 'debug' options to the pam_unix module and saw this output in /var/log/secure: Apr 25 16:01:21 localhost passwd: pam_sss(passwd:chauthtok): Request to sssd failed. Connection refused Apr 25 16:01:21 localhost passwd: pam_unix(passwd:chauthtok): username [user] obtained Apr 25 16:01:28 localhost passwd: pam_sss(passwd:chauthtok): Request to sssd failed. Connection refused

Jakub, Thank you for your response! I was checking what was happening when SSSD was down. So when I ran into this case, SSSD was not running. The problem was that it doesn't handle things as gracefully as I had hoped.

I am seeing an issue when I try to change a local user's password when SSSD (1.9.2-82.el6) is not running. I have two sets of users: users stored in ldap and users stored locally on my RHEL 6.4 machine. When able, I want to login as the ldap users and only fallback to the local users when I can't contact the ldap server. This is why I have pam configured like this: 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

When SSSD is running, I can change the password of local users and ldap users. However, when I try to change the password of a local user when SSSD is not running, I see this error: Changing password for user. passd: Authentication token manipulation error. I then added 'audit' and 'debug' options to the pam_unix module and saw this output in /var/log/secure: Apr 25 16:01:21 localhost passwd: pam_sss(passwd:chauthtok): Request to sssd failed. Connection refused Apr 25 16:01:21 localhost passwd: pam_unix(passwd:chauthtok): username [user] obtained Apr 25 16:01:28 localhost passwd: pam_sss(passwd:chauthtok): Request to sssd failed. Connection refused Apr 25 16:01:28 localhost passwd: pam_unix(passwd:chauthtok): username [user] obtained Apr 25 16:01:28 localhost passwd: pam_unix(passwd:chauthtok): password - new password not obtained Apr 25 16:01:28 localhost passwd: gkr-pam: couldn't update the 'login' keyring password: no old password was entered I know that I can comment out the password line in /etc/pam.d/system-auth-ac that references pam_sss, and the password change will work correctly. Also, I know that I can login using a local account when SSSD is stopped. Here is the auth section of my system-auth-ac: auth required pam_env.so auth sufficient pam_sss.so forward_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so Am I misconfigured somehow? Does pam_sss support forwarding passwords when SSSD is stopped? Thanks, Kevin