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? Thank you, - Xinhuan
On 28 Feb 2019, at 05:22, xinhuan zheng xhzheng2001@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-leave@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....
— Sincerely,
William Brown Software Engineer, 389 Directory Server SUSE Labs
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 wbrown@suse.de wrote:
On 28 Feb 2019, at 05:22, xinhuan zheng xhzheng2001@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-leave@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....
— 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-leave@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....
On 1 Mar 2019, at 01:15, xinhuan zheng xhzheng2001@yahoo.com wrote:
Hello Mr. Brown,
Thanks for your input.
Here is my config after trim for public email:
[domain/MYLDAP] auth_provider = ldap cache_credentials = true
dns_resolver_timeout = 5 entry_cache_timeout = 300
^ Turn this value down I think. The cache timeout only matters here when you are online, but it will keep using entries when you are “offline”.
There is a similar memcache setting that I have in my config, which I also set to a low value to help with this issue too.
enumerate = true id_provider = ldap ldap_id_use_start_tls = true
[domain/LOCAL] auth_provider = local enumerate = true id_provider = local
[nss] entry_cache_nowait_percentage = 75 entry_cache_timeout = 300
^ Try turning this value down
reconnection_retries = 3
[pam] debug_level = 5 offline_credentials_expiration = 2
^ I think you probably don’t need this line, because when you do go offline it might cause you to fail to login.
Saying all this, it’s is one of the biggest challenges of SSSD that the config values are really hard to follow and “see” how they interact with the various tunings of the service which leads to problems like this :(
offline_failed_login_attempts = 3 offline_failed_login_delay = 5 reconnection_retries = 3
[sssd] config_file_version = 2 debug_level = 5 domains = LOCAL,MYLDAP reconnection_retries = 3 sbus_timeout = 30 services = nss,pam,ssh
— Sincerely,
William Brown Software Engineer, 389 Directory Server SUSE Labs
389-users@lists.fedoraproject.org
-
William Brown -
xinhuan zheng