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 --buck
Created attachment 2103 [details] PR-body-referenced patch
Buck, would you mind trying the patch at http://samba.org/~jerry/patches/patch-3.0.23b-3.0.23c-gwc-1.diffs.gz ? 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 tested guest]) h/t/h
Buck, would you attach your smb.cofn for me ?
Created attachment 2117 [details] my smb.conf, doctored, of course [groan] 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 hoping) 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. Jeremy.
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.
@Rudi C.: could it be https://bugzilla.samba.org/show_bug.cgi?id=4095 ?
Yes that's the one. Here's the svn revision number. svn diff -r18906:18907 smbd/sesssetup.c Jeremy.