[Samba] Samba 4 AD share: Access denied

[Ryan Ashley]

Well, guess I will be configuring PAM! On a side note, I finally got my 
UNIX Attributes tab! I assigned all built-in groups ID's starting at 
20001 and all built-in user accounts ID's starting at 10001. Assigned 
primary groups and all, and it went VERY smoothly. No change though. I 
still cannot access the shares as a normal user. Yes, I did reboot the 
file-server and chown the shares to the new ID's.

Anyway, I will do the PAM configuration now. Just one question. How can 
I prevent login if I do the PAM configuration? Also, why did it work 
without PAM for weeks? On top of that, why do my other locations without 
any PAM configuration work fine and have worked fine for up to two 
years? Seems odd that this one location requires PAM.

On 08/14/2014 02:49 PM, Dale Schroeder wrote:
> On 08/14/2014 1:05 PM, Ryan Ashley wrote:
>> I can do "id", "getent", etc on the file-server and they work fine, 
>> but I do NOT want domain users being able to login to the server so I 
>> did not setup the PAM stuff. Everything else does work though, 
>> including ACLs and resolving groups and such.
>>
>> root at fs01:~# id yolandab
>> uid=10013(yolandab) gid=10003(domain users) groups=10003(domain 
>> users),10032(staff),10031(newmembers),10029(audiovideo),70002(BUILTIN\users) 
>>
>> root at fs01:~# id ernestj
>> uid=10005(ernestj) gid=10003(domain users) groups=10003(domain 
>> users),10030(fbc),10032(staff),70002(BUILTIN\users)
>> root at fs01:~#
>>
>> I have posted countless results of "getent passwd" and "getent 
>> group", but will happily do so again if it helps. I will also add the 
>> PAM stuff to test and will post the results. My understanding 
>> however, was that PAM was only used to physically login to the 
>> system, such as through SSH. Am I wrong here?
> I'm not qualified to say your wrong, but I can say that I've 
> personally never been able to access Samba shares without a properly 
> configured PAM for winbind.  If there is a way to do it, I haven't 
> found it, nor have I found a howto that didn't include PAM 
> configuration as one of the steps for a properly functioning winbind 
> samba client.
>
> Dale
>>
>>
>> Also, is it possible that my AD DB has somehow become corrupted? I 
>> spent some time last night and copied my smb.conf over from a working 
>> domain and tried it on this domain and still got access denied. I 
>> also copied my smb.conf from the non-working server to a working one 
>> and it worked fine there. This tells me that my smb.conf is correct 
>> despite having tons of extra settings that Rowland and Steve had me 
>> add during troubleshooting. I did run a dbcheck on it and it tested 
>> 327 objects and had no errors, but if it is corrupted, would it know?
>>
>> On 08/14/2014 03:56 AM, mourik jan heupink - merit wrote:
>>> On your fileserver, are you able to become or logon as one of your 
>>> regular users? (Either logon directly, or using 'su username')
>>>
>>> Then 'id' to make sure that group memberships are as expected, and 
>>> then try to access your staff share. Samba 'obeys' the acl's on the 
>>> filesystem, we're using those primarily to grant/deny access to files.
>>>
>>> Perhaps those are wrong?
>>>
>>> On 8/13/2014 22:29, Ryan Ashley wrote:
>>>> Alright, I changed the owner of the staff share (files and all) to a
>>>> domain user. The only people in the ACL were the user, domain admins
>>>> group, and staff group. The user was denied access despite owning
>>>> everything. This throws all four of my theories out the window. This
>>>> tells me that ONLY people with domain admin access can access shares.
>>>> What would cause this? I have triple-checked the ACLs and have removed
>>>> the "SYSTEM" account from the ACLs. Currently the owner is the domain
>>>> admin and the domain admins group along with the staff group have full
>>>> control. Still, no domain users can access it. Is there any 
>>>> possible way
>>>> to get Samba to log access denied cases in a log-file the way Windows
>>>> does in an event log? All I know from my standpoint is that Samba is
>>>> denying access to everybody who is not a domain admin, despite having
>>>> ACLs set that said domain admins can manipulate.
>>>>
>>
>