[Samba] Samba 4 AD share: Access denied

[Ryan Ashley]

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.

On 08/13/2014 04:13 PM, Ryan Ashley wrote:
> Alright, I just did a basic test to remove the blame from Windows. I 
> am currently connecting via VPN to this network. Everything appears to 
> work fine. Now, if I use Dolphin in KDE4 to connect to the shares as 
> any domain user, it keeps prompting me for my password. If I use the 
> domain admin I get instant access to the shares. This tells me that 
> this is not a Windows issue since I get the same results in Linux.
>
> Now, this can only mean a few things as far as I know.
>
> 1. Samba is not recognizing that the users are in the global security
>    groups. How would I test this?
> 2. Samba is, for some odd reason, using the owner on the ext4
>    filesystem and nothing else. I guess I can change the owner to a
>    domain user to test this.
> 3. If Samba is seeing users in the groups, it is not using the
>    gidNumber. How can I see what info is being tested for and denied?
> 4. Possibly related, I still have no "UNIX Attributes" tab in ADUC,
>    despite having the attributes in AD. Is it possible something is
>    still missing?
>
> Finally, it is becoming more difficult to search for resolutions to 
> this issue due to this very thread being very popular on Google. 
> Several searches I have done today on mixed terms show half a page or 
> more of this thread, which does nobody any good. We need to find a fix 
> for this so that others with this issue can see a resolution.
>
> On 08/13/2014 03:30 PM, Ryan Ashley wrote:
>> Alright, this is just ODD. I can map the share to a drive without 
>> error. Then when I attempt to access the mapped drive, I get "Access 
>> is denied". On a Windows system I cannot even map the drive if I do 
>> not have access. This tells me that I have access, but once mapped I 
>> get no access. What in the world?
>>
>> On 08/13/2014 03:06 PM, Ryan Ashley wrote:
>>> Still no luck. I even tried adding "valid users = +"TRUEVINE\Staff"" 
>>> to the staff share but no change. I did notice this in my logs though.
>>>
>>> [2014/08/13 14:57:05.551413,  3] 
>>> ../source3/libads/sasl.c:955(ads_sasl_spnego_bind)
>>>   ads_sasl_spnego_bind: got OID=1.2.840.48018.1.2.2
>>> [2014/08/13 14:57:05.551463,  3] 
>>> ../source3/libads/sasl.c:955(ads_sasl_spnego_bind)
>>>   ads_sasl_spnego_bind: got OID=1.2.840.113554.1.2.2
>>> [2014/08/13 14:57:05.551489,  3] 
>>> ../source3/libads/sasl.c:955(ads_sasl_spnego_bind)
>>>   ads_sasl_spnego_bind: got OID=1.3.6.1.4.1.311.2.2.10
>>> [2014/08/13 14:57:05.551514,  3] 
>>> ../source3/libads/sasl.c:964(ads_sasl_spnego_bind)
>>>   ads_sasl_spnego_bind: got server principal name = 
>>> not_defined_in_RFC4178 at please_ignore
>>> [2014/08/13 14:57:05.551621,  3] 
>>> ../lib/krb5_wrap/krb5_samba.c:499(ads_krb5_mk_req)
>>>   ads_krb5_mk_req: krb5_cc_get_principal failed (No such file or 
>>> directory)
>>> [2014/08/13 14:57:05.661384,  3] 
>>> ../lib/krb5_wrap/krb5_samba.c:266(ads_cleanup_expired_creds)
>>>   ads_cleanup_expired_creds: Ticket in ccache[MEMORY:winbind_ccache] 
>>> expiration Thu, 14 Aug 2014 00:57:05 EDT
>>> [2014/08/13 14:57:05.727677,  3] 
>>> ../source3/winbindd/winbindd_msrpc.c:252(msrpc_name_to_sid)
>>>   msrpc_name_to_sid: name=TRUEVINE\STAFF
>>> [2014/08/13 14:57:05.727730,  3] 
>>> ../source3/winbindd/winbindd_msrpc.c:266(msrpc_name_to_sid)
>>>   name_to_sid [rpc] TRUEVINE\STAFF for domain TRUEVINE
>>> [2014/08/13 14:58:08.145175,  3] 
>>> ../source3/winbindd/winbindd_msrpc.c:252(msrpc_name_to_sid)
>>>   msrpc_name_to_sid: name=TRUEVINE\ROOT
>>> [2014/08/13 14:58:08.145234,  3] 
>>> ../source3/winbindd/winbindd_msrpc.c:266(msrpc_name_to_sid)
>>>   name_to_sid [rpc] TRUEVINE\ROOT for domain TRUEVINE
>>> [2014/08/13 15:01:29.069958,  3] 
>>> ../source3/winbindd/winbindd_misc.c:161(winbindd_dual_list_trusted_domains)
>>>   [ 2059]: list trusted domains
>>> [2014/08/13 15:01:29.070074,  3] 
>>> ../source3/winbindd/winbindd_ads.c:1419(trusted_domains)
>>>   ads: trusted_domains
>>>
>>> It tells me nothing but maybe somebody else here can say whether or 
>>> not it is an issue. I Have got to get this up. At this point both 
>>> myself and another Linux IT guy are blaming this on a bug. I mean 
>>> let's look at this from a logical standpoint. The configuration file 
>>> is correct. The ACLs are correct. Users and groups resolve. It just 
>>> flat out denies access to anybody EXCEPT the domain admin.
>>>
>>> On 08/13/2014 09:51 AM, Ryan Ashley wrote:
>>>> I already tried removing it from the global section. I had the same 
>>>> idea you do. Unfortunately, the only thing testparm shows as being 
>>>> recognized is the path, comment, and read only flag. Still does not 
>>>> work. I did open a bug report since I have now been through this 
>>>> LONG email chain twice and tried everything as well as my 
>>>> variations on everything several times now. It just seems to want 
>>>> to deny access. I wish it was just denying it to 7, so I could 
>>>> blame 7, but it denies access to all OSes including my Android 
>>>> phone and my Debian Wheezy laptop.
>>>>
>>>> Thanks for your help, but I am not up yet. Maybe we'll get it 
>>>> sooner rather than later. Also, I have set all shared directories 
>>>> to 777 and all files in said directories to 666 until we get it 
>>>> working. Then I can worry about locking it down.
>>>>
>>>
>>
>