Quick status: wbinfo -u and wbinfo -g both return reasonable results. getent group, however, does not reflect 99% of secondary group memberships. wbinfo -r returns group memberships for about 5% of users; memberships reported include "GID"s that have no correspondence to entries in getent group. The other users are reported as belonging to no group. I'm trying to convert an existing W2K environment (130 user accounts) to use Samba for storage, but I need to be able to distinguish user groups, and I can't, so the deployment is on hold. We have two ADS domains: a parent (with very little in it), and a child, which the Samba server has been enrolled in. Our AD tree has a branch for our users with containers (and sub-containers) holding user and group objects. All users belong to at least two groups, some to upwards of seven or eight. There are 52 total groups (according to wbinfo -g). With debugging set to level 10, users participating in multiple groups get nsswitch/winbindd_ads.c:lookup_usergroups_alt(521) lookup_usergroups: No supp groups found and wbinfo -r doesn't even return "Domain Users" (the primary group for virtually all users). I've run for user in `getent passwd |egrep '^DOMAIN'|perl -ne '/^([^:]+):/m; print $1 . "\n";'`; do echo $user ; wbinfo -r $user|perl -ne 'chomp; print $_ . "\t" . getgrgid($_) . "\n";'; done and get back output like DOMAIN+user1 10000 DOMAIN+Domain Users 10052 10053 10054 10042 DOMAIN+Customer Service Assurance 10008 DOMAIN+Cert Publishers 10019 DOMAIN+Help Desk 10039 DOMAIN+Windows Admins 10046 DOMAIN+Systems DOMAIN+user2 DOMAIN+user3 DOMAIN+user4 DOMAIN+user5 10005 DOMAIN+Vendor Access 10000 DOMAIN+Domain Users DOMAIN+user6 DOMAIN+user7 DOMAIN+user8 DOMAIN+user9 DOMAIN+user10 DOMAIN+user11 10000 DOMAIN+Domain Users 10054 10055 10012 10057 10010 DOMAIN+Domain Admins etc. We don't see any patterns to the users who return values and those who don't. Further confusing the situation is that user11, for example, shows multiple groups in wbinfo -r but only one group shows up in getent passwd (expected) and NONE in getent group (not expected). The smb.conf [global] section is [global] realm = X.Y.Z security = ADS encrypt passwords = yes winbind separator = + idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = <USERDIR> template shell = /bin/bash log level = 10 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
Do you have "permissions compatible with windows 2000 servers only" on any of your domain controllers? You can check this by seeing if the Everyone group is not present in the builtin group "Pre-Windows 2000 Compatible Access".
cc me
We are set for Windows 2000 compatibility only ("Everyone" is not a member of the "Pre-Windows 2000 Compatible Access" group).
I think this is the problem. Due to active directory permissions, an anonymous user cannot enumerate all group members. If you add Everyone to the pre-Windows 2000 group does the group mapping work as expected? There may be some progress with this soon, as we are doing more kerberos stuff and I expect winbindd will be able to use this to query more information without having to resort to allowing anonymous access. There is a workaround though. Try the --set-auth-user option to wbinfo which tells winbindd to use a username and password when retrieving information from a DC rather than connecting anonymously.
I tried using "--set-auth-user" but am seeing the same result. I verified the user with "--get-auth-user", confirmed the user could authenticate using wbinfo --authenticate, and stopped and restarted winbindd, but am getting the same results. I started to type "inconsistent results" but that is misleading: I get the same results every time; they just aren't correct.
Something that may make a difference that might not be clear from my original post: the ADS containers in which we store users and computers are not "Users" and "Computers" respectively.
I think the OU's are probably the root casue. Can you provide a level 10 debug log from winbindd? Thanks.
Will try again for RC3.
sorry. didn't mean to close it.
Just a thought - if you do the --set-auth-user but use the domain administrator instead of (presumably) a normal user does that change the results?
Tested with both a domain user and a domain admin; no obvious difference.
Just tested with rc4; situation is unchanged.
i've the same with a nt4 sp3 pdc. some groups dont show their members with getent/... BUT they show up through a wbinfo -g. that's works for many foreign groups but some *always* fails -d 10 for winbind show me that winbind *receive* the user into the groups and send them to nss* through the pipe. (the same behavior was with 2.2.8, now samba-latest from yesterday)
Sent level 10 debug logs to Jerry on 2003-11-04, I'm observing similar problems. It seems however that changed Group information from AD propagates to Samba after a while. Really scary. We're also using non-standard OUs. Will try to continue investigating this...
Created attachment 257 [details] strace -v -e read=3,4 -o bad chgrp STBRICE+Groupe_Infocent_Orcq test-dir this chgrp always fail (the group exist with wbinfo -g)
Created attachment 258 [details] strace -v -e read=3,4 -o ok chgrp STBRICE+Groupe_Infocent_Unig test-dir this chgrp always succed (the group exist with wbinfo -g)
i can send you level 10 Debug but i dont think its related anymore with winbind daemon. the 2 strace output show that the groups members are listed correctly but the chgrp fail. libnss related ? at the end of strace output you can see the difference between a working group and a no working one. hopes that will be helpfull
update: after getting the errno from getgrnam() libc call in chgrp.c (from gnu-coreutils packages): [root@datawh coreutils-5.0]# src/chgrp STBRICE+Groupe_Infocent_Orcq id.c >>> Numerical result out of range <<< src/chgrp: invalid group name `STBRICE+Groupe_Infocent_Orcq' seems more a libc problem, or some hardcoded limit for the size of the reply/number of group members ? frederic.
all the problems seems related to glibc-2.2.x which have serious group handling bugs. upgrade to glibc-2.3.x and it should work better with getent.
I can't reproduce this on a glibc 2.2.5 box (rh 7.3). Looking at logs from Geoffry
I think this boils down to membership in built-in groups: [11264]: getgrgid 10057 idmap_gid_to_sid: gid = [10057] ... internal_get_id_from_sid: ID_GROUPID fetching record S-1-5-32-546 -> GID 10057 Can't find domain from sid Alexander's bug (mentioned in comment 15) maybe something else. I'll look at the logs next.
possibly related to bug 709
According to the logs that I have, the problem is the resolving of built in group sids which is not performed by winbindd but rather by the 'net groupmap' feature in samba. If you fill in the various map entries (see the HOWTO collection for details on this), this should be ok. I'm closing this one now. I will bring this up on the tech mailing list though because I'm undecided on who should resolve built in SIDs. A change in the current behavior could cause problems with exists servers though.
originally reported against one of the 3.0.0rc[1-4] releases. Cleaning up non-production versions.
database cleanup