The Samba-Bugzilla – Bug 297
Group mappings behave incorrectly--non-standard OU's
Last modified: 2005-11-14 09:26:31 UTC
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
lookup_usergroups: No supp groups found
and wbinfo -r doesn't even return "Domain Users" (the primary group for
virtually all users).
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
10000 DOMAIN+Domain Users
10042 DOMAIN+Customer Service Assurance
10008 DOMAIN+Cert Publishers
10019 DOMAIN+Help Desk
10039 DOMAIN+Windows Admins
10005 DOMAIN+Vendor Access
10000 DOMAIN+Domain Users
10000 DOMAIN+Domain Users
10010 DOMAIN+Domain Admins
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
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".
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
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
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
after getting the errno from getgrnam() libc call in chgrp.c (from gnu-coreutils
[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 ?
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:
: getgrgid 10057
idmap_gid_to_sid: gid = 
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.