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@redhat.com> 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@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users