[Samba] Samba 4 AD share: Access denied

Ryan Ashley ryana at reachtechfp.com
Wed Aug 13 13:30:45 MDT 2014 

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.
>>
>> On 08/13/2014 12:30 AM, Davor Vusir wrote:
>>> 2014-08-12 23:06 GMT+02:00 Ryan Ashley <ryana at reachtechfp.com>:
>>>> Just so you know, those attributes only work in the global section. 
>>>> I added
>>>> them to my shares, but it does not use them. I was still unable to 
>>>> access
>>>> said shares after rebooting the member server to insure the changes 
>>>> were
>>>> accepted.
>>>>
>>> Sorry to hear that. I guess I'm out of ideas. For now...
>>>
>>>> root at fs01:~# testparm /etc/samba/smb.conf
>>>> Load smb config files from /etc/samba/smb.conf
>>>> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit 
>>>> (16384)
>>>> Processing section "[install$]"
>>>> Processing section "[staff$]"
>>>> Processing section "[fbc$]"
>>>> Loaded services file OK.
>>>> Server role: ROLE_DOMAIN_MEMBER
>>>> Press enter to see a dump of your service definitions
>>>>
>>>> [global]
>>>>          workgroup = TRUEVINE
>>>>          realm = TRUEVINE.LAN
>>>>          security = ADS
>>>>          ntlm auth = No
>>>>
>>>>          dedicated keytab file = /etc/krb5.keytab
>>>>          kerberos method = secrets and keytab
>>>>          local master = No
>>>>          domain master = No
>>>>          winbind enum users = Yes
>>>>          winbind enum groups = Yes
>>>>          winbind use default domain = Yes
>>>>          winbind nss info = rfc2307
>>>>          idmap config TRUEVINE:range = 10001-40000
>>>>          idmap config TRUEVINE:schema_mode = rfc2307
>>>>          idmap config TRUEVINE:backend = ad
>>>>          idmap config *:range = 70001-80000
>>>>          idmap config * : backend = tdb
>>>>          map acl inherit = Yes
>>>>          store dos attributes = Yes
>>>>          vfs objects = acl_xattr
>>>>
>>>> [install$]
>>>>          comment = "Software installation files"
>>>>          path = /home/shared/install
>>>>          read only = No
>>>>
>>>> [staff$]
>>>>          comment = "Staff file share"
>>>>          path = /home/shared/staff
>>>>          read only = No
>>>>
>>>> [fbc$]
>>>>          comment = "Family Bible College file share"
>>>>          path = /home/shared/fbc
>>>>          read only = No
>>>>
>>>> As you can see, testparm ignores them in the share sections. I will 
>>>> remove
>>>> them since they do not work.
>>>>
>>> What happens if you remove them from the global section and only have
>>> them in the share sections?
>>>
>>> Regards
>>> Davor
>>>
>>>> On 8/12/2014 4:57 PM, Ryan Ashley wrote:
>>>>> I do not have those attributes on my actual AD DC, only on my member
>>>>> servers. I followed the guide to the letter and put them in 
>>>>> global, but I
>>>>> will happily try putting them in the share section as suggested. 
>>>>> If it works
>>>>> I will let you know. Thanks for the help. If this fixes it I will 
>>>>> also
>>>>> update my ticket and advise the guide be updated.
>>>>>
>>>>> On 8/12/2014 4:29 PM, Rowland Penny wrote:
>>>>>> On 12/08/14 20:41, Davor Vusir wrote:
>>>>>>> In my first setup, a combined (compiled) AD DC and file server I 
>>>>>>> never
>>>>>>> got it to work with "vfs objects = acl_xattr" in the global 
>>>>>>> section. I
>>>>>>> had two more shares and could not get the permissions to work 
>>>>>>> until I
>>>>>>> put "vfs objects = acl_xattr" in the share sections. The shares 
>>>>>>> were
>>>>>>> on LVM volumes mapped to directories later shared with Samba. My
>>>>>>> conclusion is that "vfs objects = acl_xattr" in the global 
>>>>>>> section on
>>>>>>> a AD DC does not extend (or how to put it) beyond the netlogon and
>>>>>>> sysvol shares. I have not tested this configuration on one (1) 
>>>>>>> mounted
>>>>>>> LVM volume where /usr/local and Sambashares reside.
>>>>>>
>>>>>> If you add "vfs objects = acl_xattr" to smb.conf on a Samba 4 AD 
>>>>>> DC, you
>>>>>> are turning off the 'dfs_samba4' vfs module. If you run 'testpam
>>>>>> --suppress-prompt --verbose', you will find 'vfs objects = 
>>>>>> dfs_samba4,
>>>>>> acl_xattr'.
>>>>>>
>>>>>>> I have now changed the setup to a dedicated virtual AD DC and a
>>>>>>> physical file server because of poor network performance. After the
>>>>>>> switch I experienced the same; proper permissions denies 
>>>>>>> access... The
>>>>>>> setup is still the same; mounted LVM volumes later shared with 
>>>>>>> samba.
>>>>>>> By removing "vfs objects = acl_xattr, map acl inherit = Yes and 
>>>>>>> store
>>>>>>> dos attributes = Yes" from the global section, as mentioned in
>>>>>>>
>>>>>>> https://wiki.samba.org/index.php/Setup_and_configure_file_shares_with_Windows_ACLs, 
>>>>>>>
>>>>>>
>>>>>> You only add these line to a member server, they are not required 
>>>>>> on the
>>>>>> AD DC.
>>>>>>
>>>>>> Rowland
>>>>>>
>>>>>>> and instead putting "vfs objects = acl_xattr" in the share section
>>>>>>> solves it. If you are using more vfs objects you may have to 
>>>>>>> reorder
>>>>>>> them. And I also noticed that removing Everyone from the Share tab
>>>>>>> will neither let you edit nor remove ACE:s in the Security tab. So
>>>>>>> first let Everyone be there, add Domain Admins, press Apply. Add
>>>>>>> Domain Admins to the ACL, press Apply. Take ownership. After this
>>>>>>> procedure you are able to edit ACE:s. This will not guarantee that
>>>>>>> inheritence is correct. Again, "vfs objects = acl_xattr" in the 
>>>>>>> global
>>>>>>> section does not seem to extend beyond global section. And I'm not
>>>>>>> sure why "map acl inherit = Yes and store dos attributes = Yes" 
>>>>>>> are in
>>>>>>> the global section (I'm using neither). Both belongs to a share
>>>>>>> section according to
>>>>>>> http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html.
>>>>>>>
>>>>>>> Hope it helps.
>>>>>>>
>>>>>>> Regards
>>>>>>> Davor
>>>>>>>
>>>>>>>
>>>> -- 
>>>> To unsubscribe from this list go to the following URL and read the
>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>

More information about the samba mailing list