linux client access to samba share where security=ADS

Latest response

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

Hi Norman, welcome to the community. One of our users should be able to offer some advice on this setup.

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.

Hi Tom. thanks for your reply. So how would I best set this up?

We need to support access to both windows clients on 2 seperate stand-alone AD domains as well as Ux access. We don't have SFU, or NIS. Our Ux clients are on seperate subnets from the samba server.

Strange observation last week - had the Linux user (running Centos 6.3) try a few things.
He mounts the cifs share locally providing his Windows creds. He can read and create files however in creating files he gets a Permission denied message but it creates the file anyways. He just cannot modify any file.

The user also need this share to preserve UId/GId permissions as well.

If a cifs mount is not the way to go for this, then I guess we can always setup nfs mounts.

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.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.