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