[Samba] Samba 4 AD share: Access denied

[Ryan Ashley]

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