This is a bug reported a long time ago in Debian, but still reproducible with 3.2.8. Initial report (back with 3.0.24): I have setup our squid proxy to authenticate Domain Accounts defined on our ADS, which is working perfect. To differentiate the access permissions of our users I use wbinfo_group.pl which relies on "wbinfo -r USERNAME" The problem is that "wbinfo -r USERNAME" does not show the change of group membership of some (but not all) older accounts. "getent group" (via libnss_winbind.so.2) correctly shows the tested changes. The problem does not occur with newly created accounts. Our ADS run "Windows Server 2003 SP2" and "Windows Server 2003 R2 SP2" I can reproduce the problem with the following backported winbind versions on the same host running etch: 3.0.27a-1, 3.0.26a-1, 3.2.0~pre1-1 and the version from sarge 3.0.14a-3sarge4. But I have only done very few tests with them. The following examples are generated in a small test domain. An level 10 debug log from winbindd corresponding to the following commands is attached. First Example: -------------- "wbinfo -r" fails to recognise the removal of user "karen" from group "inetuser" 1) # wbinfo -r karen 3000 3018 3019 3001 2) # getent group inetuser inetuser:x:3000:kids,karen,ab 3) Removal of "karen" from group "inetuser" at one of our two ADS 4) # wbinfo -r karen 3000 3018 3019 3001 5) # getent group inetuser inetuser:x:3000:kids,ab Second Example: --------------- "wbinfo -r" fails to recognise the addition of user "guru" to group "inetuser" 1) # wbinfo -r guru 3018 3036 3011 3019 3009 3026 3025 3021 3024 2) # getent group inetuser inetuser:x:3000:kids,karen,ab 3) Add "guru" to group "inetuser" on ADS 4) # wbinfo -r guru 3018 3036 3011 3019 3009 3026 3025 3021 3024 5) # getent group inetuser inetuser:x:3000:kids,karen,ab,guru Third Example: --------------- "wbinfo -r" successfully recognises the addition of user "usera" to group "inetuser" 1) # wbinfo -r usera 3001 2) # getent group inetuser inetuser:x:3000:kids,karen,ab 3) Add "usera" to group "inetuser" on ADS 4) # wbinfo -r usera 3001 3000 5) # getent group inetuser inetuser:x:3000:kids,usera,karen,ab #################################### Configs #################################### # cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5.log [libdefaults] default_realm = DOMAIN [realms] DATASYSTEME = { kdc = ads1.domain kdc = ads2.domain admin_server = ads1.domain } [domain_realm] .domain = DOMAIN ------------------------------------- # cat /etc/nsswitch.conf passwd: files winbind group: files winbind shadow: files hosts: files dns wins networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis ------------------------------------- cat /etc/samba/smb.conf [global] realm = DOMAIN workgroup = DOMAIN netbios name = HOSTNAME server string = "Hostname Proxy Server" security = ADS passdb backend = tdbsam encrypt passwords = true username level = 2 hosts allow = 192.168.xx. 192.168.yy. 127. winbind cache time = 1 winbind enum users = Yes winbind enum groups = Yes idmap uid = 2000-2999 idmap gid = 3000-3999 template homedir = /home/%D\%U template shell = /bin/false obey pam restrictions = yes winbind use default domain = Yes name resolve order = wins host bcast wins server = 192.168.yy.30 dns proxy = no panic action = /usr/share/samba/panic-action %d debug level = 10 debug timestamp = yes log file = /var/log/samba/%m.log max log size = 0 local master = no os level = 60 wins support = no socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 smb ports = 139
Created attachment 3936 [details] Level 10 debug log (with samba 3.0.24)
Two days ago, our users tried again with 3.2.8 packages provided by the Debian packagers: Hello Christian, sorry for the delay. I have testes again with winbind 3.2.3-0ms0 a backported version of 2:3.2.3-1 and with 3.2.8-1~unoff40+1 from http://pkg-samba.alioth.debian.org The problem is still existing. I see no change in behaviour. The tests was done with the following cache time parameters: # testparm -vsf | grep "cache time" lpq cache time = 30 name cache timeout = 660 printcap cache time = 750 idmap cache time = 10 idmap negative cache time = 10 winbind cache time = 1 dfree cache time = 0 ================== Winbind 2:3.2.3-1 ================== 1. Example -------------- "wbinfo -r" fails to recognise the removal of user "karen" from group "inetuser" 1) # wbinfo -r karen 3011 3005 3006 3001 3008 2) # getent group inetuser inetuser:x:3001:DOMAIN\karen,DOMAIN\lene 3) Removal of "karen" from group "inetuser" at one of our two ADS 4) # wbinfo -r karen 3011 3005 3006 3001 !!! 3008 5) # getent group inetuser inetuser:x:3001:DOMAIN\lene 2. Example ------------- "wbinfo -r" fails to recognise the addition of user "guru" to group "inetuser" 1) #date; wbinfo -r guru; getent group inetuser Do 12. Feb 21:07:06 CET 2009 3002 3000 3005 3004 3006 3003 3007 3008 3009 inetuser:x:3001:DOMAIN\karen,DOMAIN\lene 2) 21:07:20: Addition of "guru" to group "inetuser" at one of our two ADS 3) #date; wbinfo -r guru; getent group inetuser Do 12. Feb 21:07:25 CET 2009 3002 3000 3005 3004 3006 3003 3007 3008 3009 inetuser:x:3001:DOMAIN\guru,DOMAIN\karen,DOMAIN\lene 4) # date; wbinfo -r guru; getent group inetuser Do 12. Feb 21:12:53 CET 2009 3002 3000 3005 3004 3006 3003 3007 3008 3009 inetuser:x:3001:DOMAIN\guru,DOMAIN\karen,DOMAIN\lene 3. Example: --------------- "wbinfo -r" successfully recognises the addition of user "horst" to group "inetuser" 1) upuaut:/home/guru# wbinfo -r horst 3011 2) # getent group inetuser inetuser:x:3001:DOMAIN\karen,DOMAIN\lene 3) Add "horst" to group "inetuser" on ADS 4) # wbinfo -r horst 3011 3001 5) # getent group inetuser inetuser:x:3001:DOMAIN\horst,DOMAIN\karen,DOMAIN\lene 4. Example: -------------- "wbinfo -r" successfully recognises the removal of user "horst" from group "inetuser" 1) Remove "horst" from group "inetuser" on ADS 2) # wbinfo -r horst 3011 3) # getent group inetuser inetuser:x:3001:DOMAIN\karen,DOMAIN\lene ================== Winbind 3.2.8-1~unoff40+1 ================== 1. Example -------------- "wbinfo -r" fails to recognise the removal of user "karen" from group "inetuser" 1) # date; wbinfo -r karen; getent group inetuser Do 12. Feb 21:28:55 CET 2009 3011 3005 3006 3001 3008 inetuser:x:3001:karen,lene 2) 21:29:20: Removal of "karen" from group "inetuser" at one of our two ADS 4) # date; wbinfo -r karen; getent group inetuser Do 12. Feb 21:30:46 CET 2009 3011 3005 3006 3001 3008 inetuser:x:3001:lene 5) # date; wbinfo -r karen; getent group inetuser Do 12. Feb 21:32:40 CET 2009 3011 3005 3006 3001 3008 inetuser:x:3001:lene 2. Example ------------- "wbinfo -r" fails to recognise the addition of user "guru" to group "inetuser" 1) # date; wbinfo -r guru; getent group inetuser Do 12. Feb 21:36:15 CET 2009 3002 3000 3005 3004 3006 3003 3007 3008 3009 inetuser:x:3001:karen,lene 2) 21:36:40: Addition of "guru" to group "inetuser" at one of our two ADS 3) # date; wbinfo -r guru; getent group inetuser Do 12. Feb 21:36:54 CET 2009 3002 3000 3005 3004 3006 3003 3007 3008 3009 inetuser:x:3001:guru,karen,lene 4) # date; wbinfo -r guru; echo; getent group inetuser Do 12. Feb 21:45:35 CET 2009 3002 3000 3005 3004 3006 3003 3007 3008 3009 inetuser:x:3001:guru,karen,lene 3. Example: --------------- "wbinfo -r" successfully recognises the addition of user "horst" to group "inetuser" 1) #date; wbinfo -r horst; getent group inetuser Do 12. Feb 21:46:40 CET 2009 3011 inetuser:x:3001:karen,lene 3) 21:47:46: Add "horst" to group "inetuser" on ADS 4) # date; wbinfo -r horst; getent group inetuser Do 12. Feb 21:48:21 CET 2009 3011 3001 inetuser:x:3001:horst,karen,lene
The safest bet should be to use wbinfo -a domain\\user%password between the other wbinfo calls. This is the operation that *must* work. If that still fails to update the information correctly, please upload debug level 10 logs, we will definitely fix that. For everything else (i.e. wbinfo -r without having logged in), it might or might not work 100% reliably, because we cache quite a bit of that information. wbinfo -a will overwrite the cache always. Volker
Did you re-try after wbinfo -a domain\\user%password? Does that work for you?
I just forwarded Volker's comment and suggestion to our user
Closing out bug report. Please re-open if it's still an issue. Thanks for reporting!