File-Level Security

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.

Table 9.1. NTFS Volume/Folder Permissions

Permission	Action
Read	Allows objects to read the contents of a volume/folder, including file attributes and permissions
Write	Allows objects to create new files and folders within a volume/folder, write attributes on files and folders, and can read permissions and attributes on files and folders
List Folder Contents	Grants objects the same rights as the Read permission but also enables the object to traverse the full folder path
Read & Execute	Gives objects the same rights as the List Folder Contents permission and allows objects to execute programs stored in the volume/folder
Modify	Gives objects the same rights as the Read, Write, List Folder Contents, and Read & Execute permissions and allows objects to delete files and folders within the volume/folder
Full Control	Gives objects full access to the contents of the volume/folder as well as the capability to change permissions and take ownership

Table 9.2. NTFS File Permissions

Permission	Action
Read	Allows objects to read the contents of the file, including attributes and permissions
Write	Allows objects to change the contents of a file and read but not change the attributes and permissions
Read & Execute	Grants objects the same access as the Read permission and allows objects to execute a program file
Modify	Grants objects the same access as the Read, Write, and Read & Execute permissions, as well as allowing objects to delete the file
Full Control	Grants objects full access to the file, as well as the capability to change permissions and take ownership

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.

Caution

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.

Permission Inheritance

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.

Special Permissions

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.

Table 9.3. NTFS Special Permissions

Permission	Action
Traverse Folder/Execute File	For folders, allows the object to navigate through the subfolder structure on disk. For files, allows the object to execute a program file store in the folder.
List Folder/Read Data	For folders, allows an object to see the names of files and subfolders. For files, allows an object to view the contents of the file.
Read Attributes	Allows an object to view the attributes of a file or folder.
Read Extended Attributes	Allows an object to view the extended attributes of a file or folder. Extended attributes are generally defined by an application and vary from program to program.
Create Files/Write Data	For folders, allows an object to create new files within the folder. For files, allows an object to change or replace the contents, but not the attributes, of a file.
Create Folders/Append Data	For folders, allows an object to create new subfolders within the folder. For files, allows an object to append data to the end of an existing file but not to alter the remaining contents of the file.
Write Attributes	Allows an object to modify the attributes on an existing file or folder within the folder.
Write Extended Attributes	Allows an object to modify the extended attributes on an existing file or folder within the folder.
Delete Subfolders and Files	Allows an object to delete a file or subfolder, even if the standard Delete permission has not been granted.
Delete	Allows an object to delete a file from the current folder.
Read Permissions	Allows an object to view the security permissions on a file or folder.
Change Permissions	Allows an object to modify the security permissions on a file or folder.
Take Ownership	Allows an object to change the owner information on a file or folder to the object.
Full Control	Allows an object to perform all Special Permissions.

Ownership

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.

Table 9.4. Command-Line Parameters for takeown.exe

Parameter	Action
/F filename	Changes the owner of the file or files specified by filename. filename can be the name of a single file or a wildcard pattern to change multiple files.
/A	Changes the owner of the file or files to the Administrators group instead of the user who runs the tool.
/R	Changes all files in the directory specified with the /F parameter and its subfolders.
/S system	Forces the takeown action to occur on the remote computer system.
/U [domain\]user	Changes the file owner to the user specified by user and the optional domain specified by domain.
/P [password]	Uses the password specified by password to authenticate as the user specified with the /U flag. Prompts for a password if none is specified.

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.

Best Practice: Setting NTFS Permissions

Setting permissions on files and folders can lead to great confusion when trying to sort out what access an object has to a particular file or folder if some thought is not given in advance. Follow these guidelines when setting permissions on a file or folder.

Set as few permissions as necessary. The more permissions are set, the more potential for conflicting permissions that result in incorrect access to files and folders.

Set permissions based on security groups, not individual user objects. If special access is needed for an area of a folder tree, create a special security group for that access and assign permissions to that group. Then add or remove users to the group as necessary. It is easier to modify the group memberships on a user object to change the access needed on the file system than try to remember every place that user object was given permissions in the file system.

Use the Deny permission sparingly. It is often better to remove permission settings for a file/folder than to attempt to Deny access to the object. Misapplying the Deny setting can cause many unintended permissions conflicts. Never apply the Deny permission to the Everyone group.

Set permissions on folders instead of files where possible. If radically different permissions are needed on a single file in a folder with many other files, a better solution may be to move the file in question to a different location with different permissions.

Leave the default permissions as defaults. Unless you have a good reason, there is generally no need to modify the permissions on any objects within the c:\Windows folder, the c:\inetpub folder, the Program Files folder (especially the Exchsrvr folder), or any of the other default folders. Permissions within the Users Shared Folder can be modified as needed to allow access to files between users, but those changes should be made at the user folder level, not at the parent 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:

1.	Right-click on the desired folder and select Properties.
2.	In the General tab, click Advanced.
3.	In the Advanced Attributes dialog box, enable the Encrypt Contents to Secure Data check box as shown in Figure 9.6. Figure 9.6. Folder encryption settings in the Advanced Attributes dialog.
4.	Click OK to close the Advanced Attributes dialog.
5.	Click Apply to encrypt the files within the folder, and then click OK to close the folder Properties dialog.