The Samba-Bugzilla – Bug 4047
post~3.0.22 group-membership handling undesirable
Last modified: 2009-04-04 08:03:02 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
Created attachment 2103 [details]
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.
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
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
Buck, would you attach your smb.cofn for me ?
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
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.
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.
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.
could it be
Yes that's the one. Here's the svn revision number.
svn diff -r18906:18907 smbd/sesssetup.c