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