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 = 10.100.15.40
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
> it is caused by SSSD caches, to refresh particular objects in cache see `man
> You can lower TTL for records in cache, but the lower TTL, the higher load on
> server (`man sssd.conf` search for cache).
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project