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