One of the biggest challenges for new system administrators, whether running SBS or another of the Windows Server products, is understanding how permissions on files and folders works. Even those who have worked with Windows server products for years can get confused from time to time. The next two sections of the chapter cover the basics of both NTFS file permissions and share permissions and the interaction between the two. It also covers the default NTFS and share permissions on several key directories unique to an SBS installation.
NTFS File Permissions
Prior to Windows NT, the Microsoft Windows file system had no security. Anyone who could physically access the PC could access all files on the volume. With Windows NT, Microsoft introduced the NT File System (NTFS) and the concept of file-level security to workstations and servers. The implementation of NTFS has matured with each release of the server product line, but the essential principles remain the same.
NTFS permissions can be applied at the file or folder level. These permissions can be viewed or modified in the Security tab of the object properties window. Figure 9.1 shows the default NTFS permissions on the root of drive C: on an SBS 2003 installation. Figure 9.2 shows the permissions for the file boot.ini in the root of drive C:. As you can see in the two figures, different permissions are available for volume/folder permissions than for file permissions. Tables 9.1 and 9.2 outline the permission settings for both the volume/folder permissions and file permissions.
Figure 9.1. NTFS permissions for the C: volume in a default SBS installation.
Applying NTFS Permissions
Viewing and modifying the NTFS permissions on a file or folder is done through the Security tab of the Properties page on the file or folder, as shown previously in Figures 9.1 and 9.2. Different permissions can be applied to different security groups or individual user objects as necessary.
Figure 9.2. NTFS permissions for the boot.ini file.
Some special security groups exist in this realm that are not used elsewhere in a Windows network. One in particular is the Creator/Owner group. The membership of this group cannot be modified directly. Instead, when a user creates a file in a folder, that user becomes the creator/owner of that file, and permissions assigned to that group apply to that user for the files she owns in the folder.
Permission assignments are cumulative. For example, suppose that the account jondough is a member of both the Domain Users group and a custom group called Accounting. In a directory on the server where accounting files are stored, the Domain Users group is given Read permissions but nothing else. The Accounting group is given Write permissions but nothing else. The effective permissions for jondough, because he is a member of both groups, are Read and Write for the files in the folder.
Allow and Deny Permissions
When assigning permissions to a user or group, you can choose to Allow or Deny the permission in the assignment. Selecting Allow in the permissions list grants the permission to the user or group. Selecting Deny in the permissions list revokes that permission from the user or group. The Deny permission almost always overrides an Allow permission when an object has both permissions assigned through multiple groups.
Taking another look at the example in the previous section, suppose that the system administrator wanted to make sure that Domain Users could not write to any files in the Accounting folder and only members of the Accounting group could. If the system administrator assigns the Deny Write permission to Domain Users, the user jondough would not be able to write to any files in the folder. His effective permissions would be Allow Write from the Accounting group and Deny Write from the Domain Users group, and because Deny takes higher priority over Allow, he would not be able to write to any files in this folder.
Using the Deny permission without careful forethought can lead to significant problems with file permissions. If Deny permissions are assigned to the Domain Users group, every account in the domain will be locked out of that permission for that folder. For that reason, it is best not to apply the Deny permission to Domain Users for anything other than Read and Write permissions. If the Deny permission is applied to Modify or Full Control for the Domain Users, the folder effectively becomes locked out for all users because no account would then have permission to go back in and make changes to the permissions on the objects.
When permissions are set on a folder, those same permissions also apply to all the files and subfolders within that folder as well. By default, all objects in a folder inherit the permissions of the parent folder unless a separate set of permissions has been applied to the object. When viewing the permissions of an object, inherited permissions appear grayed out in the Security tab, indicating that those permissions were applied to one of the parent folders of the object.
Inherited permissions for an object can be turned off in the Advanced Security Settings window. Click on the Advanced button in the Security tab to open this dialog. Figure 9.3 details the Advanced Security Settings dialog for the C:\Windows\config folder.
Figure 9.3. The Advanced Security Settings window.
In the Permissions tab, you can see all the security groups that have been granted permission to the folder and the location from which the permissions were inherited. The Allow Inheritable Permissions from the Parent to Propagate to This Object and All Child Objects check box is enabled, indicating that this folder should inherit all permissions from the parent folder, which is C:\Windows in this case. If any additional permissions had been assigned at this level, this check box would also propagate those permissions to child objects in addition to the inherited permissions.
If you wanted to remove permission inheritance and create a completely new set of permissions on the folder, click this check box to turn it off. On doing so, you are presented with a Security dialog box asking what you want to do with the permissions. You can Copy the permissions, which creates a new set of permissions matching the settings that had been inherited, or Remove the permissions, which clears all settings. If you choose to Remove the settings, be sure to grant sufficient settings that you can later go back and modify the permissions before you apply the changes and close the Properties dialog. Doing this without granting additional permissions first can yield the folder inaccessible.
With Windows 2003, the permission inheritance rules for the Deny permission were modified slightly. In previous NTFS implementations, a Deny permission applied to all subfolders and files through inheritance and could not be overridden. In the 2003 implementation, however, an explicit Allow permission can override an inherited Deny permission. Going back to the example used earlier in the chapter, if the Domain Users group is given the Deny Write permission on the Accounting folder, no users in the domain will be able to write to any files within that folder. Suppose that a subfolder of Accounting, called 2005 for example, has the Allow Write permissions assigned to the Accounting group. Even though the Deny permission is inherited from the parent folder, the explicit Allow Write permission overrides the Deny, and members of the Accounting group will be able to write to files in the 2005 folder.
In addition to the standard permissions listed previously in Tables 9.1 and 9.2, Special Permissions can be applied to a file or folder. These Special Permissions are essentially subsets of the regular permissions that allow you to fine-tune the access you may want to grant to a particular set of users. These special permissions are accessed by either adding a new permission entry in the Advanced Security Settings dialog or by editing an existing security entry. Figure 9.4 shows the Permission Entry page for an object, and Table 9.3 details the Special Permissions and their capabilities.
Figure 9.4. NTFS Special Permissions for the Users Shared Folders folder.
One other item available in the Advanced permissions window is the Owner tab, shown in Figure 9.5. In this window, you can see who owns a particular file or folder, and you can change the object that owns the file or folder. File ownership affects two aspects of the object. First, file ownership is used to calculate space used against disk quotas, if quotas are enabled. Second, the owner of a file has the permissions assigned to the Creator/Owner group for the folder assigned to the owner for that file.
Figure 9.5. The Owner tab for the Users Shared Folders folder.
With Windows Server 2003, Microsoft has provided a new command-line tool to work with file ownershiptakeown. This tool can be used by an administrator to either take ownership of the object or assign ownership of the object to another user on the network. Table 9.4 lists the command-line parameters for the tool.
To change the owner of a file in the current directory to the currently logged-on user, enter takeown /f filename at the command prompt. In addition to wildcards, environment variables can also be used with the tool. For example, takeown /f %windir%\*.txt /r /a would change ownership of all the .txt files in the Windows system directory and all its subdirectories to the Administrators group. You must have Modify permissions or the Take Ownership special permission to change ownership on a file or folder.
Encrypted File System
Another security feature included with NTFS is the Encrypted File System. When applied, files marked as encrypted are unreadable by other users. This additional level of protection can keep sensitive data secure even if NTFS permissions are modified to grant access to the folders where the encrypted files are stored.
File encryption uses the user's domain certificate to encrypt the file. By default, only two accounts can access the contents of a file after it has been encryptedthe user who encrypted the file and the domain Administrator account. The domain Administrator account is the default Recovery Agent that can access the contents of the file in case the user is no longer able to access the file, either because of a certificate problem or because the user is no longer with the company.
File encryption can be enabled on a file or a folder. When encryption is set on a folder, all the existing contents of the folder and any new items put into that folder will be encrypted. Likewise, individual files within a folder that has been marked for encryption can have the encryption removed.
File encryption can be enabled on server shares as well as local file paths. Follow these steps to set up encryption for a folder on a domain share: