[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
