How to invalidate local cache after user changed their password

[xinhuan zheng]

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

[William Brown]

>  On 28 Feb 2019, at 05:22, xinhuan zheng <xhzheng2001(a)yahoo.com&gt;
> 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

[xinhuan zheng]

 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(a)suse.de&gt;
wrote:  
 
 

>  On 28 Feb 2019, at 05:22, xinhuan zheng <xhzheng2001(a)yahoo.com&gt;
> 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...

[William Brown]

>  On 1 Mar 2019, at 01:15, xinhuan zheng <xhzheng2001(a)yahoo.com&gt;
> 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