linux client access to samba share where security=ADS
We need to setup share access to both Ux and Windows clients from 2 seperate domains. User authenication to be controlled by Windows AD credentials. We are not running any Services for Ux on Windows DCs, no LDAP, etc. Ther eis a windows trust between the 2 domains.
The reason for using windows creds is to avoid having to create local Ux accounts on the samba server.
We've setup samba on a RH 6.4 server using security=ADS (Windows domain) with access to a share controlled by group membership. As it is, the setup works for windows client access from both domains however Ux users are getting permission denied in write operations. They can mount and read. (On Ux client side there are mounting a CIFS share.)
What needs to be in place/configured in order to allow user access to the same share from both Ux and Windows? (Client or server config change)
My current samba config -
[global]
workgroup = DEVENG
netbios name = arc
bind interfaces only = yes # to get rid of host/address mismatch
interfaces = lo eth0 127.0.0.1 10.128.xx.xx/24
hosts allow = 127. 10.128. 192.
smb ports = 139 445
----------------------- Domain Members Options ------------------------
realm = DEVENG.LOCAL
security = ADS
encrypt passwords = yes
password server = *
template shell = /bin/bash
idmap uid = 500-1000000
idmap gid = 500-1000000
winbind use default domain = yes
winbind nested groups = yes
----------------------- Browser Control Options ----------------------------
local master = no
preferred master = no
os level = 33
============================ Share Definitions ==============================
[neteng]
comment = Network Engineering share
path = /fs_neteng
browseable = yes
writable = yes
valid users = @Neteng
And the kerbos config:
/etc/krb5.conf
[libdefaults]
default_realm = DEVENG.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
DEVENG.LOCAL = {
kdc = DEVENGDC1.DEVENG.LOCAL
}
[domain_realm]
.DEVENG.LOCAL = DEVENG.LOCAL
Responses
What are you doing to account for ID-mapping?
The Samba config you transcribed really only addresses how to map an AD user or group SID to a Linux uid or group id. This is done primarily for the purposes of allowing an AD-managed user to login to the Linux system and to control filesystem access within the context of the Linux host. Samba is taking care to give you a local-to-the-Linux host that is computed from the SID in a way that is unique within the context of the Linux host. It gives you, for example, access rights to your Linux user account's local home directory.
Unfortunately, this mapping is really only one-way: the remote CIFS share-server doesn't map your Linux uid/gid back to an AD SID. Without that SID, your attempts to access are essentially done as an anonymous or "every" user-mapping. You'd need to set up a bi-directional/global idmap service within your domain to ensure that the CIFS server is able to match your access request to a SID that has rights to the share and sub-objects.
If you mount a cifs share as a given user (i.e., mount -t cifs -o domain=DOMAIN,user=USER "//CIFSSERVER/SHARE" /Some/Local/Mount/Point) then all file operations will happen as DOMAIN\USER. Assuming that DOMAIN\USER has rights to the share, then writes can happen as expected. ANY Linux-user that writes to that mountpoint will get handled as though the writes came from DOMAIN\USER.
Things get a lot more complex when you're trying to do discretely-permitted writes (i.e., LinuxUser1 maps to ADuser1; LinuxUser2 maps to ADuser2; etc.). That's where you have to do IDmapping. For this, you'd need to look at tools like cifs.idmap.
I'm adding this to a 3-year old discussion... anyone dropping into this, certainly see tips above from Tom.
That being said, I used the documentation to join a samba server for RHEL 6.7 using net ads join (do configurations first!, see documentation), and it worked fine. .
Additionally, see this Red Hat Solution regarding BadLock vs Samba https://access.redhat.com/solutions/2260591
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
