I'm using samba from FreeBSD ports. Samba is a member of the Windows AD domain. On fileservers, where membership is determined though nsswitch modules, samba incorrectly shows group membership for most of the users. The following output demonstrates this issue: [emz@taiga:~]# wbinfo -t checking the trust secret for domain SOFTLAB via RPC calls succeeded [emz@taiga:~]# wbinfo -a emz%nevernomore plaintext password authentication succeeded challenge/response password authentication succeeded (notice the groups emz is in:) [emz@taiga:~]# id emz uid=1001(emz) gid=0(wheel) groups=0(wheel),20010(администраторы домена),20074(warez-rw),20078(пользователи vpn),20103(оаит),20149(internet users - proxy2),20151(internet users - proxy1),20153(internet users - spb),20274(internet users - panicbox),20450(internet users - samara),20462(internet users - crystal) but: [emz@taiga:~]# wbinfo -n emz S-1-5-21-3780126066-798514342-2262872178-1128 SID_USER (1) [emz@taiga:~]# wbinfo --user-domgroups S-1-5-21-3780126066-798514342-2262872178-1128 SID_USER S-1-5-21-3780126066-798514342-2262872178-513 S-1-5-21-3780126066-798514342-2262872178-17960 S-1-5-21-3780126066-798514342-2262872178-17956 S-1-5-21-3780126066-798514342-2262872178-9213 S-1-5-21-3780126066-798514342-2262872178-11860 S-1-5-21-3780126066-798514342-2262872178-20184 S-1-5-21-3780126066-798514342-2262872178-13581 S-1-5-21-3780126066-798514342-2262872178-17662 S-1-5-21-3780126066-798514342-2262872178-512 S-1-5-21-3780126066-798514342-2262872178-2629 S-1-5-21-3780126066-798514342-2262872178-15792 S-1-5-21-3780126066-798514342-2262872178-9159 S-1-5-21-3780126066-798514342-2262872178-9161 S-1-5-21-3780126066-798514342-2262872178-5934 S-1-5-21-3780126066-798514342-2262872178-19463 S-1-5-21-3780126066-798514342-2262872178-13813 S-1-5-21-3780126066-798514342-2262872178-19466 S-1-5-21-3780126066-798514342-2262872178-19464 S-1-5-21-3780126066-798514342-2262872178-19465 S-1-5-21-3780126066-798514342-2262872178-13811 S-1-5-21-3780126066-798514342-2262872178-13810 S-1-5-21-3780126066-798514342-2262872178-519 S-1-5-21-3780126066-798514342-2262872178-13980 S-1-5-21-3780126066-798514342-2262872178-13928 S-1-5-21-3780126066-798514342-2262872178-6563 S-1-5-21-3780126066-798514342-2262872178-13812 (you can see the number of the groups emz is in is much bigger) [emz@taiga:~]# wbinfo -r emz 20004 20463 20462 20149 20074 20553 20078 20450 20010 20103 20274 20151 20153 20008 20731 20632 20734 20732 20733 20630 20629 20636 20703 20715 20663 20631 20740 20739 I wrote a simple script expanding SID to names: ./wbgroup.sh emz SOFTLAB+Пользователи домена 2 SOFTLAB+InetUsers 2 SOFTLAB+Internet Users - Crystal 2 SOFTLAB+Internet Users - Proxy2 2 SOFTLAB+Warez-RW 2 SOFTLAB+Пользователи Интернет - Москва 2 SOFTLAB+Пользователи VPN 2 SOFTLAB+Internet Users - Samara 2 SOFTLAB+Администраторы домена 2 SOFTLAB+ОАИТ 2 SOFTLAB+Internet Users - PanicBox 2 SOFTLAB+Internet Users - Proxy1 2 SOFTLAB+Internet Users - SPb 2 SOFTLAB+Администраторы СПб 2 SOFTLAB+Organization Management 2 SOFTLAB+Exchange Public Folder Administrators 2 SOFTLAB+View-Only Organization Management 2 SOFTLAB+Public Folder Management 2 SOFTLAB+Recipient Management 2 SOFTLAB+Exchange Recipient Administrators 2 SOFTLAB+Exchange Organization Administrators 2 SOFTLAB+Администраторы предприятия 2 SOFTLAB+SQL OLAP Admins 2 SOFTLAB+Office UnManaged 2 SOFTLAB+Офис 2 SOFTLAB+Exchange View-Only Administrators 2 SIDs can be converted to gid and vice versa: # for gid in `wbinfo -r emz` ; do wbinfo -G $gid ; done S-1-5-21-3780126066-798514342-2262872178-513 S-1-5-21-3780126066-798514342-2262872178-17960 S-1-5-21-3780126066-798514342-2262872178-17956 S-1-5-21-3780126066-798514342-2262872178-9213 S-1-5-21-3780126066-798514342-2262872178-11860 S-1-5-21-3780126066-798514342-2262872178-20184 S-1-5-21-3780126066-798514342-2262872178-13581 S-1-5-21-3780126066-798514342-2262872178-17662 S-1-5-21-3780126066-798514342-2262872178-512 S-1-5-21-3780126066-798514342-2262872178-2629 S-1-5-21-3780126066-798514342-2262872178-15792 S-1-5-21-3780126066-798514342-2262872178-9159 S-1-5-21-3780126066-798514342-2262872178-9161 S-1-5-21-3780126066-798514342-2262872178-5934 S-1-5-21-3780126066-798514342-2262872178-19463 S-1-5-21-3780126066-798514342-2262872178-13813 S-1-5-21-3780126066-798514342-2262872178-19466 S-1-5-21-3780126066-798514342-2262872178-19464 S-1-5-21-3780126066-798514342-2262872178-19465 S-1-5-21-3780126066-798514342-2262872178-13811 S-1-5-21-3780126066-798514342-2262872178-13810 S-1-5-21-3780126066-798514342-2262872178-519 S-1-5-21-3780126066-798514342-2262872178-13980 S-1-5-21-3780126066-798514342-2262872178-13928 S-1-5-21-3780126066-798514342-2262872178-6563 S-1-5-21-3780126066-798514342-2262872178-13812 S-1-5-32-545 S-1-5-32-544 # for sid in `wbinfo --user-domgroups S-1-5-21-3780126066-798514342-2262872178-1128` ; do wbinfo -Y $sid ; done 20004 20463 20462 20149 20074 20553 20078 20450 20010 20103 20274 20151 20153 20008 20731 20632 20734 20732 20733 20630 20629 20636 20703 20715 20663 20631 But still id shows incorrect membership: some groups are missing. This bug is also present on 3.5.11; I have no information about earlier 3.5.x versions. However, I have ols 3.0.x sambas in the same domain and on FreeBSD, so I can say 3.0.36 misses only two groups emz is in. This problem isn't local to one user, almost every domain user misses groups in it's id output.
Yeah :(, I noticed I also reported my password, had to change it on 30 hosts :/.
Please upload full debug level 10 logs of winbind doing all this. This is log.winbindd and log.wb-*.
Did all of that again. Here are attached logs along with my config. Here is the output: [emz@taiga:log/samba]# /usr/local/etc/rc.d/samba stop Stopping winbindd. Waiting for PIDS: 49520. Stopping smbd. Waiting for PIDS: 49517. Stopping nmbd. Waiting for PIDS: 49513. (cleaned up old logs) [emz@taiga:log/samba]# /usr/local/etc/rc.d/samba stop Stopping winbindd. Waiting for PIDS: 31572. Stopping smbd. Waiting for PIDS: 31569, 31569. Stopping nmbd. Waiting for PIDS: 31565. (cleaned up old logs) [emz@taiga:log/samba]# /usr/local/etc/rc.d/samba start Removing stale Samba tdb files: ....... done Starting nmbd. Starting smbd. Starting winbindd. [emz@taiga:log/samba]# [emz@taiga:log/samba]# [emz@taiga:log/samba]# wbinfo -t checking the trust secret for domain SOFTLAB via RPC calls succeeded [emz@taiga:log/samba]# wbinfo -a emz%XXXXXXXXXXXX plaintext password authentication succeeded challenge/response password authentication succeeded [emz@taiga:log/samba]# [emz@taiga:log/samba]# [emz@taiga:log/samba]# id emz uid=1001(emz) gid=0(wheel) groups=0(wheel),20010(администраторы домена),20074(warez-rw),20078(пользователи vpn),20103(оаит),20149(internet users - proxy2),20151(internet users - proxy1),20153(internet users - spb),20274(internet users - panicbox),20450(internet users - samara),20462(internet users - crystal) [emz@taiga:log/samba]# wbinfo --user-domgroups S-1-5-21-3780126066-798514342-2262872178-1128 S-1-5-21-3780126066-798514342-2262872178-513 S-1-5-21-3780126066-798514342-2262872178-17960 S-1-5-21-3780126066-798514342-2262872178-17956 S-1-5-21-3780126066-798514342-2262872178-9213 S-1-5-21-3780126066-798514342-2262872178-11860 S-1-5-21-3780126066-798514342-2262872178-20184 S-1-5-21-3780126066-798514342-2262872178-13581 S-1-5-21-3780126066-798514342-2262872178-17662 S-1-5-21-3780126066-798514342-2262872178-512 S-1-5-21-3780126066-798514342-2262872178-2629 S-1-5-21-3780126066-798514342-2262872178-15792 S-1-5-21-3780126066-798514342-2262872178-9159 S-1-5-21-3780126066-798514342-2262872178-9161 S-1-5-21-3780126066-798514342-2262872178-5934 S-1-5-21-3780126066-798514342-2262872178-19463 S-1-5-21-3780126066-798514342-2262872178-13813 S-1-5-21-3780126066-798514342-2262872178-19466 S-1-5-21-3780126066-798514342-2262872178-19464 S-1-5-21-3780126066-798514342-2262872178-19465 S-1-5-21-3780126066-798514342-2262872178-13811 S-1-5-21-3780126066-798514342-2262872178-13810 S-1-5-21-3780126066-798514342-2262872178-519 S-1-5-21-3780126066-798514342-2262872178-13980 S-1-5-21-3780126066-798514342-2262872178-13928 S-1-5-21-3780126066-798514342-2262872178-6563 S-1-5-21-3780126066-798514342-2262872178-13812 [emz@taiga:log/samba]# wbinfo -r emz 20004 20463 20462 20149 20074 20553 20078 20450 20010 20103 20274 20151 20153 20008 20731 20632 20734 20732 20733 20630 20629 20636 20703 20715 20663 20631 20740 20739 [emz@taiga:log/samba]# cd /home/emz [emz@taiga:~]# ./wbgroup.sh emz SOFTLAB+Пользователи домена 2 SOFTLAB+InetUsers 2 SOFTLAB+Internet Users - Crystal 2 SOFTLAB+Internet Users - Proxy2 2 SOFTLAB+Warez-RW 2 SOFTLAB+Пользователи Интернет - Москва 2 SOFTLAB+Пользователи VPN 2 SOFTLAB+Internet Users - Samara 2 SOFTLAB+Администраторы домена 2 SOFTLAB+ОАИТ 2 SOFTLAB+Internet Users - PanicBox 2 SOFTLAB+Internet Users - Proxy1 2 SOFTLAB+Internet Users - SPb 2 SOFTLAB+Администраторы СПб 2 SOFTLAB+Organization Management 2 SOFTLAB+Exchange Public Folder Administrators 2 SOFTLAB+View-Only Organization Management 2 SOFTLAB+Public Folder Management 2 SOFTLAB+Recipient Management 2 SOFTLAB+Exchange Recipient Administrators 2 SOFTLAB+Exchange Organization Administrators 2 SOFTLAB+Администраторы предприятия 2 SOFTLAB+SQL OLAP Admins 2 SOFTLAB+Office UnManaged 2 SOFTLAB+Офис 2 SOFTLAB+Exchange View-Only Administrators 2 [emz@taiga:~]# for gid in `wbinfo -r emz` ; do wbinfo -G $gid ; done for: Команда не найдена. do: Команда не найдена. done: Команда не найдена. [emz@taiga:~]# sh # set -E # for gid in `wbinfo -r emz` ; do wbinfo -G $gid ; done S-1-5-21-3780126066-798514342-2262872178-513 S-1-5-21-3780126066-798514342-2262872178-17960 S-1-5-21-3780126066-798514342-2262872178-17956 S-1-5-21-3780126066-798514342-2262872178-9213 S-1-5-21-3780126066-798514342-2262872178-11860 S-1-5-21-3780126066-798514342-2262872178-20184 S-1-5-21-3780126066-798514342-2262872178-13581 S-1-5-21-3780126066-798514342-2262872178-17662 S-1-5-21-3780126066-798514342-2262872178-512 S-1-5-21-3780126066-798514342-2262872178-2629 S-1-5-21-3780126066-798514342-2262872178-15792 S-1-5-21-3780126066-798514342-2262872178-9159 S-1-5-21-3780126066-798514342-2262872178-9161 S-1-5-21-3780126066-798514342-2262872178-5934 S-1-5-21-3780126066-798514342-2262872178-19463 S-1-5-21-3780126066-798514342-2262872178-13813 S-1-5-21-3780126066-798514342-2262872178-19466 S-1-5-21-3780126066-798514342-2262872178-19464 S-1-5-21-3780126066-798514342-2262872178-19465 S-1-5-21-3780126066-798514342-2262872178-13811 S-1-5-21-3780126066-798514342-2262872178-13810 S-1-5-21-3780126066-798514342-2262872178-519 S-1-5-21-3780126066-798514342-2262872178-13980 S-1-5-21-3780126066-798514342-2262872178-13928 S-1-5-21-3780126066-798514342-2262872178-6563 S-1-5-21-3780126066-798514342-2262872178-13812 S-1-5-32-545 S-1-5-32-544 # for sid in `wbinfo --user-domgroups S-1-5-21-3780126066-798514342-2262872178-1128` ; do wbinfo -Y $sid ; done 20004 20463 20462 20149 20074 20553 20078 20450 20010 20103 20274 20151 20153 20008 20731 20632 20734 20732 20733 20630 20629 20636 20703 20715 20663 20631 #
Created attachment 7290 [details] tar gzipped archive of the logs requested
You seem to have "max log size = 100". This cuts off most of the log files. This is not sufficient information, sorry. "max log size = 0" is required for full log files.
Created attachment 7293 [details] gzipped tar archive resumbitted, recaptured with max log size=0 My mistake. I'm sorry for the time spant to examine useless logs. Here are the recaptured with the max log size = 0 logs.
Ok, it seems "id emz" still enumerates groups to find the group memberships of user "emz". Can you try to do a "su - emz" and do an "id" then? Maybe that behaves differently. Thanks, Volker
Actually, no (did both id under root and under user emz): [emz@taiga:~]> id uid=1001(emz) gid=0(wheel) groups=0(wheel),20010(администраторы домена),20074(warez-rw),20078(пользователи vpn),20103(оаит),20149(internet users - proxy2),20151(internet users - proxy1),20153(internet users - spb),20274(internet users - panicbox),20450(internet users - samara),20462(internet users - crystal) [emz@taiga:~]> su -m Password: [emz@taiga:~]# id emz uid=1001(emz) gid=0(wheel) groups=0(wheel),20010(администраторы домена),20074(warez-rw),20078(пользователи vpn),20103(оаит),20149(internet users - proxy2),20151(internet users - proxy1),20153(internet users - spb),20274(internet users - panicbox),20450(internet users - samara),20462(internet users - crystal)
Ok. Then this is going to be a larger change. For all groups that we enumerate we seem to need to scan the whole netsamlogon cache for entries. This sucks.
Another question: Does this problem also affect smbd? It should not, you should be able to benefit from permissions from all group memberships.
Actually it does, and this is the actual reason I'm reporting this, not 'id' of course. This came up when I was localizing a permissions bug on a file server, and it's sad, but when a directory allows access for a group B the user A is in, the user A cannot access the directory when the B group is missing from his 'id' output.
Ok, sorry. I had thought that smbd does not go through nsswitch to determine the user's group memberships. You must have patches on top of Samba that do this then. Where did you get your Samba version from? Can we see those patches please? Alternatively, can you send a debug level 10 log of smbd of such a denied access when it should have been allowed? Please do not forget to re-enable the "max log size = 0" so that we get the full logs, not the cut ones. Please send those together with the winbind log files taken at the same moment? Sorry to send you through so many loops, but I had gathered from your initial report that you actually need precise output of "id emz", now to see that your problem seems to be more related to smbd. I was unfortunately not able to see that from your initial entry here.
Nothing to be sorry about, my mistake again. I'm just glad to see such interest in the bug. But. The directory on production was fully reorganized since I saw the bug, and I just cannot reproduce it on my test servers (and actually on production too), because you're right and it seems like smbd isn't affected by the missing groups (thus, I don't know - was it my eyes when I was localizing the reason or something else). Since I cannot reproduce the bug, let's stick with the id issue at this time, though just and id issue isn't that serious. I'll let you know here if I will get it again. For now, I guess, FreeBSD port patches aren't relevent ?
Problem was automagically resolved by extending gid/uid/mapping delta from 10K to 70K. The range was increased while invetigating another problem - multiple "User is invalid on this system" messages for valid domain accounts. Is is possible that winbind warning/error output lacks messages about inability to map uid/gid due to insufficient mapping range ?
Skip last comment, I mixed up the servers. :/
reporter says, problem disapeared :)