Bug 297 - Group mappings behave incorrectly--non-standard OU's
Summary: Group mappings behave incorrectly--non-standard OU's
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: winbind (show other bugs)
Version: 3.0.0preX
Hardware: All Linux
: P3 critical
Target Milestone: 3.0.1
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
Depends on:
Blocks: 709 807
  Show dependency treegraph
Reported: 2003-08-13 18:47 UTC by Geoffrey Coulter
Modified: 2005-11-14 09:26 UTC (History)
2 users (show)

See Also:

strace -v -e read=3,4 -o bad chgrp STBRICE+Groupe_Infocent_Orcq test-dir (84.11 KB, text/plain)
2003-11-17 03:59 UTC, beuserie frederic
no flags Details
strace -v -e read=3,4 -o ok chgrp STBRICE+Groupe_Infocent_Unig test-dir (74.88 KB, text/plain)
2003-11-17 04:00 UTC, beuserie frederic
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Geoffrey Coulter 2003-08-13 18:47:53 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).

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

10000   DOMAIN+Domain Users
10042   DOMAIN+Customer Service Assurance
10008   DOMAIN+Cert Publishers
10019   DOMAIN+Help Desk
10039   DOMAIN+Windows Admins
10046   DOMAIN+Systems
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
Comment 1 Tim Potter 2003-08-14 16:29:40 UTC
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".
Comment 2 Tim Potter 2003-08-14 20:29:48 UTC
cc me
Comment 3 Geoffrey Coulter 2003-08-14 22:00:57 UTC
We are set for Windows 2000 compatibility only ("Everyone" is not a member of
the "Pre-Windows 2000 Compatible Access" group).
Comment 4 Tim Potter 2003-08-15 09:52:05 UTC
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.
Comment 5 Geoffrey Coulter 2003-08-15 14:12:58 UTC
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.
Comment 6 Geoffrey Coulter 2003-08-15 15:02:36 UTC
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.
Comment 7 Gerald (Jerry) Carter (dead mail address) 2003-08-22 09:04:23 UTC
I think the OU's are probably the root casue.  Can you 
provide a level 10 debug log from winbindd?  Thanks.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2003-08-29 08:11:35 UTC
Will try again for RC3.
Comment 9 Gerald (Jerry) Carter (dead mail address) 2003-08-29 08:11:57 UTC
Will try again for RC3.
Comment 10 Gerald (Jerry) Carter (dead mail address) 2003-08-29 08:13:40 UTC
sorry.  didn't mean to close it.
Comment 11 Tim Potter 2003-09-07 20:39:27 UTC
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?
Comment 12 Geoffrey Coulter 2003-09-10 10:30:55 UTC
Tested with both a domain user and a domain admin; no obvious difference.
Comment 13 Geoffrey Coulter 2003-09-16 14:14:37 UTC
Just tested with rc4; situation is unchanged.
Comment 14 beuserie frederic 2003-11-11 07:39:11 UTC
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)
Comment 15 Alexander List 2003-11-14 02:25:33 UTC
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...
Comment 16 beuserie frederic 2003-11-17 03:59:18 UTC
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)
Comment 17 beuserie frederic 2003-11-17 04:00:54 UTC
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)
Comment 18 beuserie frederic 2003-11-17 04:04:33 UTC
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
Comment 19 beuserie frederic 2003-11-17 09:19:26 UTC

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 ?

Comment 20 beuserie frederic 2003-11-25 13:13:36 UTC
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.
Comment 21 Gerald (Jerry) Carter (dead mail address) 2003-11-29 11:17:41 UTC
I can't reproduce this on a glibc 2.2.5 box (rh 7.3).  Looking
at logs from Geoffry
Comment 22 Gerald (Jerry) Carter (dead mail address) 2003-11-29 19:36:59 UTC
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.
Comment 23 Gerald (Jerry) Carter (dead mail address) 2003-11-29 19:42:16 UTC
possibly related to bug 709
Comment 24 Gerald (Jerry) Carter (dead mail address) 2003-12-01 10:09:11 UTC
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.
Comment 25 Gerald (Jerry) Carter (dead mail address) 2005-02-07 09:05:23 UTC
originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.
Comment 26 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:26:31 UTC
database cleanup