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

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
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.

(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

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.

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