wbinbindd fails to update cache (3.0 alpha-20)
abartlet at samba.org
Wed Oct 9 22:23:00 GMT 2002
jra at dp.samba.org wrote:
> On Wed, Oct 09, 2002 at 03:05:40PM -0700, Jiu Zheng wrote:
> > > > I have a win2k domain controller, and winbindd is running on a FreeBSD box.
> > > > After a user has been authentiacted (using "wbinfo -a username%password"),
> > > > when "Member of" for this user is modified from the domain controller,
> > > > "wbinfo -r username" won't returns the new groups, unless you remove file
> > > > "winbindd_cache.tdb" then restart winbindd. It seems like winbindd
> > > > wouldn't try to refetch the group information after it is cached.
> > > >
> > > > I post this message to samba-bugs at samba.org a few days ago and no reply
> > > > yet. Could anyone look into this please?
> > >
> > > (Assuming Samba 3.0, I'm not quite sure what ended up in 2.2)
> > 2.2.5 does not have such a problem.
> > >
> > > Yes, this behaviour is by design. Perhaps we need to reconsider the
> > > design. The problem is that we wanted to avoid an expencive call to the
> > > DC for every login, particularly as we are given a full list of the
> > > users groups in the reply to the authenticaion request.
> > >
> > The problem is that it seems the old information is kept in cache forever.
> > If we try to avoid expensive calls, can we define a timeout value so we
> > don't it very often?
> It looks like winbindd is not noticing the SAM id change when the DC
> is updated..... I don't think not updating the groups is by design.
The problem is, we don't have an easy way to validate the last change on
this information - there is no sequence number in an info3 reply, and
even if we query the PDC for it immediately, it would invalidate as soon
as somebody changes a password.
We could impose a 'reasonable' time limit on the cached data, but unless
we are using the AD stuff, we run the risk that a user may not get a
'global' group to which they are entitled. This might be a 'deny' group
in an ACL.
(I know this whole things has knobs on, and what's more I knew that when
I committed it originally... It's been on my 'to think harder about'
list for a while).
> The UNIX user is logging off then on again to see the change aren't
A passworded logon refreshes the cache. The real messy case is SSH
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical