Is that the sssd configuration on the server or the client? There's no
sss_cache executable on the client; is that correct? 

I noticed that when I remove a user from the sudo role, the clients
notice it almost immediately, but when I readd the sudo role, it doesn't
come back. I usually have to restart sssd on the client. I tried setting
entry_cache_timeout on the client to 60 and even setting
cache_credentials to false, but those don't seem to have changed
anything. For reference, here's part of the sssd.conf on the client: 


cache_credentials = False
krb5_store_password_if_offline = True
ipa_domain = ipa.services.FOO
id_provider = ipa
auth_provider = ipa
access_provider = permit
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname =
chpass_provider = ipa
ipa_server = _srv_, ipa.services.FOO
dns_discovery_domain = ipa.services.FOO
entry_cache_timeout = 60 

Am I doing something wrong here? 

On 2017-04-06 03:11, Martin Bašti wrote:

> On 06.04.2017 01:57, Greg Gilbert wrote: 
>> Hey. I'm a bit new to FreeIPA, so apologies if this has already been 
>> addressed. For reference, I'm running FreeIPA 4.4 server on CentOS 7, and 
>> FreeIPA client 4.3.1 on Ubuntu nodes.
>> I've noticed that when I make changes to policies, it either takes a long 
>> time to propagate out to the client nodes, or requires a manual restart of 
>> the sssd service. In this case, I'm testing adding and removing a user from 
>> a sudo rule. Is this the correct behavior, or is there a misconfiguration on 
>> my part somewhere?
>> - greg
> Hello,
> it is caused by SSSD caches, to refresh particular objects in cache see `man 
> sss_cache`.
> You can lower TTL for records in cache, but the lower TTL, the higher load on 
> server (`man sssd.conf` search for cache).
> Martin
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to