Hello Mr. Brown,
Thanks for your input.
Here is my config after trim for public email:
[domain/MYLDAP]auth_provider = ldapcache_credentials = true
dns_resolver_timeout = 5entry_cache_timeout = 300enumerate = trueid_provider =
ldapldap_id_use_start_tls = true
[domain/LOCAL]auth_provider = localenumerate = trueid_provider = local
[nss]entry_cache_nowait_percentage = 75entry_cache_timeout = 300
reconnection_retries = 3
[pam]debug_level = 5offline_credentials_expiration =
2offline_failed_login_attempts = 3offline_failed_login_delay =
5reconnection_retries = 3
[sssd]config_file_version = 2debug_level = 5domains =
LOCAL,MYLDAPreconnection_retries = 3sbus_timeout = 30services = nss,pam,ssh
- Xinhuan
On Wednesday, February 27, 2019, 7:42:38 PM EST, William Brown
<wbr...@suse.de> wrote:
> On 28 Feb 2019, at 05:22, xinhuan zheng <xhzheng2...@yahoo.com> wrote:
>
> 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?
I’ve never seen SSSD behave like this - but I would also believe it to be true.
My SSSD configuration has an extremely low cache timeout for avoiding this
issue.
[domain/blackhats.net.au]
ignore_group_members = False
entry_cache_group_timeout = 60
cache_credentials = True
id_provider = ldap
auth_provider = ldap
access_provider = ldap
chpass_provider = ldap
ldap_referrals = False
ldap_access_order = filter, expire
[nss]
memcache_timeout = 60
I’ve trimmed the config (obviously) for email.
Can you provide your SSSD config to me to examine to see if I can spot any
issues?
>
> Thank you,
>
> - Xinhuan
> _______________________________________________
> 389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
_______________________________________________
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
