[Freeipa-users] How long should it take to propagate user role changes?

[Greg Gilbert]

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

[Martin Bašti]

Post by Greg Gilbert
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

[Jakub Hrozek]

Post by Martin Bašti

Post by Greg Gilbert
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).

btw the sudo caching is a bit more complex, but man sssd-sudo hopefully
explains it well.

Also please check in the sssd debug logs if the sssd client is 'online'.

[g***@greg-gilbert.com]

Hey,

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:

[domain/ipa.services.FOO]

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?

Post by Martin Bašti

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

[g***@greg-gilbert.com]

Actually I just saw Jakub's response, and that helped me out. I just
added this to the sssd.conf on the client, and it seems to work:

[domain/ipa.services.FOO]
ldap_sudo_smart_refresh_interval = 60
ldap_sudo_full_refresh_interval = 21600

Thanks, all!

Hey,
Is that the sssd configuration on the server or the client? There's no sss_cache executable on the client; is that correct?
[domain/ipa.services.FOO]
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 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