Password Changing with SSSD not running

[Kevin Sullivan]

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

[Dmitri Pal]

On 04/25/2014 04:39 PM, kevin sullivan wrote:
>  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? 

Are your local accounts same as remote ones?
If yes then this is wrong. 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.
Password changes can't be done offline.
It is also recommended to have only root and local system accounts like 
oracle or tomcat or apache in /etc/passwd. Once you clean this up from 
the real user accounts put it in front of SSSD in PAM and NSS 
configuration so that root can always login. Other accounts should be 
just there but should not be interactive user accounts. The rest SSSD 
will take care of.

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

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Lukas Slebodnik]

On (25/04/14 16:39), kevin sullivan wrote:
> 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 
Why do you want to have pam_sss before pam_unix for password?
The following configuration works for me even with stopped sssd.

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3
authtok_type=
password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

LS

[Simo Sorce]

On Fri, 2014-04-25 at 16:39 -0400, kevin sullivan wrote:
>  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. 
Sorry to say this (I generally avoid it) but you are doing it wrong
right here.

One of the principal features of SSSD is its offline mode, which has
been built explicitly so that you do not need to have different accounts
locally and remotely.

You only have your LDAP account, and when the machine goes offline (ie,
can't reach the LDAP server for whatever reason), then SSSD uses the
local cache to serve your machine as if nothing had happened.

It works also for authentication although not enabled by default.
(See man sssd.conf: cache_credentials ).

So with SSSD what you should do is to get rid of local accounts that
duplicate/shadows LDAP accounts, and live happily thereafter.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Kevin Sullivan]

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



On Fri, Apr 25, 2014 at 5:48 PM, Simo Sorce <simo(a)redhat.com&gt; wrote:

>  On Fri, 2014-04-25 at 16:39 -0400, kevin sullivan wrote:
>  > 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.
>
>  Sorry to say this (I generally avoid it) but you are doing it wrong
>  right here.
>
>  One of the principal features of SSSD is its offline mode, which has
>  been built explicitly so that you do not need to have different accounts
>  locally and remotely.
>
>  You only have your LDAP account, and when the machine goes offline (ie,
>  can't reach the LDAP server for whatever reason), then SSSD uses the
>  local cache to serve your machine as if nothing had happened.
>
>  It works also for authentication although not enabled by default.
>  (See man sssd.conf: cache_credentials ).
>
>  So with SSSD what you should do is to get rid of local accounts that
>  duplicate/shadows LDAP accounts, and live happily thereafter.
>
>  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
>

[Lukas Slebodnik]

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

[Kevin Sullivan]

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&gt;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
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Dmitri Pal]

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:[e-mail]>> 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:[e-mail]>
>      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?
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.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Jakub Hrozek]

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:[e-mail]>> 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:[e-mail]>
>  >    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.

[Jakub Hrozek]

On Fri, Apr 25, 2014 at 04:39:49PM -0400, kevin sullivan wrote:
>  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 
Are you sure SSSD was running at this point?

Connection refused sounds an awful lot like the deamon was not up at
all.

Can you check if sssd was running (service sssd start, service sssd
status) and paste if the error code pam_sss returns is the same as you
pasted above?

[Lukas Slebodnik]

On (25/04/14 16:39), kevin sullivan wrote:
> 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
>  
I checked the source code of pam_sss. If I read source code corretly,
you should remove argument use_authtok.

Could you try with next line?
password    sufficient    pam_sss.so forward_pas

LS

> 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

[Kevin Sullivan]

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.

What seems to happen is that I am prompted for my current password, and
then my new password, and then my new password again. Once I submit all
three, the password change operation fails with 'passd: Authentication
token manipulation error'. I see this 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

Since SSSD isn't running, I don't see anything in the SSSD logs. Is there a
way I can check the return value of pam?

I was assuming that pam_sss wasn't forwarding the password through the pam
stack because it has a 'forward_pass' option and because pam_unix was
complaining about not receiving the password. But I may not understand pam
as well as I should, so feel free to correct me if I am wrong.

Thanks,

Kevin


On Mon, Apr 28, 2014 at 3:12 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:

>  On Fri, Apr 25, 2014 at 04:39:49PM -0400, kevin sullivan wrote:
>  > 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
>
>  Are you sure SSSD was running at this point?
>
>  Connection refused sounds an awful lot like the deamon was not up at
>  all.
>
>  Can you check if sssd was running (service sssd start, service sssd
>  status) and paste if the error code pam_sss returns is the same as you
>  pasted above?
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Jakub Hrozek]

On Mon, Apr 28, 2014 at 09:30:32PM +0200, Lukas Slebodnik wrote:
>  On (25/04/14 16:39), kevin sullivan wrote:
>  >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
>  >
>  I checked the source code of pam_sss. If I read source code corretly,
>  you should remove argument use_authtok.
>  
>  Could you try with next line?
>  password    sufficient    pam_sss.so forward_pas 
I think it would be best to let the (arguably complex and fragile) PAM
configuration to be autogenerated by a tool that was written specifically
for the purpose, like authconfig :)

btw this is how my password stack on Fedora looks like:

password    optional      pam_pwquality.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

[Jakub Hrozek]

On Mon, Apr 28, 2014 at 04:23:45PM -0400, kevin sullivan wrote:
>  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. 
Oops, I'm sorry, I was checking another case where pam_sss seemed to be
misbehaving if it was offline while a password change was attempted and
apparently mixed the two...

I'd still recommend to use some tool to configure the pam stack,
though..

[Kevin Sullivan]

Thanks Jakub! I have moved pam_sss after pam_unix in the password
management group of my system-auth per your recommendations (and the
recommendations of other people) and things work fine.

Thank you very much!


On Mon, Apr 28, 2014 at 4:29 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:

>  On Mon, Apr 28, 2014 at 04:23:45PM -0400, kevin sullivan wrote:
>  > 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.
>
>  Oops, I'm sorry, I was checking another case where pam_sss seemed to be
>  misbehaving if it was offline while a password change was attempted and
>  apparently mixed the two...
>
>  I'd still recommend to use some tool to configure the pam stack,
>  though..
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Sumit Bose]

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:[e-mail]>> 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:[e-mail]>
>  > >    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

[Kevin Sullivan]

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:[e-mail]>> 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:[e-mail]>
>  > > >    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
>

[Sumit Bose]

On Tue, Apr 29, 2014 at 07:22:43AM -0400, kevin sullivan wrote:
>  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&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:[e-mail]>> 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:[e-mail]>
>  > > > >    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

[Simo Sorce]

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

[Sumit Bose]

On Tue, Apr 29, 2014 at 09:14:07AM -0400, Simo Sorce wrote:
>  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. 
Do you think it would be ok to use the 'forward_pass' option for this as
well or do you prefer to add a new one?

bye,
Sumit

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

[Simo Sorce]

On Tue, 2014-04-29 at 15:56 +0200, Sumit Bose wrote:
>  On Tue, Apr 29, 2014 at 09:14:07AM -0400, Simo Sorce wrote:
>  > 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.
>  
>  Do you think it would be ok to use the 'forward_pass' option for this as
>  well or do you prefer to add a new one? 
Not sure, I do not see any reason why it would hurt, but is there any
case where you'd like to use that option but *not* enable the behavior
we discussed ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York