Bug 4047 - post~3.0.22 group-membership handling undesirable
post~3.0.22 group-membership handling undesirable
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2006-08-24 13:52 UTC by Buck Huppmann
Modified: 2009-04-04 08:03 UTC (History)
1 user (show)

See Also:

PR-body-referenced patch (2.71 KB, patch)
2006-08-24 13:56 UTC, Buck Huppmann
no flags Details
patch to patch-3.0.23b-3.0.23c-gwc-1.diffs-patched code (4.64 KB, patch)
2006-08-30 12:28 UTC, Buck Huppmann
no flags Details
my smb.conf, doctored, of course (2.36 KB, text/plain)
2006-08-30 14:31 UTC, Buck Huppmann
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Buck Huppmann 2006-08-24 13:52:48 UTC
for us, i mean; i'm sure it's been playing to wide acclaim for everyone else
who's trying to turn his UNIX machine into a Windows servant, but we're trying
to keep most administrative control on UNIX and just refer logons and
SID-to-name-to-[ug]id translations to winbindd

sorry. should probably leave politics out of this

anyway, we have security = ads and all user's domain\-less account names in
/etc/passwd and /etc/group on each samba server. upon our abortive 3.0.22-to-
3.0.23b upgrade, our users' supplementary /etc/group memberships failed to be
honored any more, leading to access failures in the underlying UNIX/POSIX APIs

i take it this has to do with the new token-based authorization stuff samba im-
plements and the fact that our user's ADS groups have no correlation with their
UNIX group memberships (the former being nonexistent, except for Domain Users).
anyway, cranking up debugging would demonstrate that users had 0 gids in their
supplementary gid list

attached is a patch to revert the behavior, subject to a non-default config
setting. i'm sure it will probably result in death and dismemberment for some-
body, but, so far, nobody hereabouts. limitations include that it's an all-or-
none proposition, leading to wholesale disregard of the group membership lists
derived from the user's netlogon token or winbind- or passdb-enumerated group
memberships, but i figure that's retributively fair, since the upgrade did just
the converse/opposite to us. further limitation is lack of documentation, since
i couldn't locate the smb.conf.5 source in my distribution tarball. what's more:
it's probably just plain wrong and is botched for 1000 different usage scenarios
from the straightforward ones we make of it. for all those, i apologize, but i
hope you can maybe understand what i'm getting at and that it's not just a mis-
config on my part

Comment 1 Buck Huppmann 2006-08-24 13:56:59 UTC
Created attachment 2103 [details]
PR-body-referenced patch
Comment 2 Gerald (Jerry) Carter 2006-08-24 14:02:31 UTC
Buck, would you mind trying the patch at

I agree with your analysis. It was a misintended side effect 
of the changes.  I think we have thigns worked out now (for 3.0.23c)
but would appreciate some testing feedback from more people.
Also could you please attach your smb.conf so I can understand 
more about your environment.
Comment 3 Buck Huppmann 2006-08-24 15:40:20 UTC
i'll try the patch and let you know, attaching my smb.conf in case of trouble.
(it's too hideous to otherwise put on public display. e.g., it contains the
3.0.whatever's release mascot: winbind trusted domains only)

thanks for so quickly taking ownership and responding
Comment 4 Buck Huppmann 2006-08-30 12:28:24 UTC
Created attachment 2116 [details]
patch to patch-3.0.23b-3.0.23c-gwc-1.diffs-patched code

sorry; your patch didn't do the trick for me, as my logons are
going down the sesssetup...spnego path and end up calling
auth/auth_util.c:make_server_info_info3(), which doesn't call
pdb_enum_group_memberships(). the patch i've uploaded (assuming
IE does the right thing) integrates your gid-to-SID-stuff into
that function also, ``factoring'' it out into a helper that's
called by the other functions that require that. works for me
(with both domain accounts and mapped accounts [though i haven't
tested guest])

Comment 5 Gerald (Jerry) Carter 2006-08-30 13:07:47 UTC
Buck,  would you attach your smb.cofn for me ?
Comment 6 Buck Huppmann 2006-08-30 14:31:19 UTC
Created attachment 2117 [details]
my smb.conf, doctored, of course


OK. i relent

it's been doctored to remove all indicia of my employer. the stuff at the
top and the lack of idmap directives will clue you into the fact that we
run a hacked winbindd that maps domain SIDs to uids/gids of existing
passwd/group entries and vice versa and just returns not-found-ish errors
for anything that would require an idmap allocation. (i see there's a new
idmap_proxyonly functionality, that might offer this out of the box, i'm

so, yes, i've probably been a bit disingenuous to suggest that it's a
change in samba functionality that's engendered our woes of late, but in-
sofar as my experience accords with whatever anybody else has been report-
ing and as (the latest, at least, of) my attempted patches accord with
what it's perceived samba might reasonably be expected to do, i hope that
doesn't invalidate this PR (or even bug #3807, though i probably need to
furnish you a better, usable-in-absence-of-winbindd patch for that)

thanks for continuing to pursue

and belated apologies for the broadsides i made against the direction of
samba development amounting to hosting a virtualized NT server on a UNIX
hypervisor; it's tres moderne, after all
Comment 7 Rudi Chiarito 2006-11-08 15:23:23 UTC
I think I am seeing the same problem. 3.0.23c doesn't work, 3.0.10 does. Unix users are coming from getpwnam(), not from the AD tree, obtained through a lookup to a Unix LDAP server that mirrors user information from AD (long story). Log files indicate that Samba does find "username" through getpwnam() after having looked up DOMAIN\USERNAME and a couple more permutations, but then it keeps looking for DOMAIN\domain\USERNAME and other stuff and eventually fails.

This looks like a major regression to me.
Comment 8 Jeremy Allison 2006-11-08 20:23:25 UTC
Actually the lookup on DOMAIN\domain\USERNAME is a known bug I've
fixed for 3.0.23d. Please try the code in the SAMBA_3_0_23 svn branch
and see if this fixes it for you.
Comment 9 Rudi Chiarito 2006-11-09 12:37:27 UTC
Hello Jeremy,
I have tried looking for the change you made, but can't find it. Which source file or changeset is it in? A patch (rather than the whole 3.0.23 branch) would be easier for me to test.
Comment 10 Buck Huppmann 2006-11-09 19:08:40 UTC
@Rudi C.:

could it be


Comment 11 Jeremy Allison 2006-11-10 17:50:41 UTC
Yes that's the one. Here's the svn revision number.
svn diff -r18906:18907 smbd/sesssetup.c