Regarding retrieving user group membership using wbinfo.

[Hemanth Thummala]

I can do that. Also from the experiments I did so far, netsamlogon_cache is
updated on every successful login. And customer is actually using Kerberos
for these machines. It is evident from the packet captures we got.

Thanks,
Hemanth.


On Thu, Jun 5, 2014 at 7:56 PM, Richard Sharpe <realrichardsharpe at gmail.com>
wrote:

> On Thu, Jun 5, 2014 at 7:14 AM, Volker Lendecke
> <Volker.Lendecke at sernet.de> wrote:
> > On Thu, Jun 05, 2014 at 06:43:59AM -0700, Richard Sharpe wrote:
> >> On Thu, Jun 5, 2014 at 3:41 AM, Hemanth Thummala
> >> <hemanth.thummala at gmail.com> wrote:
> >> > 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.
> >>
> >> A vital piece of info is that this is Samba 3.6.12+ you are talking
> >> about. The same problem might not exist in the latest sources.
> >>
> >> > 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.
> >
> > If all goes well then the netsamlogon_cache is only written
> > after a successful login. This can happen when a client
> > authenticates via netlogon or presents a valid kerberos
> > ticket with a PAC. In the bad case, can you find out where
> > the bad information comes from? Is it really the netsamlogon
> > cache that is faulty?
>
> Modify the code that writes the cache entry to log stuff at level 0,
> then see if the cache is being modified after the entry is first
> written.
>
> If I am not mistaken this customer does not use Kerberos either for
> those machines.
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
>