The current way is to delete the cache file associated to the domain:
/var/lib/sss/db/cache_<domain>.ldb

Wiping out a cache has side-effects like removing all cached credentials, so
it shouldn't be done if you are not online and can authenticate with your user against the domain's servers.

component: SSSD => Documentation
doc: 0 => 1
owner: somebody => obriend
priority: major => critical

In section 15.1.2.3. "Specifying Multiple Domains" the draft RHEL 6 Deployment Guide mentions the ability to remove the cache file for a particular domain as one of the features of SSSD >= 0.6.0. Until now I wasn't aware of any side effects, but I can update the Dep. Guide with Simo's comments, above. Who normally owns the man pages?

status: new => assigned

David, we would very much appreciate it if you would also update the manpages with this information.

milestone: NEEDS_TRIAGE => SSSD 1.2.1

Replying to [comment:1 simo]:

The current way is to delete the cache file associated to the domain:
/var/lib/sss/db/cache_<domain>.ldb

Wiping out a cache has side-effects like removing all cached credentials, so
it shouldn't be done if you are not online and can authenticate with your user against the domain's servers.

I'm also concerned about the case where I'm online and I've just changed my configuration to point to a different identity store with a disjoint set of users. If sssd doesn't flush its caches, will I start seeing a mixture of accounts from my new identity sources and the old ones?

Nalin, that's very much an edge-case, but yes. Until the cache entries time out, they'll still be valid.

If you're changing identity stores, you should absolutely purge the cache (or change domain names).

If you change the identity store it is recommended that you change the domain name.
If you do so at restart a new cache file (ith the new name) will be created and the old one ignored.

Seems we've collected a bit of extra info for this. First draft looks like this:

Considerations Associated with Removing Cache Files
Removing a domain's cache file can have some unexpected side effects. You should be aware of the following before you proceed:

*
  Removing the cache file also removes any cached credentials. Consequently, you should not proceed unless you are online and can authenticate with your user against the domain's servers.
*
  If you are online and change your configuration to reference a different identity provider, SSSD will recognize users from both providers until the cached entries from the original provider time out.
  To avoid this situation, you can either purge the cache or use a different domain name for the new provider (this is the recommended practice). Changing the domain name means that when you restart SSSD it will create a new cache file (with the new name) and the old file will be ignored.

I'm right with point 2, but have to admit to not getting point 1 100%. "auth with your user against the domain's servers"? Does that mean, authenticate using my username against the server (be it native LDAP or LDAP/KRB5 or whatever) before I delete the cache_DOMAINNAME.ldb file? Quick example?

David.

All user data (both identification and cached credentials) are stored in the {{{/var/lib/sss/db/cache_DOMAIN.ldb}}} file. This means that removing the cache will also remove the cached credentials.

So, if you're going to clear the cache, you want to be sure that the next authentication attempt after clearing the cache will be performed online (because offline authentication will fail). That's what is meant by "auth with your user against the domain's servers".

closing - bug - bugzilla bug opened to track ... https://bugzilla.redhat.com/show_bug.cgi?id=609107

resolution: => duplicate
status: assigned => closed

Fields changed

doc: 1 => 0
docupdated: 0 => 1

Fields changed

rhbz: => 0

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1534

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.