On Wed, Feb 27, 2019 at 03:28:08PM -0500, Mark Reynolds via FreeIPA-users wrote: > Forwarding to freeipa-users who have more knowledge on SSSD > > > > -------- Forwarded Message -------- > Subject: [389-users] How to invalidate local cache after user changed > their > password > Date: Wed, 27 Feb 2019 19:22:19 +0000 (UTC) > From: xinhuan zheng <xhzheng2...@yahoo.com> > Reply-To: General discussion list for the 389 Directory server project. > <389-us...@lists.fedoraproject.org> > To: 389-us...@lists.fedoraproject.org > > > > Hello, > > I have been struggling with this problem for a while. When a user changed > their password, our 389 directory servers received new password and saved > into directory server. However, when user tries to login to a server whose > authentication is using 389 directory server, their new password won't work > for the first few minutes. There is a local cache process, sssd, running on > the server the user tries to login. Apparently sssd is still using old > password information, and does not know password has changed on directory > servers. I have set sssd to keep cache information for 5 minutes only, and > do pre-fetch prior to cache information expiring. But I don't know how to > tell sssd to ignore cache completely when information has changed on 389 > directory server side. > > Is there a way to completely disable sssd local cache, and only use it when > 389 directory servers are not available?
If SSSD stores a hashed version of the password in it cache or not is controlled by the cache_credentials option in the [domain/...] section of sssd.conf. The default is 'false' I assume you have set it to 'true', see man sssd.conf for details. But please note that SSSD only uses the cache password if the backend is offline, i.e. SSSD thinks it cannot reach any servers. You can check with 'sssctl domain-status domain.name' if SSSD thinks it is online or not at the time the cached (old) password is still used for authentication. Btw, I assume you have not set cached_auth_timeout in sssd.conf, using this option might explain the observed behavior as well. HTH bye, Sumit > > Thank you, > > - Xinhuan > _______________________________________________ > 389-users mailing list -- 389-us...@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
