If smb.conf is configured with "force user" set to an active directory user, any attempt to connect to the share fails with: [2011/11/07 16:25:47.071201, 3] passdb/lookup_sid.c:1737(get_primary_group_sid) Forcing Primary Group to 'Domain Users' for CINDER\administrator [2011/11/07 16:25:47.071245, 1] auth/server_info.c:391(samu_to_SamInfo3) The primary group domain sid(S-1-5-21-2089716213-3334164741-1685414606-513) does not match the domain sid(S-1-5-21-1556222852-1544685173-53101980) for CINDER\administrator(S-1-5-21-1556222852-1544685173-53101980-500) [2011/11/07 16:25:47.071278, 10] auth/auth_util.c:636(make_server_info_pw) Failed to convert samu to info3: NT_STATUS_UNSUCCESSFUL [2011/11/07 16:25:47.071307, 3] smbd/error.c:81(error_packet_set) error packet at smbd/reply.c(803) cmd=117 (SMBtconX) NT_STATUS_UNSUCCESSFUL This is a regression from previous behaviour, where "force user" could be set to an active directory user. The current force_user make_server_info_pw() code path assumes the target user is a local user: - unix_users_domain_name() is unconditionally added as a prefix to the username prior to looking up the user SID. - get_primary_group_sid() composes a group sid using get_global_sam_sid() and DOMAIN_RID_USERS rather than the winbind mapped value, causing the domain SID mismatch error blocking login.
Created attachment 7078 [details] proposed patch addressing local user assumptions
(In reply to comment #1) > Created attachment 7078 [details] > proposed patch addressing local user assumptions This patch does not fix the case where "winbind use default domain = yes" is configured, as unix_users_domain_name() prefix is still added prior to lookup.
Created attachment 7090 [details] proposed patch The following changes since commit 17f1a97a614db4ed8292544988cb6a6cf56621d8: libcli/cldap: fix a crash bug in cldap_socket_recv_dgram() (bug #8593) (2011-11-10 16:31:59 +0100) are available in the git repository at: git://git.samba.org/ddiss/samba.git bso8598_ad_force_user_rb1 David Disseldorp (1): s3-auth: fix force user for AD user source3/auth/auth_util.c | 18 ++++++++---------- source3/passdb/lookup_sid.c | 3 +-- 2 files changed, 9 insertions(+), 12 deletions(-)
I've just been hit by this bug (or one of its incarnation) on one server of mine. It was, up to now, running 3.5.8 (a backported package of mine, on Debian squeeze). We updated it last week-end to 3.6.5 as a way to cope with latest security issue and also moved to a version that is maintained (by me) in Debian. However, this server has users coming from two domains named "ATLAS" and "IDF", and is a member of one of the two (IDF). Users have the same logins in both domains and we use "force user" the following way in smb.conf, for their home directories: [homes] comment = Home Directories create mask = 0700 browseable = No writable = Yes # Permet d'arriver depuis un compte IDF ou ATLAS et que ca marche valid users = IDF+%S,ATLAS+%S,%S force user = IDF+%S force group = IDF+dota-gg path = /home/IDF/%S Since the upgrade to 3.6.5, users couldn't reach their homes anymore, because whatever domain they were coming from, "force user" was forcing to local accounts, not to IDF+<login>. And their homes do belong to IDF+<login> not to <login> (we're using winbind on that machine). I tried to build 3.6.5 packages with the proposed patch but that didn't help. As this is a production server, I can have hard times reproducing that and get meaningful logs (maybe at night..:-)). The only difference with what David reports is that domains, in my case, are NT4 domains (yes, I'm still using those beasts!).
Created attachment 7542 [details] Level 10 log showing the problem
Created attachment 7543 [details] smb.conf for the server with the problem
My test case on this server: It is member of the IDF domain. This domain trusts other domains, among these one named "ATLAS". User logins are identical in both domains. The server runs winbind and the home for "IDF+cperrier" is /home/IDF/cperrier. I want user "cperrier" of domain ATLAS to use //<server>/cperrier and end up in the same place than "cperrier" of domain IDF when using //<server>/cperrier Hence the setting I have for [homes]. It works just fine in 3.5 and is plain broken in 3.6 as soon as "force user" is used. Neither IDF\cperrier not atlas\cperrier can login... Commenting the "force user" statement allows idf\cperrier to login but, of course, atlas\cperrier just can't. I have a full test setup ready for testing patches. A first try on David's patch wasn't successful but I did that in a hurry on a production server and will do that more quietly on my test server. In any case, I consider this a serious enough regression for being mandatory in 3.6...:-)
(In reply to comment #3) > Created attachment 7090 [details] > proposed patch Tried this one. I added this patch to the 3.6.5 Debian package I use (and maintain), rebuilt, installed on my test server and, well, smbd doesn't even start..:-)
Created attachment 7548 [details] Logfile of smbd starting with David's patch (send with the pkg-samba-maint account but that's still Christian Perrier speaking)
Is there a chance to get this one fixed until July 30?
The patch has been rejected cause of: https://lists.samba.org/archive/samba-technical/2011-November/080405.html
I've bisected the 3.6 tree from current v3-6-test to the commit of 3.5.8 at I'm the 3.5.8 now. So this seems to be broken in 3.5.8 already. The provided information seem to be incorrect.
Created attachment 9469 [details] Patch for master
Here is a new patch which should fix the "Here be dragons" part. See also create_token_from_username introduced by Andrew with 1c3c5e2156d9096f60bd53a96b88c2f1001d898a
gd and I are confident that the first hunk is correct. The second hunk is probably the 'here be dragons' hunk. So we need your comment on that and if you see problem your input how to correctly fix this.
For the record, commit f62683956a3b182f6a61cc7a2b4ada2e74cde243 (fail authentication for single group name which cannot be converted to sid) incorrectly refers to this bug ID. It should instead refer to bug 10300. My mistake.
Created attachment 9642 [details] v4-1-test patch
Created attachment 9643 [details] v4-0-test patch
Created attachment 9644 [details] v4-0-test patch
Comment on attachment 9642 [details] v4-1-test patch LGTM
Karolin, please add the patches to the relevant branches. Thanks!
The patchset has a bug. I will fix it and upload a new one.
Created attachment 9696 [details] v4-1-test patch
Created attachment 9697 [details] v4-0-test patch
Created attachment 9699 [details] v4-1-test patch
Created attachment 9700 [details] v4-0-test patch
Comment on attachment 9699 [details] v4-1-test patch LGTM.
Comment on attachment 9700 [details] v4-0-test patch LGTM
Re-assigning to Karolin for inclusion in 4.0.next, 4.1.next. Jeremy.
Comment on attachment 9700 [details] v4-0-test patch Ah - NAK on this one. Looks like you erroneously changed the signature for pdb_create_builtin_alias in source3/passdb/ABI/pdb-0.1.0.sigs It should be: source3/passdb/ABI/pdb-0.sigs:pdb_create_builtin_alias: NTSTATUS (uint32_t) not: source3/passdb/ABI/pdb-0.1.0.sigs:pdb_create_builtin_alias: NTSTATUS (uint32_t, gid_t) So this still needs fixing up. Jeremy.
Moving back to Andreas to fix up the 4.0.x patch.
(In reply to comment #30) > Comment on attachment 9700 [details] > v4-0-test patch > > Ah - NAK on this one. Looks like you erroneously changed the signature for > pdb_create_builtin_alias in source3/passdb/ABI/pdb-0.1.0.sigs > > It should be: > source3/passdb/ABI/pdb-0.sigs:pdb_create_builtin_alias: NTSTATUS (uint32_t) > > not: > > source3/passdb/ABI/pdb-0.1.0.sigs:pdb_create_builtin_alias: NTSTATUS (uint32_t, > gid_t) > > So this still needs fixing up. Well spotted! The problem seems to be that we have the same ABI version in 4.0 and 4.1 but different signature for pdb_create_builtin_alias(). Therefore, the patch from 4.1 does not work, and we need to recreate the signatures file for 4.0. But the question is: do we need to do anything regarding the brokenness of the versions between master/4.1 and 4.0 ? Cheers - Michael
I need to be able to map local users to AD users, so we can have certain services impersonate the AD users for purposes of file ownership and permissions on the server. Based on the bug description, this patch looked like what I would need, but when I tried applying the latest v4-1-test patch to 4.1.7, I get the same behavior described in the original report; the connection fails with an error about mismatched groups. In this particular test case, I have a local user "andy" with "force user = andy.liebman", an AD user. [2014/04/24 19:41:13.675568, 10, pid=3230, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:77(lookup_name) lookup_name: Unix User\andy.liebman => domain=[Unix User], name=[andy.liebman] [2014/04/24 19:41:13.675600, 10, pid=3230, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:78(lookup_name) lookup_name: flags = 0x073 [2014/04/24 19:41:13.676043, 5, pid=3230, effective(0, 0), real(0, 0)] ../source3/lib/username.c:181(Get_Pwnam_alloc) Finding user andy.liebman [2014/04/24 19:41:13.676089, 5, pid=3230, effective(0, 0), real(0, 0)] ../source3/lib/username.c:120(Get_Pwnam_internals) Trying _Get_Pwnam(), username as lowercase is andy.liebman [2014/04/24 19:41:13.676124, 5, pid=3230, effective(0, 0), real(0, 0)] ../source3/lib/username.c:159(Get_Pwnam_internals) Get_Pwnam_internals did find user [andy.liebman]! [2014/04/24 19:41:13.676238, 10, pid=3230, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:1220(gid_to_sid) gid 16777222 -> sid S-1-5-21-832283782-3302318743-1924928875-513 [2014/04/24 19:41:13.676285, 1, pid=3230, effective(0, 0), real(0, 0), class=auth] ../source3/auth/server_info.c:550(passwd_to_SamInfo3) The primary group domain sid(S-1-5-21-832283782-3302318743-1924928875-513) does not match the domain sid(S-1-22-1) for andy.liebman(S-1-22-1-16777217) [2014/04/24 19:41:13.676342, 5, pid=3230, effective(0, 0), real(0, 0)] ../lib/dbwrap/dbwrap.c:187(dbwrap_check_lock_order) check lock order 1 for /var/run/samba/smbXsrv_tcon_global.tdb editshare@lmbd-ad-mstr:~$ getent passwd andy.liebman andy.liebman:*:16777217:16777222::/home/andy.liebman:/sbin/nologin editshare@lmbd-ad-mstr:~$ getent group mxfsamba4 mxfsamba4:x:502:editshare,_flow,brian.p.campbell,andy.liebman,brian,andy editshare@lmbd-ad-mstr:~$ wbinfo -U 16777217 S-1-5-21-832283782-3302318743-1924928875-1133 editshare@lmbd-ad-mstr:~$ wbinfo -G 16777222 S-1-5-21-832283782-3302318743-1924928875-513 It looks like for some reason it's mapping the primary group to the user's AD primary group SID, but only mapping the user to the Unix User SID, not the AD SID.
Created attachment 9869 [details] Full level 10 log of connection attempt
Created attachment 9870 [details] smb.conf from my setup
(In reply to comment #35) > Created attachment 9870 [details] > smb.conf from my setup Can you try with force user = MYDOMAIN\andy.liebman ? This might be one of the places where "winbind use default domain = yes" has negative effects.
Adding the domain explicitly to the "force user" option had the same effect; it still tried looking up the user in the local domain, lmbd-ad-mstr, not the AD domain: [2014/04/25 11:55:44.715034, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:237(user_ok_token) user_ok_token: share mxfsamba4_1 is ok for unix user andy [2014/04/25 11:55:44.715108, 5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:181(Get_Pwnam_alloc) Finding user MYDOMAIN\andy.liebman [2014/04/25 11:55:44.715143, 5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:120(Get_Pwnam_internals) Trying _Get_Pwnam(), username as lowercase is mydomain\andy.liebman [2014/04/25 11:55:44.971290, 5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:159(Get_Pwnam_internals) Get_Pwnam_internals did find user [MYDOMAIN\andy.liebman]! [2014/04/25 11:55:44.971368, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:77(lookup_name) lookup_name: LMBD-AD-MSTR\andy.liebman => domain=[LMBD-AD-MSTR], name=[andy.liebman] [2014/04/25 11:55:44.971400, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:78(lookup_name) lookup_name: flags = 0x073 [2014/04/25 11:55:44.971431, 4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:216(push_sec_ctx) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2014/04/25 11:55:44.971460, 4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/uid.c:485(push_conn_ctx) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2014/04/25 11:55:44.971486, 4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:316(set_sec_ctx) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2014/04/25 11:55:44.971513, 5, pid=9454, effective(0, 0), real(0, 0)] ../libcli/security/security_token.c:53(security_token_debug) Security token: (NULL) [2014/04/25 11:55:44.971534, 5, pid=9454, effective(0, 0), real(0, 0)] ../source3/auth/token_util.c:629(debug_unix_user_token) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2014/04/25 11:55:44.971534, 10, pid=9454, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_smbpasswd.c:1293(smbpasswd_getsampwnam) getsampwnam (smbpasswd): search by name: andy.liebman [2014/04/25 11:55:44.971534, 10, pid=9454, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_smbpasswd.c:238(startsmbfilepwent) ... snip failed search in smbpasswd ... [2014/04/25 11:55:44.971829, 4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:424(pop_sec_ctx) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2014/04/25 11:55:44.971857, 4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:216(push_sec_ctx) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2014/04/25 11:55:44.971883, 4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/uid.c:485(push_conn_ctx) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2014/04/25 11:55:44.971908, 4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:316(set_sec_ctx) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2014/04/25 11:55:44.971933, 5, pid=9454, effective(0, 0), real(0, 0)] ../libcli/security/security_token.c:53(security_token_debug) Security token: (NULL) [2014/04/25 11:55:44.971957, 5, pid=9454, effective(0, 0), real(0, 0)] ../source3/auth/token_util.c:629(debug_unix_user_token) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2014/04/25 11:55:44.972014, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/groupdb/mapping_tdb.c:272(find_map) failed to unpack map [2014/04/25 11:55:44.972048, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/groupdb/mapping_tdb.c:272(find_map) failed to unpack map [2014/04/25 11:55:44.972092, 4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:424(pop_sec_ctx) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2014/04/25 11:55:44.972123, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:77(lookup_name) lookup_name: Unix User\andy.liebman => domain=[Unix User], name=[andy.liebman] [2014/04/25 11:55:44.972149, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:78(lookup_name) lookup_name: flags = 0x073 [2014/04/25 11:55:44.973496, 5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:181(Get_Pwnam_alloc) Finding user andy.liebman [2014/04/25 11:55:44.973578, 5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:120(Get_Pwnam_internals) Trying _Get_Pwnam(), username as lowercase is andy.liebman [2014/04/25 11:55:44.973810, 5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:159(Get_Pwnam_internals) Get_Pwnam_internals did find user [andy.liebman]! [2014/04/25 11:55:44.973923, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:1220(gid_to_sid) gid 16777222 -> sid S-1-5-21-832283782-3302318743-1924928875-513 [2014/04/25 11:55:44.973963, 1, pid=9454, effective(0, 0), real(0, 0), class=auth] ../source3/auth/server_info.c:550(passwd_to_SamInfo3) The primary group domain sid(S-1-5-21-832283782-3302318743-1924928875-513) does not match the domain sid(S-1-22-1) for andy.liebman(S-1-22-1-16777217) However, per Volker's suggestion about "winbind use default domain = yes" I tried turning that off, and was able to successfully connect to the share, and got the correct SID so that ACLs now work properly. In order for it to work, I need to turn off "winbind use default domain" and provide the explicit domain in the "force user" option. Now I need to figure out if we can work around the lack of "winbind use default domain = yes" or if we will need to find a way to get that to work, but that looks like more of a bug in "winbind use default domain" than in this patch.
no more feedback anb I've seen this working in recent supported Samba releases. So we'll close this now.