Dear Maintainer,

I've discovered, after a few days of troubleshooting, that sssd's caching is
doing strange things.

With a clean cache (via sss_cache -E), the first query (getent, an ssh login,
etc), things work.  Subsequent queries fail to return unixHomeDirectory and
probably other things, dumping the user at /.

I've confirmed that sssd appears to do this (amongst other attributes):

[sssd[be[some.domain]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory]

And then does:

[sssd[be[some.domain]]] [sysdb_remove_attrs] (0x2000): Removing attribute [homeDirectory] from [username]

It then commits this to its cache -- ie. it is entirely missing.

Then, further queries consult the cache, get a hit from it, but don't re-query
for these attributes, returning empty/null.

I've confired the cache is empty using ldbsearch, and seeing sssd log this:

[sssd[be[some.domain]]] [krb5_auth_send] (0x0100): Home directory for user [username] not known.

I've worked around this by setting entry_cache_timeout = 0 and the issue is
"fixed".

Hi, I've since discovered overnight that this is related to global
catalog, and the ad_enable_gc setting.

I was not replicating the appropriate attributes to the GC. Setting the
above correctly appears to have fixed things.

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1194345
https://fedorahosted.org/sssd/wiki/Troubleshooting - this text specifically:

The POSIX attributes disappear randomly after login
SSSD looks the user's group membership in the Global Catalog to make
sure even the cross-domain memberships are taken into account. Chances
are the POSIX attributes are not replicated to the Global Catalog. You
can disable the Global catalog lookups by disabling the ad_enable_gc
option, but you'll lose cross-domain memberships. Alternatively, modify
the AD schema to replicate the POSIX attribute to the Global Catalog.

So, perhaps some more specific documentation around this in the README,
and upstream, might be a good idea.