Hi I upgraded a working 4.1.16 configuration with idmap_nss idmap config * : backend = tdb idmap config * : range = 1000001-1999999 idmap config DLR : backend = nss idmap config DLR : range = 1000-1000000 The unixusers/groups are provided by VAS (Quest authentication servers) from the AD. Everythings works as expected, but I am unable to access a share with a force user parameter any more [tmpuser] path = /home_local/tmpuser comment = tmpuser-Share guest ok = no read only = no force group = +XXX\groupname force user = maurerh I got access denied, with force user = maurerh or with force user = XXX\maurerh Without force user I can access the share With force user samba logs Failed to generate session_info (user and group token) for session setup: NT_STATUS_ACCESS_DENIED [2015/01/28 15:22:55.911105, 1] ../source3/auth/server_info.c:628(passwd_to_SamInfo3) The primary group domain sid(S-1-5-21-1156737867-681972312-1097073633-131379) does not match the domain sid(S-1-22-1) for maurerh(S-1-22-1-7740) The SID it claims is the SID of the primary group id of the user maurerh in AD , which could be resolved to the correct groupid [root@rmc-donau samba]# wbinfo --sids-to-unix-ids S-1-5-21-1156737867-681972312-1097073633-131379 S-1-5-21-1156737867-681972312-1097073633-131379 -> gid 43466 [root@rmc-donau samba]# id -a maurerh uid=7740(maurerh) gid=43466(xxx_maurerh_p) groups=43466(xxx_maurerh_p) Regards Hansjörg
this is actually looks like a real regression and is a valid release blocker. Jeremy, can you have a look at this?
Created attachment 11130 [details] Level 10 debug log Same problem here in 4.2.2 (worked great in every 4.0.x and 4.1.x release). This is the share: [testX] path = /testX browsable = yes force create mode = 0660 force directory mode = 2770 force user = firebird force group = firebird guest ok = no valid users = "+MUC\medical office" invalid users = The user and group "firebird" both exist local on this server: # getent passwd firebird firebird:x:84:84:Firebird Database Owner:/opt/firebird:/bin/false # getent group firebird firebird:x:84: Also the account im using to access (muehlfeld), is member of the domain group "medical office". This are the permissions on the folder: # ls -ld /testX/ drwxr-s--- 2 firebird firebird 6 8. Jun 16:36 /testX/ When I try to access this share, I get "permission denied". When I remove either the "force group" or the "force user" line, then it's possible to access the share. Find attached a level 10 debug log from the try to access this share
In this specific case the "force user = firebird" is failing, but the "force group = firebird" is failing with the following error: [2015/06/08 16:37:27.767165, 10, pid=24056, effective(0, 0), real(0, 0)] ../source3/smbd/service.c:343(find_forced_group) firebird is a User, not a group Leading to: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NO_SUCH_GROUP] || at ../source3/smbd/smb2_tcon.c:127 If we look at the code here in master we see: 332 if (!lookup_name_smbconf(talloc_tos(), groupname, 333 LOOKUP_NAME_ALL|LOOKUP_NAME_GROUP, 334 NULL, NULL, &group_sid, &type)) { 335 DEBUG(10, ("lookup_name_smbconf(%s) failed\n", 336 groupname)); 337 goto done; 338 } 339 340 if ((type != SID_NAME_DOM_GRP) && (type != SID_NAME_ALIAS) && 341 (type != SID_NAME_WKN_GRP)) { 342 DEBUG(10, ("%s is a %s, not a group\n", groupname, 343 sid_type_lookup(type))); 344 goto done; 345 } so the user firebird is being returned instead of the group firebird. I'll investigate some more.
Mark, I don't think this is the same problem you're seeing as the original reporter. The code in source3/smbd/service.c:343(find_forced_group) is identical in 4.1.x to 4.2.x and master, so I think you would hit the same problem on 4.1.x. Can you confirm ?
(In reply to Jeremy Allison from comment #4) > Mark, I don't think this is the same problem you're seeing as the original > reporter. I've opened a new Bug (#11320) and attached the 4.2.2 and 4.1.17 logs there.
Hi I attached three debug10 files log.129.247.189.34_withXXXusername with force user = XXX\maurerh set in tmpuser share (not working) log.129.247.189.34_withusername with force user = maurerh set in tmpuser share (not working) log.129.247.189.34_working without force user (working) Regards Hansjörg
Created attachment 11274 [details] debug10 with force user XXX\maurerh
Created attachment 11275 [details] debug10 with force user = maurerh
Created attachment 11276 [details] debug10 without force user (working)
one additional note: the inital tests where performed with 4.2.0rc4 an 4.2.0 I upgraded to 4.2.3 before T took the debug10 logs, with the same error Regards Hansjörg
I'm 100% sure the fix for this is in bug: https://bugzilla.samba.org/show_bug.cgi?id=11320 I just need a reproducer so I can commit Justin's fix. *** This bug has been marked as a duplicate of bug 11320 ***
Created attachment 11287 [details] debug10 with force user XXX\maurerh and patch applied
Created attachment 11288 [details] debug10 with force user = maurerh and patch applied
Hi thank you, I tried the patch form https://bugzilla.samba.org/show_bug.cgi?id=11320 with 4.2.3 but unfortunately it does not solve our force user problem We do not have any user and groups with the same name. Regards Hansjörg
Hi I tried 4.3.0rc4 and I can confirm, that the problem still exists regards Hansjörg
Can you reproduce this without using VAS ? I want to understand if this is an interaction with their service. Thanks, Jeremy.
Hi thank you for your reply would it be sufficient to - disable VAS in nsswitch.conf - stop vas service - add user maurerh in /etc/passwd and group to /etc/group or should I test on a fresh installed system without VAS at all Regards Hansjoerg Maurer
Can you try without VAS at all please ? Also, I need to see the full smb.conf so I can see what you have in your workgroup/realm/netbios name values. This fix that went into 4.3.x is also in a related area. commit 60ea0df0887e686653d4ec944e070bc8be3eaa28 Author: Jeremy Allison <jra@samba.org> Date: Thu Oct 15 09:20:58 2015 -0700 s3: lsa: lookup_name() logic for unqualified (no DOMAIN\ component) names is incorrect. Change so we only use unqualified name lookup logic if domain component = "" and LOOKUP_NAME_ISOLATED flag is passed in. Remember to search for "NT Authority" *before* going into unqualified name lookup logic. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11555 Signed-off-by: Jeremy Allison <jra@samba.org> Reviewed-by: Uri Simchoni <uri@samba.org> (cherry picked from commit 2f6dc260ada6cd178a650ca003c2ad22e12697c1) Might be nice to check with latest 4.3.x also.
Hi ok, installed a fresh centos-7 system with self compiled samba 4.3.1 and without VAS and maurerh in lokal user DB and the error is still the same [root@rmc-cs57 samba]# grep maurer /etc/passwd maurerh:x:7740:43466:Hansjoerg Maurer:/home/maurerh:/usr/local/bin/tcsh [root@rmc-cs57 samba]# grep maurerh /etc/group dlr_maurerh_p:x:43466:maurerh rmc_sysadmin_mf:x:1547:maurerh passwd: files shadow: files group: files more /etc/nsswitch.conf [root@rmc-cs57 samba]# hostname rmc-cs57.robotic.dlr.de [global] workgroup = DLR realm = INTRA.DLR.DE netbios name = RMC-CS57 server string = RMC-CS57 interfaces = 127.0.0.1, eth0 bind interfaces only = Yes security = ADS password server = * username map = /etc/samba/smbusers log level = 1 max log size = 2000000 syslog = 0 log file = /var/log/samba/log.%m machine password timeout = 604800 os level = 25 preferred master = No local master = No domain master = No dns proxy = No encrypt passwords = yes idmap config * : backend = tdb idmap config * : range = 1000001-1999999 idmap config DLR : backend = nss idmap config DLR : readonly = yes idmap config DLR : range = 1000-1000000 max protocol = smb2 wins server = utmp = Yes preserve case = Yes short preserve case = Yes create mask = 0777 directory mask = 0777 hosts allow = XXX hide dot files = No map archive = No dont descend = lost+found load printers= no printing = bsd printcap name = /dev/null use sendfile = yes strict allocate = yes [test] path = /home_local/test comment = Testshare browseable = yes guest ok = no writable = yes wide links = no force group = +DLR\rmc_sysadmin_mf force user = maurerh [root@rmc-cs57 samba]# cat /etc/krb5.conf [libdefaults] default_tkt_enctypes = arcfour-hmac-md5 default_etypes_des = des-cbc-crc default_etypes = arcfour-hmac-md5 default_tgs_enctypes = arcfour-hmac-md5 default_realm = INTRA.DLR.DE dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 36000 renew_lifetime = 864000 ... If I create a directory under [test] form a windows client without the force user its works and user and group are mapped to the correct ID [root@rmc-cs57 samba]# ll /home_local/test/ total 0 drwxrwxrwx 2 maurerh rmc_sysadmin_mf 6 2. Nov 10:48 Neuer Ordner/ With force user (maurerh or DLR\maurerh) I get [2015/11/02 10:47:05.489498, 1] ../source3/auth/server_info.c:396(SamInfo3_handle_sids) The primary group domain sid(S-1-5-21-1156737867-681972312-1097073633-131379) does not match the domain sid(S-1-5-21-1125991651-1650231895-255117594) Next I will test the fix you referred Regards Hansjörg
Hi the patch of https://bugzilla.samba.org/show_bug.cgi?id=11555 is already in 4.3.1 I am testing with. Let me know, if I can provide further information. Regards Hansjörg
(In reply to maurer from comment #19) OK, can you replace the debug 10 logs already posted with debug 10's that correspond to the smb.conf you posted. Also - what machine or domain does the sid : S-1-5-21-1156737867-681972312-1097073633-131379 map to, and what machine or domain does the sid: S-1-5-21-1125991651-1650231895-255117594 map to (you should be able to look this up with wbinfo -s SID) ?
Hi sorry for the inconsistency, the problem occours first on an productive machine with VAS, then we tested it on a test machine with VAS and now on another system without VAS The debug 10 I upload now and the following information refers to the machine rmc-cs57 with the smb.conf I provided today (withou VAS installed) SID S-1-5-21-1156737867-681972312-1097073633-131379 is the SID of the primary group of user maurerh [root@rmc-cs57 samba]# wbinfo -s S-1-5-21-1156737867-681972312-1097073633-131379 DLR\dlr_maurerh_p 2 id -a maurerh uid=7740(maurerh) gid=43466(dlr_maurerh_p) groups=43466(dlr_maurerh_p) SID S-1-5-21-1125991651-1650231895-2551175944 seems to be the localsid of RMC-CS57 (the samba host) [root@rmc-cs57 samba]# wbinfo -s S-1-5-21-1125991651-1650231895-255117594 failed to call wbcLookupSid: WBC_ERR_DOMAIN_NOT_FOUND Could not lookup sid S-1-5-21-1125991651-1650231895-255117594 [root@rmc-cs57 samba]# net getlocalsid SID for domain RMC-CS57 is: S-1-5-21-1125991651-1650231895-2551175944 Regards Hansjörg
Created attachment 11567 [details] debug10 on rmc-cs57 withou VAS installed
Oh, I think this might be the problem: idmap config DLR : backend = nss you're using that to map local UNIX users unknown to the domain DLR into domain sids. Is there such a user DLR\maurerh on the real domain controller ? I'm guessing not.
Hi no, there is a user DLR\maurerh and a group DLR\dlr_maurerh_p on the real Domain Controller wbinfo -u | grep maurerh DLR\maurerh wbinfo -g | grep maurerh DLR\dlr_maurerh_p wbinfo -i DLR\\maurerh DLR\maurerh:*:7740:43466:Maurer, Hansjörg:/home/DLR/maurerh:/bin/false wbinfo -n DLR\\maurerh S-1-5-21-1156737867-681972312-1097073633-27527 SID_USER (1) wbinfo -n DLR\\dlr_maurerh_p S-1-5-21-1156737867-681972312-1097073633-131379 SID_DOM_GROUP (2) And if I (as DLR\maurerh) connect to a share (with force user = maurerh NOT set) and I create a file, it is created with the local uid/gid from above. So the mapping DLR\maurerh -> local maurerh using nss seems to work. Therefore this works, but if I put a force user = maurerh or force user = DLR\maurerh into the share I am unable to connect (since samba version 4.2.0) Even smbstatus shows [root@rmc-cs57 ~]# smbstatus Samba version 4.3.1 PID Username Group Machine Protocol Version ------------------------------------------------------------------------------ 31004 maurerh dlr_maurerh_p 129.247.189.30 (ipv4:129.247.189.30:51361) SMB2_10 Regards Hansjörg
Yeah, doing this is a big problem though. You're making MACHINE\user == DOMAIN\user on this box. Now Samba internally uses a SamInfo3 struct to store data coming from the DC and cache is. Inside that data struct we have: DOMAIN-SID rid-for-user rid-for-primary-group Which mains that the primary group *must* match the DOMAIN-SID-rid-for-primary-group concatenation for that structure to work. The way you're mapping things ends up with SamInfo3_handle_sids() trying to create a SamInfo3 struct with a primary group that doesn't fit the above constraint. So I'm trying to understand what you're trying to do. a). Do you want "force user = DOMAIN\user" and "force group = DOMAIN\group" ? b). Or do you want "force user = MACHINE\user" and "force group = DOMAIN\group" ? The nss backend is mixing up the two in a way that is incompatible. Yes I know it used to work, but that was a bug that got fixed - it shouldn't have. In this case 'backend = nss' is mixing up local users as domain users, and that way lies madness. Remove the: idmap config DLR : backend = nss idmap config DLR : range = 1000-1000000 lines. This is why it isn't working for you, but is for everyone else. Then I want you to try first is to set the force user to be RMC-CS57\maurerh, if you're trying to do (a), or set the force user to be DLR\maurerh if you're trying to do (b). If this doesn't work I'm going to need you to use gdb on an active session so I can get an exact backtrace.
Hi I know using idmap nss might be a strange setup. In our case is was a management decision 8 years ago to connect all unix Systems to the Active Directory using VAS. At this time VAS provides offline logons, user/group filtering, attribute overwrite and GPO's, and we had the same interface to th AD on all Unix plattforms/versions. All Users in AD are unix-enabled (rfc2307) and VAS uses this information and provides them to Linux using nss. Therefore every user/group in unix (provided by VAS) has an user/group in AD with the same name/UID/GID. Similar setup may occur on sites, which have a Metadirectory which provides user/group Information to an AD and to another LDAP based Directory, which acts as the userbase for unix. Therefor to your question what I am trying to do. I want to use the "force user" / "force group" settings in a way, that files creates by a Windows Domain User are created with the UID/GID of the user/group in the "force user" / "force group" setting. If this is (in this case) maurerh, DLR\maurerh or RMC-CS57\maurerh does not matter for our point of view, because the UID of DLR\maurerh or RMC-CS57\maurerh is the same. > So I'm trying to understand what you're trying to do. > a). Do you want "force user = DOMAIN\user" and "force group = DOMAIN\group" ? > b). Or do you want "force user = MACHINE\user" and "force group = DOMAIN\group" ? Ok, I think you are wondering about the combination of force user and force group This migth have been misleading. The problem is that force user does not work, even if there is NO force group set in the share, the force group itself works. Sorry for not explaining this. Here are the 4 cases I tested (with only ONE setting activated at each test) force group = +DLR\rmc_sysadmin_mf -> works, files are created with GID of NSS Group rmc_sysadmin_mf force group = +RMC-CS57\rmc_sysadmin_mf -> does not work, no access to share force user = DLR\maurerh -> does not work, no access to share force user = RMC-CS57\maurerh -> does not work, no access to share Here you can see, that force group = +DLR\rmc_sysadmin_mf works, but I can find no "force user" combination with gives me access to the share. If I remove the idmap config DLR : backend = nss lines completly, how does samba know which UID/GID to use for file operations? I have tried idmap config DLR : backend = ad in order to get the UID/GID directly from AD and not deriving them from Unix (nss) UID/GID s and even in this setup force user = DLR\maurerh or force user = RMC-CS57\maurerh does not work. If you think, that this setup will not be supported any more, no problem. I do not want to waste your time. We only have one share with force user (and we can remove this setting) and force group is working. But especially because of last point (force group still working), I was thinking, that this might be a bug. If you want to trace it down, give me a note and I will provide the gdb output, if not, you can close the bugreport Regards hansjoerg
> If this is (in this case) maurerh, DLR\maurerh or RMC-CS57\maurerh does not matter for our point of view, > because the UID of DLR\maurerh or RMC-CS57\maurerh is the same. What I'm saying is you can't do that with the nss backend. If you want to do that, use username map or something else. In the Windows Domain model, DOMAIN\user != MACHINE\user - and can never be so. That's the underlying reason why Samba is rejecting this setup.
Hi thank you for your reply. Maybe I am misunderstanding something completely, but according to the man page of idmap_nss it says, that idmap_nss ensures, "that the SID for a Unix user named jsmith is reported as the one assigned to DOMAIN\jsmith" Is this only working only in a NT4-style Samba Domain and not with security ADS? Regards Hansjörg
the bug was that was present was fixed. For generic questions beyond the bug report, please see https://www.samba.org/samba/support/