Mac OS X Permissions Problems with Window Server 2003 R2
Recently I found a problem when using Mac OS X and Windows Server 2003 R2 as a file server. The problem exists in the permissions that are applied to user folders. When applying permissions to shares you normally start out with a very restrictive permission structure at the top. As you create the folders you add permissions for users and groups to permit and restrict access for others. This structure of permissions is very common in dealing with corporate shares. We also share the folder with ‘domain users’ only having change or modify access to the entire share. This eliminates people applying their own permissions and locking everyone out including themselves. This is a common task for a network admin in setting up permissions.
We have a Windows Server 2003 R2 file server with a directory called ‘Drives’ this directory is shared with ‘Domain Admins’ and ‘System’ Full Control and ‘Domain Users’ Change Control. Under this directory the permissions are structures as follows at the NTFS level. Domain Users have Read permissions only to the folder and does not inherit down to other folders. This allows a Domain User to read the directory names, but not access the contents in each of the folders. Each folder at this level is names according to the user that owns the content. On these folders we add the domain user’s username with Change control and we allow the permissions to inherit to all child folders and file below.
The problem exists when you use a script to create the folders and apply the permissions using the cacls.exe command on a Windows 2003 R2 server. A user on a Mac OS X client with not be able to drag files into the folder on a Windows 2003 R2 server share or perform a copy procedure and will result in the error: “You may need to enter the name and password for an administrator on this computer to change the item name “item-name”.”. You may also see the exclamation error if the file has a preview fork attached of “Couldn’t open the file. It may be corrupt or a file format that Preview doesn’t recognize.”. After much reading on this problem I was almost convinced that it was an OS X bug, but I realize now it is actually a flaw in the cacls command. We use a script similar to the snippet of code below to create the directories.
mkdir \\server\share\userdir
cacls \\server\share\userdir /e /t /g userdir:c
explanation:
cacls {file or folder} /e {edits} /t {changes on all sub directories} /g {grants} userdir:c {user:permission of change}
The problem was solved using the command that was introduced in Vista and Server 2003 R2 called icacls.exe. The icacls tool is now included in Windows Server Service Pack 2 and is standard in Vista. This command allows you to set inheritance, which is the root cause of the problem. The inheritance properties were first introduced in NTFS 5.0 with Windows 2000, however something has changed recently in the OS X 10.5 software or Windows Server 2003 R2. The problem also exists in Windows Server 2008 and Windows Server 2008 R2 so the problem is not going away and I am guessing it is OSX at fault.
When setting a directory with the code above, if you use the icacls command to export the permissions structure out to a file you can see the problem. This will export the security into Microsoft’s SDDL language which is documented here http://msdn.microsoft.com/en-us/library/aa379567(VS.85).aspx.
icacls.exe \\server\share\userdir /save aclfile.txt notepad.exe aclfile.txt D:(A;OICI;0x1301bf;;;S-1-5-21-123456789-123456789-123456789-12345) (A;OICIID;FA;;;DA)(A;OICIID;FA;;;SY) (user:chage) (domain admin:full) (system:full)
The problem is not is not evident until we set the permission properly with the icacls.exe command.
icacls \\server\share\userdir /t /c /grant userdir:(OI)(CI)M
explanation:
icacls {file or folder} /t {changes on all sub directories} /grant {grants} userdir:(OI)(CI) {see below}M { change/modify }
CI CONTAINER INHERIT
OI OBJECT INHERIT
NP NO PROPAGATE INHERIT
IO INHERIT ONLY
ID INHERITED
SA SUCCESSFUL ACCESS FLAG
FA FAILED ACCESS FLAG
Complete list http://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx
D:AI(A;OICI;0x1301bf;;;S-1-5-21-123456789-123456789-123456789-12345) (A;OICIID;FA;;;DA)(A;OICIID;FA;;;SY)
Explanation:
D: - Defines the DACL
AI - is the MISSING Auto Inheritance Flag
(A;OICI;0x1301bf;;;S-1-5-21-123456789-123456789-123456789-12345) - is the user’s SID and permissions
(A;OICIID;FA;;;DA) - is the “Domain Admin” permissions identified by the trailing DA
(A;OICIID;FA;;;SY) - is the “System” permissions identified by the trailing SY
The AI in the DACL or Discretionary Access Control List is missing when using the cacls command. My guess is that the client when using Windows is responsible for the completion and writing of the DACL. When a Mac OS X client copies a file they utilize SAMBA which does not carry the DACL and consequentially fails. This would explain the empty file that gets created when an OS X client drags and drops the file. The file entry gets created, but is inherited with only the original permissions that have inheritance from above. This same problem could also exist on Linux or UNIX using SAMBA since it is SAMBA that drops the ball.
The Fix:
Use ‘icacls \\server\share\userdir /t /c /grant username:(OI)(CI)M’ to grant access to NTFS folders and replace all entries in scripts using the cacls command.
September 29th, 2010 at 8:12 pm
I follow your blog site for quite a lengthy time and need to have to tell that your content articles always prove to be of a high value and high quality for readers.