Regarding retrieving user group membership using wbinfo.

[Volker Lendecke]

Hi!

Can you fix the entry by a successful wbinfo -a?

A winbind debug level 10 log will show what winbind puts
into the netsamlogon cache. You can bump up the debuglevel
temporarily with

smbcontrol winbindd debug 10

Yes, it's the logon_ex routine that will update the info3
structure. In the debug level 10 output you will see it
decrypted and unmarshalled.

With best regards,

Volker Lendecke

On Thu, Jun 05, 2014 at 07:56:33PM +0530, Hemanth Thummala wrote:
> Yes Volker. You are correct. netsamlogon_cache is getting updated on
> successful user login. And from the code I could see that a DCE-RPC call is
> made to get the group membership list and update netsamlogon_cache.tdb file.
> 
> When I remove the cache entries related to this specific user(SID), listing
> is proper. Based on this I suspect that netsamlogon_cache is updated with
> incorrect data using the DCE-RPC response. I could not get what exactly the
> request and response contains as they are encrypted. But from code, it
> is rpccli_netlogon_sam_network_logon_ex() routine which is responsible for
> retrieving the info3 structure which includes the group membership
> information.
> 
> And yes I forgot to mention that it is Samba 3.6.12+ stack that we are
> using here. Thanks for that Richard.
> 
> Thanks,
> Hemanth.
> 
> 
> 
> 
> On Thu, Jun 5, 2014 at 7:44 PM, 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?
> >
> > With best regards,
> >
> > Volker Lendecke
> >
> > --
> > SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> > phone: +49-551-370000-0, fax: +49-551-370000-9
> > AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> > http://www.sernet.de, mailto:kontakt at sernet.de
> >

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de