wbinbindd fails to update cache (3.0 alpha-20)

[Andrew Bartlett]

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
> they.

A passworded logon refreshes the cache.  The real messy case is SSH
key-based logins.

Andrew Bartlett

-- 
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