Hi, I'm about to update our old workgroup server from Solaris 8 with Samba 3.0.22 to Debian 4.0 with Samba 3.0.23d (debian package). With 3.0.22 I was using 'security = server' now I was able to get the server in the AD/Domain and try to use winbind. As a first step I tried a part of my old config: [foo] comment = foo writable = yes force create mode = 0660 create mask = 0660 force directory mode = 2770 directory security mask = 2770 force directory security mode = 0000 directory mask = 2770 force security mode = 0000 force group = +ve security mask = 0770 path = /projekte/foo valid users = +ve vfs objects = extd_audit Group ve is a local unix group and AD user ralfgro is member of that group. $ id -a EMEA\\ralfgro uid=70000(ralfgro) gid=70000(domain users) Gruppen=70000(domain users),300(ve) User ralfgro is able to authenticate and to connect to that share if I use 'vali users = EMEA\ralfgro' [2007/01/25 14:15:33, 3] lib/util_sid.c:string_to_sid(223) string_to_sid: Sid EMEA\ralfgro does not start with 'S-'. [2007/01/25 14:15:33, 10] passdb/lookup_sid.c:lookup_name(64) lookup_name: EMEA\ralfgro => EMEA (domain), ralfgro (name) [2007/01/25 14:15:33, 10] smbd/share_access.c:user_ok_token(229) user_ok_token: share foo is ok for unix user EMEA\ralfgro [2007/01/25 14:15:33, 10] smbd/share_access.c:is_share_read_only_for_token(271) is_share_read_only_for_user: share foo is read-write for unix user EMEA\ralfgro I'm not able to connect to this share if I use the unix group as I did with 3.0.22. valid users = +ve [2007/01/25 14:19:22, 3] lib/util_sid.c:string_to_sid(223) string_to_sid: Sid root does not start with 'S-' [2007/01/25 14:19:22, 10] passdb/lookup_sid.c:lookup_name(64) lookup_name: VU0EM003\ve => VU0EM003 (domain), ve (name) [2007/01/25 14:19:22, 3] smbd/sec_ctx.c:push_sec_ctx(208) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2007/01/25 14:19:22, 3] smbd/uid.c:push_conn_ctx(345) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2007/01/25 14:19:22, 3] smbd/sec_ctx.c:set_sec_ctx(241) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2007/01/25 14:19:22, 5] auth/auth_util.c:debug_nt_user_token(448) NT user token: (NULL) [2007/01/25 14:19:22, 5] auth/auth_util.c:debug_unix_user_token(474) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2007/01/25 14:19:22, 3] smbd/sec_ctx.c:pop_sec_ctx(339) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2007/01/25 14:19:22, 10] smbd/share_access.c:user_ok_token(208) User EMEA\ralfgro not in 'valid users' [2007/01/25 14:19:22, 2] smbd/service.c:make_connection_snum(580) user 'EMEA\ralfgro' (from session setup) not permitted to access this share (foo) [2007/01/25 14:19:22, 3] smbd/error.c:error_packet(146) error packet at smbd/reply.c(676) cmd=117 (SMBtconX) NT_STATUS_ACCESS_DENIED Using AD groups it working: valid users = +EMEA\"domain users" [2007/01/25 14:25:41, 3] lib/util_sid.c:string_to_sid(223) string_to_sid: Sid +EMEA\domain users does not start with 'S-'. [2007/01/25 14:25:41, 10] passdb/lookup_sid.c:lookup_name(64) lookup_name: EMEA\domain users => EMEA (domain), domain users (name) [2007/01/25 14:25:41, 10] smbd/share_access.c:user_ok_token(229) user_ok_token: share foo is ok for unix user EMEA\ralfgro [2007/01/25 14:25:41, 10] smbd/share_access.c:is_share_read_only_for_token(271) is_share_read_only_for_user: share foo is read-write for unix user EMEA\ralfgro I tried different strings for the valid users parameter that I found in the samba mailing list archive. +HOSTNAME\ve +BULTIN\ve +"Unix Group"\ve ...and some other strings. Nothing worked. Maybe I'm simply missing something, but I found some mails regarding a similar problem in other samba 3.0.2x versions. Ralf
*** Bug 4354 has been marked as a duplicate of this bug. ***
*** Bug 4355 has been marked as a duplicate of this bug. ***
I'm in trial and error mode at the moment... This is working: local unix user rg, added with 'smbpasswd -a rg'. Member of unix group ve. [2007/01/26 08:27:02, 3] lib/util_sid.c:string_to_sid(223) string_to_sid: Sid +ve does not start with 'S-'. [2007/01/26 08:27:02, 10] passdb/lookup_sid.c:lookup_name(64) lookup_name: VU0EM003\ve => VU0EM003 (domain), ve (name) [2007/01/26 08:27:02, 3] smbd/sec_ctx.c:push_sec_ctx(208) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2007/01/26 08:27:02, 3] smbd/uid.c:push_conn_ctx(345) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2007/01/26 08:27:02, 3] smbd/sec_ctx.c:set_sec_ctx(241) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2007/01/26 08:27:02, 5] auth/auth_util.c:debug_nt_user_token(448) NT user token: (NULL) [2007/01/26 08:27:02, 5] auth/auth_util.c:debug_unix_user_token(474) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2007/01/26 08:27:02, 3] smbd/sec_ctx.c:pop_sec_ctx(339) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2007/01/26 08:27:02, 10] passdb/lookup_sid.c:lookup_name(64) lookup_name: Unix Group\ve => Unix Group (domain), ve (name) [2007/01/26 08:27:02, 10] smbd/share_access.c:user_ok_token(229) user_ok_token: share foo is ok for unix user rg [2007/01/26 08:27:02, 10] smbd/share_access.c:is_share_read_only_for_token(271) is_share_read_only_for_user: share foo is read-write for unix user rg [2007/01/26 08:27:02, 4] lib/sharesec.c:get_share_security(130) get_share_security: using default secdesc for foo [2007/01/26 08:27:02, 10] lib/util_seaccess.c:se_map_generic(176) se_map_generic(): mapped mask 0x10000000 to 0x001f01ff [2007/01/26 08:27:02, 10] lib/util_seaccess.c:se_access_check(233) se_access_check: requested access 0x00000002, for NT token with 22 entries an This is not working: AD User emea\ralfgro which I added to the local unix group ve with gpasswd: $ gpasswd -a emea\\ralfgro ve Adding user emea\ralfgro to group ve $ id -a emea\\ralfgro uid=70000(ralfgro) gid=70000(domain users) Gruppen=70000(domain users),300(ve) So, AD user ralfgro is clearly member of group ve. [2007/01/26 08:29:10, 3] lib/util_sid.c:string_to_sid(223) string_to_sid: Sid +ve does not start with 'S-'. [2007/01/26 08:29:10, 10] passdb/lookup_sid.c:lookup_name(64) lookup_name: VU0EM003\ve => VU0EM003 (domain), ve (name) [2007/01/26 08:29:10, 3] smbd/sec_ctx.c:push_sec_ctx(208) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2007/01/26 08:29:10, 3] smbd/uid.c:push_conn_ctx(345) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2007/01/26 08:29:10, 3] smbd/sec_ctx.c:set_sec_ctx(241) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2007/01/26 08:29:10, 5] auth/auth_util.c:debug_nt_user_token(448) NT user token: (NULL) [2007/01/26 08:29:10, 5] auth/auth_util.c:debug_unix_user_token(474) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2007/01/26 08:29:10, 3] smbd/sec_ctx.c:pop_sec_ctx(339) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2007/01/26 08:29:10, 10] passdb/lookup_sid.c:lookup_name(64) lookup_name: Unix Group\ve => Unix Group (domain), ve (name) [2007/01/26 08:29:10, 10] smbd/share_access.c:user_ok_token(208) User EMEA\ralfgro not in 'valid users' [2007/01/26 08:29:10, 2] smbd/service.c:make_connection_snum(580) user 'EMEA\ralfgro' (from session setup) not permitted to access this share (foo) [2007/01/26 08:29:10, 3] smbd/error.c:error_packet(146) error packet at smbd/reply.c(676) cmd=117 (SMBtconX) NT_STATUS_ACCESS_DENIED Maybe I'm missing something obvious here. I just switched to winbind/AD.
Hi, I have reproduced the described behaviour. "valid users = +localunixgroup" works fine for local (not domain) users, because the "S-1-22-2-<GID>" sid is contained in the user token. For domain users, these local sids are _not_ contained in the user token any longer (that changed in 3.0.23). IMHO this works as designed since 3.0.23. Now, local groups created with "net sam createlocalgroup" should be used for local right management. Members can be added with "net sam addmem". Jerry, what do you think? Is this a bug or not? Any chance to fix this? Or are localgroups the correct way to realize the desired behaviour?
(In reply to comment #4) > IMHO this works as designed since 3.0.23. Now, local groups created > with "net sam createlocalgroup" should be used for local > right management. Members can be added with "net sam addmem". > > Jerry, what do you think? Is this a bug or not? Any chance to fix this? > Or are localgroups the correct way to realize the desired behaviour? I agree. Works as expected. Local groups are one solution. >