Regarding retrieving user group membership using wbinfo.

[Hemanth Thummala]

Hi,

We are experiencing a strange problem with one of our customer setups
relating to user group memberships. Customer has multi-site AD setup in
which our boxes are deployed in multiple sites.
In one particular site, we are seeing a difference in group membership
details with a user(wbinfo -r <user>). Able to retrieve only few groups
than expected. Whereas other sites we are able to get the correct results.

Initially we thought its AD replication problem, but even after
forcing(blocked the traffic with site-local DC) our boxes to contact PDC
did not help.

Then I have removed the cache entries for this user from both
winbindd_cache.tdb and netsamlogon_cache.tdb. Then it started showing the
correct entries. But after 5 to 6 hours this problem reappears. After
cleaning up cache entries in both tdb files, problem will go away.

>From the code walk-through and debug level logs this is what I understood.
1. Winbindd receives request GETGROUPS from the client.
2. Initially it will lookup winbindd_cache.tdb and see if there is a
"UG/sid" entry for the user. it will return the information in cache if
entry is not expired (I think expiry time is 5 mins).
3. If the entry in winbindd_cache.tdb is expired, then lookup_usergroups()
request will be made.
4. Before contacting the DC to fetch the groups, will search for the user
SID in netsamlogon_cache.tdb. If the entry is found, that information will
be returned.
5. If the entry is not found in netsamlogon_cache.tdb, then DCE-RPC request
will be made using cached kerberos credentials.

I came to know that there is no expiry time for the cached entries in
netsamlogon_cache.tdb. I have seen the expiry time calculation is commented
out in netsamlogon_cache_get().

But I am not really sure why the cache entry in netsamlogon_cache.tdb() is
updated with wrong data due to which the problem is reappearing.

Can some one validate my understanding and throw some light on what could
be the root cause for this problem.

Thanks,
Hemanth.