On Thu, Apr 17, 2014 at 09:56:31AM -0400, J. Alexander Jacocks wrote:
> Did you remove the SSSD cache on the 'old' clients? I
would first try
> that:
> rm -f /var/lib/sss/db/cache_*
>
> Please note that the cache may contain cached credentials, so removing
> the cache would purge them..but it sounds like your clients can access
> the LDAP server, so offline case shouldn't be the issue for you.
>
Jakub,
Yep, that was it. I should have thought of that!
How long does it take for SSSD to invalidate its cache? Or, is this just
something that I'll have to make a note of, in the unlikely case that we
blow away our backend, again?
Many thanks!
- Alex
Normally the cache expiration time is 5400 seconds
(entry_cache_timeout). But the catch is that currently SSSD is not able
to change the ID of a user if it was already cached. This is a planned
enhancement for a future release:
https://fedorahosted.org/sssd/ticket/2244
So if your test LDAP had different UIDs than the production LDAP, we
might have errored out saving the entry.
Changing other attributes on updating the entry should be supported.