Details of this bugs are in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387076. As a summary, our user reported that 'valid users' is no longer working for him since 3.0.23d (3.0.22 is OK). He reproduces this with 3.0.24. I couldn't reproduce this but he mentioned that his 'valid users' are indeed NIS users, which may explain why I can't reproduce the bug. smb.conf: [global] workgroup = TARGIT01.DE server string = targit share server wins support = yes dns proxy = no interfaces = 127.0.0.0/8 eth0 bind interfaces only = true hosts allow = 192.168.6. 192.168.2. 127. log file = /var/log/samba/log.%m log level = 2 max log size = 5000 local master = yes os level = 100 domain master = no domain logons = no preferred master = yes security = user map to guest = Never guest ok = false invalid users = root load printers = yes printing = cups printcap name = cups socket options = TCP_NODELAY browseable = true encrypt passwords = false unix charset = ISO8859- display charset = ISO8859-1 [ProjectShare] comment = targit Project Share path = /ProjectShare browseable = yes writeable = true printable = false create mask = 0666 directory mask = 0777 guest ok = true [OfficeShare] comment = targit Office Share (restricted) path = /OfficeShare guest ok = false valid users = peter, martinh admin users = force group = gleitung writeable = true printable = false create mask = 0760 force create mode = 0760 directory mask = 0770 browseable = false He recorded a level 10 log which I'll attach later
Created attachment 2732 [details] Level 10 debug log of a failed session Comment from our user: attached a level 10 log with the current stable (etch) samba packages 3.0.24-6. The logs contain: - connect from 192.168.2.205 (ntmhvm) to TargitShare on targit1 with the user martinh this connect works the share has no "valid users" setup - connect from 192.168.2.205 (ntmhvm) to OfficeShare on targit1 with the user martinh this connect works NOT the share uses a "valid users" setup - probably there are some connects from 192.168.2.231 (ntckvm) and 192.168.2.189 (ltpb) in the log which can be ignored for this test
Created attachment 2760 [details] Simple workaround(?) for samba We've experienced similar problem. User was not allowed to access a share (NT_STATUS_ACCESS_DENIED) if he was listed in "valid users" but not added into a passdb backend. If "valid users" had an group entry (@group) users from this group were allowed. I'm not a samba developer, but I've written simple patch/workaround which solved this issue (I've been testing it for whole 5 minutes). I hope somebody will accept this, or invent a better resolution for a problem.
Sorry, but I think this is the wrong approach. We need to figure out why either the token is wrong or lookup_name can't find your user. We've gone through bit pains to get rid of the name-based access checks, and I'm a bit reluctant to go back. Volker
lookup_name returns through this if: if (!(flags & LOOKUP_NAME_EXPLICIT) && strequal(domain, unix_users_domain_name())) { if (lookup_unix_user_name(name, &sid)) { type = SID_NAME_USER; goto ok; <-- here. } TALLOC_FREE(tmp_ctx); return False; } Without copying SID first like in previous if: sid_copy(&sid, get_global_sam_sid()); sid_append_rid(&sid, rid); So that's probably why nt_token_check_sid() fails I guess. I was sure that my approach is not good. But it was everything i could done in this subject.
> Without copying SID first like in previous if: Uh, well - wrong. SID of course is copied by lookup_unix_user_name().
So you need to look in the token creation routines in auth_util.c why the correct user sid is not in the token
(In reply to comment #6) > So you need to look in the token creation routines in auth_util.c why the > correct user sid is not in the token > Just before nt_token_check_sid: User SID: (gdb) print sid $14 = {sid_rev_num = 1 '\001', num_auths = 2 '\002', id_auth = "\000\000\000\000\000\026", sub_auths = {1, 1000, 0 <repeats 13 times>}} In 13 SIDs read from token id_auth is _mostly_ the same, but sub_auths differ. (gdb) print sid2[0] $30 = {sid_rev_num = 1 '\001', num_auths = 2 '\002', id_auth = "\000\000\000\000\000\026", sub_auths = {2, 7, 0 <repeats 13 times>}} $32 = {sid_rev_num = 1 '\001', num_auths = 2 '\002', id_auth = "\000\000\000\000\000\026", sub_auths = {2, 10, 0 <repeats 13 times>}} $36 = {sid_rev_num = 1 '\001', num_auths = 2 '\002', id_auth = "\000\000\000\000\000\026", sub_auths = {2, 18, 0 <repeats 13 times>}} etc. I guess these are this tokens: se_access_check: user sid is S-1-5-21-2176992431-4081783690-2698828043-3000 se_access_check: also S-1-22-2-4 se_access_check: also S-1-1-0 se_access_check: also S-1-5-2 se_access_check: also S-1-5-11 se_access_check: also S-1-22-2-7 se_access_check: also S-1-22-2-10 se_access_check: also S-1-22-2-18 se_access_check: also S-1-22-2-19 se_access_check: also S-1-22-2-102 se_access_check: also S-1-22-2-250 se_access_check: also S-1-22-2-16 se_access_check: also S-1-22-2-35 I think that the function which creates sid for unix user creates it in a different manner that it should: sid_copy(sid, &global_sid_Unix_Users); sid_append_rid(sid, pwd->pw_uid); /* For 64-bit uid's we have enough Hmhm. ;-)
Created attachment 2761 [details] Another workaround. Maybe better than previous. ;p This patch makes samba call create_token_from_username instead of create_local_nt_token in auth_util.c for users which are found in PAM (I guess). If that function is called token gets SIDs created from UID, which are then accepted by functions in share_access.c There might be side effects. ;p I hope that somebody with bigger experience will be able to fix this issue.
Can you try to put this in auth_unix.c:119 (branches/SAMBA_3_0..) and see what happens? Then it would only apply to plain text passwords, in that case I'd be less reluctant to buy this. Volker
Created attachment 2762 [details] Another solution It worked generally: It accepted user from "valid users" while refusing others. I'm testing it with "3.0.27pre1-SVN-build-". It would need a few more tests, maybe someone will find a better resolution? We just need to force user creation with "create_token_from_username" for users without passdb entry, which are authenticated with PAM. I guess. If you like I can submit mine testparm -v output and connection log.
22:54 < vl> vorago: I'm here 22:56 < vl> vorago: With a good comment I think I could accept that solution if it works for you. To be honest, I don't really care about non-encrypted passwords anymore... 22:56 < vorago> Heh. 22:56 < vorago> I guess that patch needs testing. Lots of 22:56 < vorago> I can add comment explaining 'why'. 22:56 < vl> No, this is quite obvious what it does. 22:57 < vorago> You think? I'm not quite clear about 'mapped users' 22:57 < vl> That's the beauty of the new code. It's all quite centralized when you find the right spots. 22:57 < vorago> It's not so hard to debug samba. 22:58 < vl> The way you did it is a bit of a hack. But a mapped user just needs to get in via the "token" it got from /etc/passwd and /etc/group, because it has changed its identity from what Windows or passdb told us. 22:58 < vl> Same applies to users without encrypted passwords authenticated via PAM. 22:58 < vorago> So the comment just might look like: 22:58 < vl> So setting the is_mapped flag at this spot triggers exactly the right action. 22:59 < vorago> Force Samba to use information from PAM while creating user SIDS 22:59 < vl> It's not exactly using the PAM info, it's using NSS info. 22:59 < vorago> Hm, right. 22:59 < vl> PAM is out of the game at this point. 23:00 < vl> vorago: Feel free to add my comments here on irc for reference. I'd like Jerry/Jeremy to sign this off also, but you've got my go. vorago==bla
This fix is a good band-aid, but I think the real bug is in make_server_info_pw() where we say : /* For now we throw away the gids and convert via sid_to_gid * later. This needs fixing, but I'd like to get the code straight and * simple first. */ TALLOC_FREE(gids); I think we should be using gid_to_sid here in the same way as in create_token_from_username(). Jeremy. Jeremy
Ah - no. In make_server_info_pw() we're already calling pdb_enum_group_memberships() which should bounce down to pdb_default_enum_group_memberships() which does exactly the getgroups_unix_user() call followed by the : for (i=0; i<*p_num_groups; i++) { gid_to_sid(&(*pp_sids)[i], (*pp_gids)[i]); } translation. Why isn't this working and returning a correct token with the right SIDs ? Jeremy.
Interesting. Looking at the logs the problem seems to be that the logged on user gets the SID prefix of the local machine, but when being searched for in "valid users = martinh" he gets the SID prefix of "Unix User". I think on Logon the SID prefix should be being set to S-1-1-22-<rid>. This is the real bug I think. Jeremy.
Created attachment 2763 [details] Replacement patch Ok, can you check this patch please ? I think this is more correct, even though much longer. The real problem is that the user SID in the token is wrong. This really should be a UNIX-only SID. Jeremy.
(In reply to comment #15) > Ok, can you check this patch please ? I think this is more correct, even though > much longer. The real problem is that the user SID in the token is wrong. This > really should be a UNIX-only SID. > Jeremy. > Checked; it worked in NIS environment in mine configuration. It generally does the same thing (adds uid based SID) but in much straight forward way and doesn't look like a hack. ;)
Created attachment 2765 [details] Patch Ok, sorry - I think this is a better patch - it should also fix bug #4678 and not cause any backwards compatibility problems in environments with plaintext passwords and no backend SAM. Let me know - in testing this I discovered some minor memory leaks in our auth subsystem but I'll fix these for 3.0.26, too dangerous for 3.0.25b. I think this is safe though. Jeremy.
Never mind - I was mistaken about the auth memory leaks (just ^D'ed smbclient instead of logging off correctly). This should fix the bug generically for 3.0.25b and beyond though. Jeremy.
fixed in 3.0.25b