Linux File Sharing in a Microsoft Active Directory Domain

Access Control


Introduction

When you use SAMBA to provide file sharing to Windows clients in an Active Directory domain, you need to be aware that, although on the surface it looks pretty much like filesharing of a Windows Server, underneath it is a Linux (or Unix) filesystem, with its own ways of handling files, directories, file and directory ownership, and file and directory access (read, modify, ...).

One way of dealing with it is to manage all this strictly from the Unix side. However, your users will create, modify, copy, move, ... files from their windows workstations, so there will always be Windows-style operations that need to be translated to a Unix/Linux filesystem.

Samba also allows file management from windows clients, such as modifying security on shared files or directories, through Windows Explorer. Again, these modifications need to be translated to something that can be implemented on a Unix filesystem.

Likewise, changes executed on the Unix side, using Unix tools to modify user and group permissions on files and directories, will need to be represented accurately in a Windows environment.

Samba manages this partially by mapping NTFS features to unix properties, and partially by implementing some access control of its own, and you can manually add unix filesystem specific settings on top of it. As a system administrator, you will need to understand this combination in order to adequately manage file access control, and to ensure that moved, copied and newly created files have adequate read and write permissions for the appropriate users and groups.


It is assumed you have a reasonable knowledge of Windows file sharing and NTFS ACL's, are capable of setting up basic file sharing with Samba, can manage to integrate Samba in an Active Directory Domain, and understand the basics of unix file ownership and permissions.

Here, we'll deal with the complexities of managing user access to files and directories on a Unix (Linux) system, serving files to Windows clients.


Using basic Unix permissions

In Unix filesystems, administrators assign read (r), write (w), and execute (x) permissions to files, to a file's owner, to users in a specified group, and to "all the rest"others. This scheme is simple and effective, but sometimes requires elaborate directory structures to model an appropriate permission system.

On the other hand, Windows sysadmins are used to being able to use multiple groups or even individual users in ACL's, and to pick and choose between up to 15 different permissions for each of them. Although this does not necessarily result in an easier management, the mechanisms itself allow for rather fine-grained configuration without resorting to complex directory trees. Especially when you are migrating from Windows Filesharing to Samba, the straightforward permission bits ('minimal' ACLs) on Unix might seem too limited.

basic unix file permissions will show up in Windows as read, write, execute, for a user (unix owner), a group (the unix group, defaults to the primary group of the owner), and "Everyone".

You can influence those with

Case study : Personal Files

Case : you have an active directory domain with Windows 200x file servers. Each AD user has a 'home' folder for personal use on one of your windows file servers. You've decided to migrate those to a Samba AD member server. You've setup winbind to let samba/linux recognise AD usernames, but these users don't have access to the server other than through samba - they are not Linux accounts, and do not have unix /home directories. In stead, you've created a share "personal" pointing to /srv/smb/personal, so that your windows accounts can map their home drive h:\ to \\sambaserver\personal\account_name

How to handle file access control - using Samba controls and basic unix filesystem tools and file mode permissions ?

First check umask, do see with what permissions new files and directories are created

	# umask
	0022

this means :
new file : 644 = rw- r-- r--
new dir : 755 = rwx r-x r-x

problem: every new file and directory will have

Files copied from a windows file server (during migration to samba) are treated as new files and will be owned by the account that copies them (eg administrator & member of Domain Users or Domain Admins) so users will have no write rights to their "own" files, but everybody can read them. This will need to be fixed.

Changing umask will have system-wide effects, so that may not be the best choice.

You can use the samba "force group" directive to force the group to "nogroup", in order to get rid of default domain users group.
However, a cleaner way is to let samba set default permissions :

		create mask = 700			#includes 'execute' to result in 'full Control" in Windows, 
									#although it's uncommmon for unix

		directory mask = 700		#includes 'execute' to provide directory traversal and listing (required)

These masks indicate what permissions a file or a directory will get when it's created through a samba share.

The above masks seem sufficient for our purpose. If not, there's also 'force security mask' ; this sets bits in modes even if the user (from windows, through samba) forgets to set them or tries to unset them. see the samba manual.

Because it's samba setting the permissions bits according to the create or directory mask on the share, you have to be careful with nested shares, i.e if a directory is shared directly but is also the subdirectory of another share. Depending on how (through which share) the directory was accessed by the client, different masks may apply if the shares ware configured with different create or directory masks.
On the other hand, this may create opportunities for creative access control, but it can become messy very quickly.

This setup will provide users with a directory that they own and fully control, while no other group or user has access. Files created by the user will have the same permissions. However, if you're migrating files off a Windows server and you're copying them as Administrator, they'll be owned by Administrator, so you'll have to chown them.

migration procedure

create a parent directory in which each user will have its personal directory (eg /srv/smb/personal )/-. Chown or chgrp this directory root:Domain Users, so that Domain users have read and directory traversal rights, allowing them access into their personal directory

chmod o-rwx /srv/smb/personal , to exclude "Everyone".

Next, you need to create directories for each user. Using the user logon name as directory name greatly simplifies scripting. Avoid names with spaces or special characters unless you want to make scripting / automation a pain below the back

#on Unix samba server:
	for NAME in list_of_names; do
		mkdir /srv/smb/personal/$NAME
	done
#on Windows file server
#copy files from old location (from server, as administrator) to Samba server

		cd E:\data\homedirs
		xcopy username\* \\server\personal\username\ /E /C /H
		
#automation:
for %%i in username
		xcopy %%i/* \\server\personal\%%i\ /E /C /H
#on Unix samba server:	
	
	DOMAIN="YOUR_DOMAIN"
	
	for ITM in list_of_names  ; do 
	 	chmod -R 700 $ITM; 
	 	chown -R ${DOMAIN}+${ITM}:${DOMAIN}+domain\ users $ITM; 
	done

Lastly, on Windows AD, change the AD user account: set a new path for home directory : \\sambaserver\personal\%username%. This will trigger a warning (folder exists), but you can ignore that. You can also use a script against Active Directory to reset the home folder path for all users.

note that this configuration allows automatic creation of home dirs from within the ADUC mmc. Very convenient for new accounts created by hand.

Access Based Enumeration and Hidden Files

You can prevent users from actually seeing directories or files they don't have read access to, use hidden unix dot files, etc and let Samba hide those from its users

		hide dot files = yes
		hide unreadable = yes

Extended ACL

By installing support for POSIX ACL on your samba server, you gain the ability to assign more than one user or group to a file. POSIX ACL for directories can also assist in defining what the ACL of a newly created file in that directory will be. This comes very close to what Windows admins expect, but there are some differences, as Windows ACL is not exactly POSIX compliant.
All the while, Samba's own access Control and the unix tools mentioned earlier, still apply, which sometimes helps, and sometimes gets in the way.

What follows is mostly based on the following sources:
Unofficial Samba ACL Howtow
Linux Posix ACL
Samba Manual : Access Controls

extended POSIX ACL add to the Unix file mode permission bits. The unix permissions themselves are included in the ACLs (usually referred to as 'minimal ACL"), and look like this

#Unix representation
server:/srv/smb/personal# ls -al somefile.txt 
-rwx------ 1 MYDOMAIN+jbg MYDOMAIN+domain users 8497 2008-05-13 19:07 somefile.txt

#POSIX ACL representation:
server:/srv/smb/personal# getfacl somefile.txt  
# file: somefile.txt 
# owner: MYDOMAIN+jbg
# group: MYDOMAIN+domain\040users
user::rwx
group::---
other::---

This can be extended with "named users" and "named groups", eg

server:/srv/smb/personal/jbg# getfacl samplefile 
# file: samplefile
# owner: root
# group: MYDOMAIN+domain\040users
user::rwx
user:MYDOMAIN+jdoe:r-x
group::---
group:MYDOMAIN+somegroup:rwx
mask::rwx
other::---

How do we read this:

user::rwx
permissions of user/owner : jbg- basic Unix
user:MYDOMAIN+jdoe:r-x
permissions of an additional named user jdoe (extended ACL)
group::---
permissions of the primary user group - basic Unix
group:MYDOMAIN+somegroup:rwx
permissions of an additional named group
mask::rwx
permission mask-see further
other::---
permission for other -basic Unix ("world")

mask : permissions in POSIX ACL use a mask. The effective permissions are the permissions that are present both in the mask and in the users, groups or others permissions, eg

	group::---
	mask::rwx		#effective group permission= ---
	
	##but also
	
	user::rwx
	mask::r--		#effective user permission : r--

the mask defaults to all bits/permissions of users, groups and others combined, thus doing nothing at all, but can be modified with setfacl.

ACL default permissions

apart from the actual access permissions, you can set default permissions on directories. The default permissions of a directory will be applied to newly created (sub-)directories and files in the directory in question.

This provides a mechanism to let permissions on directories propagate to (be inherited by) the contents of that directory. (With basic Unix permission bits, this could be accomplished by chmod g+s on the directory, setting the SGID bit so that a directory is "executed" with the permissions of its group, rather than of the group the user belongs to)

server:/srv/smb/personal/test1# getfacl sampledir/
# file: sampledir
# owner: MYDOMAIN+test1
# group: MYDOMAIN+domain\040users
user::rwx
group::---
group:MYDOMAIN+somegroupk:r-x
group:MYDOMAIN+othergroup:rwx
mask::rwx
other::---
default:user::rwx
default:user:MYDOMAIN+test1:rwx
default:group::---
default:group:MYDOMAIN+somegroup:r-x
default:group:MYDOMAIN+othergroup:rwx
default:mask::rwx
default:other::---

defaults are calculated by setfacl when applying membership, but can be modified manually, with setfacl

If you need to troubleshoot this, it's probably best to troubleshoot on the unix side, because the windows security dialogue is just a (sometimes imperfect) representation of file mode permissions, posix acls, and samba access controls.

Migration from Windows

what we aim for is one share, containing subdirectories each readable and writeable by specific groups; like


	shared
	  |-finance			* only accessible by groupFinance
	  |-hrm				* only accessible by groupHRM
	  |-generalinfo		* writeable by groupHRM, readable by all Domain Users

In contrast to Windows, you can not give ownership to a group, because this doesn't map to the unix ownership scheme (user:group). In stead, we can have directories
owned by user Domain Admin or root
group domain admins or domain users, with appropriate rights
+ named groups with read access
+ named groups with write access
+ mask rwx to not block anything inadvertedly
+ default ACLs to propagate settings to newly created subdirs and files

FIXME: ## check : needs directory execute for Domain Users so may need chown if created in Unix. test and adjust procedure accordingly

first we create the directory "shared" and share it through samba; we'll use only 1 share and manage access through subdirectories thereof. On the Windows side, you can map drive letters to \\server\share\subdirectory, or you can set hide unreadable = yes " in smb.conf, and map to \\server\shared : windows users will only see the directories they have (read) access to. Keeps it clean and simple.

This is what the shared directory looks like when we first create it :

initial situation:
server:/srv/smb# getfacl shared
# file: shared
# owner: root
# group: MYDOMAIN+domain\040users
user::rwx
group::r-x
other::r-x

we then set access ACL and defaults for the directory 'shared' :

	chmod o-rwx shared/
	chgrp MYDOMAIN+domain\ users shared/

	setfacl -m default:other::--- shared/
	#setfacl -m d:g:MYDOMAIN+domain\ admins:rwx shared/	#optional
	setfacl -m default:g::rwx shared/						#groups added with rwx automatically

This is the result

server:/srv/smb# getfacl shared
# file: shared
# owner: root
# group: MYDOMAIN+domain\040users
user::rwx
group::r-x
other::---
default:user::rwx
default:group::rwx
default:other::---

a newly created subdirectory of shared will look like this:

server:/srv/smb/shared# getfacl hrm
# file: hrm
# owner: root
# group: root
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---

we add a group with "full Control" (eg via security dialog in Windows, or with setfacl on unix)

server:/srv/smb/shared# getfacl hrm
# file: hrm
# owner: root
# group: root
user::rwx
group::rwx
group:MYDOMAIN+groupHRM:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:MYDOMAIN+groupHRM:rwx
default:mask::rwx
default:other::---

note how a named group is added with rwx, and included in the defaults so that subdirectories and files will have the same rights for that group

server:/srv/smb/shared# getfacl hrm/*
# file: hrm/usercreatedfile
# owner: root
# group: MYDOMAIN+domain\040users
user::rwx
group::---
group:MYDOMAIN+groupHRM:rwx
mask::rwx
other::---

# file: hrm/usercreatedfolder
# owner: root
# group: MYDOMAIN+domain\040users
user::rwx
group::---
group:MYDOMAIN+groupHRM:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:MYDOMAIN+groupHRM:rwx
default:mask::rwx
default:other::---

Add an additional group with readaccess

server:/srv/smb/shared# getfacl announce/
# file: announce
# owner: root
# group: MYDOMAIN+domain\040users
user::rwx
group::---
group:MYDOMAIN+groupFinance:r-x
group:MYDOMAIN+groupHRM:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:MYDOMAIN+groupFinance:r-x
default:group:MYDOMAIN+groupHRM:rwx
default:mask::rwx
default:other::---

As seen before, when you migrate data of a Windows file server to this Samba file server, the copied files will be treated as newly created files, and the default ACLs will enable the required permissions relevant to the target directory. So migrating the data is a simple copy action. Unlike Windows ACLs, POSIX ACLs will not let you give ownership to a group, because the underlying Unix filesystem expects a user to be owner. So it's not exactly the same as on Windows, but you can create an appropriate solution anyway.

Difference between files created through Unix and files created through Samba

When creating files or directories from a Unix session (mkdir, touch, cp, mv, ...), Unix rules apply. When creating a file or directory through a Samba share, Samba's rules are superimposed, and the result may differ between both methods.

### file created in unix shell:

	getfacl unixmade
		# file: unixmade
		# owner: root
		# group: root
		user::rwx
		group::rwx
		other::---
		default:user::rwx
		default:group::rwx
		default:other::---

### file created on Windows workstation, through samba

	getfacl sambamade
		# file: sambamade
		# owner: root
		# group: MYDOMAIN+domain\040users
		user::rwx
		group::---
		other::---
		default:user::rwx
		default:group::rwx
		default:other::---

Note the difference in group permissions (effect of samba's create or directory mask). Also, the "root" owner on the samba created file is a translation of Administrator ('admin user = Administrator' translates 'Administrator' to 'root'), and the samba created file gets the group of the Administrator account (Domain Users) while the unix created file gets group 'root'.

case study : migrating shared folders from Windows to samba with Posix ACL

Given all of the above, migrating files of a Windows file sharing server to a Samba file server, should be a simple XCOPY routine; all the rest is pre-setup in ACL and samba.

Of course, you'll also need to replace UNC paths in login scripts, drive letter mappings, and everywhere the old server is referenced.

Personal files on a file system with extended ACL

If you do the "personal files" configuration on a system with posix extended acl, you need to set (or at least check) default acls so that newly created files and directories get the correct security settings.

The parent directory (/srv/smb/personal) has to be writable by DOMAIN\Administrator for the creation of new user home directories, eg when creating them from ADUC. This is automatically covered if you've mapped Administrator to root. The parent directory should also have rx (or just x ?) for domain users, to let them traverse to their home directory

The home directory itself should be owned + full control by user, nothing else.

getfacl /data/personal/
	# file: data/personal
	# owner: root
	# group: MYDOMAIN+domain\040users
	user::rwx
	group::r-x
	other::---

Creating a new directory from Unix :


cd data/personal
mkdir test
getfacl test

	# file: test
	# owner: root
	# group: root
	user::rwx
	group::r-x
	other::r-x

chown MYDOMAIN+jbg:nogroup test
chmod 700 test

getfacl test
	# file: test
	# owner: MYDOMAIN+test1
	# group: nogroup
	user::rwx
	group::---
	other::---
	

user home automatically created from Windows ADUC:

getfacl testSamba/
	# file: testSamba
	# owner: MYDOMAIN+test1
	# group: MYDOMAIN+domain\040users
	user::rwx
	user:MYDOMAIN+test1:rwx
	group::---
	mask::rwx
	other::---
	default:user::rwx
	default:user:MYDOMAIN+test1:rwx
	default:group::---
	default:mask::rwx
	default:other::---

Note how the ADUC created home directory automatically sets the correct ACLs.

Conclusion

It's perfectly possible to provide file serving to Windows clients in an Active Directory environment, by means of a Unix file server with Samba. However, expecting it to work as a (free, cost-free) Windows replacement, may result in unexpected behavior. It's necessary to treat the infrastructure as what it is : a Unix file system with posix ACL, made available to windows clients through Samba. Even when you use Windows tools (eg Microsoft Explorer File Security dialog) to manage the ACLs, you better be aware that you're editing POSIX acl's or Unix file mode permission bits. It's also perfectly possible (and probably advisable) to set up your main file sharing structure from a Unix session, and only do the occasional changes or additions from Windows.


Benefits of using Linux/Samba ?

Apart from the obvious benefits (open source solutions, no or low license costs, the ability to build a lean, dedicated server without the overhead of a full blown Windows server, ...), a Linux-based file server offers you all the scripting capacities of the Linux shell, and the opportunity to take advantage of Linux filesystem features, such as hard and symbolic links.

E.g. you can create symbolic links on the file server and your Windows clients will see them as real directories rather than Windows shortcuts, and use them transparently : you can have the clients see subdirectories in a share while in reality, this subdirectory resides elsewhere on the server. The organisation of files and directories as seen by the clients / users / user programs can differ from the organisation of files and directories on the server. On the flip side, this has then the disadvantage that windows tools will be unable to distinguish between a link and a real directory, so Windows based backup programs and the likes may backup the same content twice, or get caught in recursive loops.


Koen Noens
September 2008