Bug 8741 - id reports incorrect group membership
id reports incorrect group membership
Status: NEW
Product: Samba 3.5
Classification: Unclassified
Component: User & Group Accounts
3.5.12
All FreeBSD
: P5 major
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-03 09:58 UTC by drookie
Modified: 2015-07-31 09:01 UTC (History)
1 user (show)

See Also:


Attachments
tar gzipped archive of the logs requested (34.94 KB, application/x-gzip)
2012-02-03 14:01 UTC, drookie
no flags Details
gzipped tar archive resumbitted, recaptured with max log size=0 (2.07 MB, application/x-gzip)
2012-02-05 10:05 UTC, drookie
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description drookie 2012-02-03 09:58:07 UTC
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.
Comment 1 drookie 2012-02-03 10:11:14 UTC
Yeah :(,  I noticed I also reported my password, had to change it on 30 hosts :/.
Comment 2 Volker Lendecke 2012-02-03 13:14:21 UTC
Please upload full debug level 10 logs of winbind doing all this. This is log.winbindd and log.wb-*.
Comment 3 drookie 2012-02-03 13:58:51 UTC
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
#
Comment 4 drookie 2012-02-03 14:01:05 UTC
Created attachment 7290 [details]
tar gzipped archive of the logs requested
Comment 5 Volker Lendecke 2012-02-04 08:08:24 UTC
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.
Comment 6 drookie 2012-02-05 10:05:43 UTC
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.
Comment 7 Volker Lendecke 2012-02-06 07:03:20 UTC
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
Comment 8 drookie 2012-02-06 07:08:04 UTC
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)
Comment 9 Volker Lendecke 2012-02-06 07:09:56 UTC
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.
Comment 10 Volker Lendecke 2012-02-06 07:11:43 UTC
Another question: Does this problem also affect smbd? It should not, you should be able to benefit from permissions from all group memberships.
Comment 11 drookie 2012-02-06 07:26:05 UTC
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.
Comment 12 Volker Lendecke 2012-02-06 07:32:10 UTC
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.
Comment 13 drookie 2012-02-06 08:48:37 UTC
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 ?
Comment 14 drookie 2012-02-13 04:43:34 UTC
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 ?
Comment 15 drookie 2012-02-13 04:45:52 UTC
Skip last comment, I mixed up the servers. :/