File and Folder Properties

When using the NTFS file system, a file’s properties include size, owner, and access permissions. The same is true for directories, where the basic permission is determined by a number of attributes.

The following file permissions exist: Full Control, Modify, Read & Execute, Read, and Write. The individual permissions each include one logical group of restricting permissions. The following table lists file permissions and the corresponding restrictions.

Table 8.1: Permission Groups and Corresponding Restricting Permissions

Restricting Permissions	Full Control	Modify	Read & Execute	Read	Write
Traverse Folder/Execute File	Yes	Yes	Yes	No	No
List Folder/Read Data	Yes	Yes	Yes	Yes	No
Read Attributes	Yes	Yes	Yes	Yes	No
Read Extended Attributes	Yes	Yes	Yes	Yes	No
Create Files/Write Data	Yes	Yes	No	No	Yes
Create Folders/Append Data	Yes	Yes	No	No	Yes
Write Attributes	Yes	Yes	No	No	Yes
Write Extended Attributes	Yes	Yes	No	No	Yes
Delete Subfolders and Files	Yes	No	No	No	No
Delete Folders	Yes	Yes	No	No	No
Read Permissions	Yes	Yes	Yes	Yes	Yes
Change Permissions	Yes	No	No	No	No
Take Ownership	Yes	No	No	No	No

Note

Groups and users with full access can delete all files in a folder, regardless of the individual file permissions.

The directories have the following permission options: Full Access, Modify, Read & Execute, List Folder Contents, Read, and Write. The individual permissions each include one logical group of restricted permissions. The only difference between the directories and files is the additional List Folder Contents group.

Note

When analyzing the options List Folder Contents and Read and Execute in detail, it seems that they have the same restricted permissions. However, these permissions are handled differently. The List Folder Contents permissions apply only to folders, not to files. This option should occur only when displaying folder permissions. On the other hand, with Read and Execute, the permissions apply to both files and folders. This option is available when displaying file or folder permissions. Figure 8-19: Permissions at the file level. The grayed attributes point to the fact that they were inherited by a parent object.

It is, of course, possible to assign different combinations of basic permission attributes to directories and files. However, this is common practice for system files only and requires in-depth understanding of the NTFS file system security concept.

The Change Permissions and Take Ownership attributes are of particular importance for a file system’s security administration. Only users owning the attribute for changing directory or file permissions can actively modify the security settings. Only users owning the attribute for taking the ownership can assume ownership of a directory or file. The owner of a directory or file can always assign himself or herself the attribute for taking ownership and therefore change all other attributes, too. An administrator always has the right to become the owner of a directory or file. An administrator who owns a file or directory can assign himself or herself the attribute for changing permissions and therefore actively modify all other attributes as well. Administrators or users who own the attribute for taking ownership of a file or directory can assume ownership of this object, but they cannot actively return ownership to its original owner.

Note

On Windows Server 2003, a user or administrator can only assume ownership of a directory or file actively. No one can transfer ownership to another person using standard methods.

To improve terminal server security, it is recommended that critical system files be protected as thoroughly as possible. This applies to the following file system areas in particular:

• Start files in the system drive: Boot.ini, Ntdetect.com, or Ntloader

• The different operating system directories (\WINDOWS)

• User profile directories (\Documents and Settings)

• Application-specific directories

Because of the improved default settings of Windows Server 2003 in comparison to its predecessors, the security of start files, system directories, and user data is ensured. However, installing applications that might change standard security settings can leave the security system vulnerable.

Important

Whenever a new application is installed on a terminal server, it is recommended that all possible impacts on system security be checked. The default security settings of the new application can allow previously unauthorized users free access to the installation directory! Furthermore, many applications allow other programs to be launched indirectly, which might enable access to system-relevant settings.

Increasing system security after required applications are installed usually involves restricting permissions for standard groups, user groups, or even individual users within one administrator session. Subsequently, a test user logs on and the runtime system is monitored—for example, using file system access monitoring tools.

Windows Explorer or the Cacls.exe command-line program are recommended tools for modifying the security attributes of a directory or a file.

File Monitor

File Monitor is another tool developed by Mark Russinovich and Bryce Cogswell. It can be downloaded for free from the SysInternals Web site at http://www.sysinternals.com. File Monitor is a combination of graphical application and special device driver. It can record and display all file activities occurring on a Windows system. With its integrated filter and search functions, File Monitor is a powerful tool for examining a terminal server’s file activities. It is particularly practical for tracing how applications use files and DLLs. This information can be used for delimiting and solving system- and application-related problems.

File Monitor’s graphical user interface indicates each file access in an individual line. The line is divided into fields that include a sequence number, time, process name, access type, the file (including its path), access result, and additional information. The Result field is the most important means of analyzing errors that occur during file access. The Other field shows the relative position of read and write activity in the file. All file accesses logged can be easily viewed using the scroll bar.

The File Monitor filter functions can be set to display the logs for selected processes or files only. The DASD (direct access storage device) path name is especially interesting because it indicates direct hard drive accesses that bypassed the file system.

Analyzing or securing a terminal server using the File Monitor is relatively simple. An administrator logs on, configures an application for maximum security for the file system, and starts File Monitor (if necessary, with a filter preset to reduce the resulting amount of data).

If the administrator now logs on with a second session, using a standard user account without administrator privileges, the administrator can verify if the application starts up as desired. Normally, this should not be possible with very strict security settings, and error messages will be displayed on the desktop.

Using the first session, the administrator now takes File Monitor to see which access errors were logged. The administrator can then view all files with access permissions that need to be changed. Entire files might be missing (such as DLLs or .ini files), which at that point becomes clearly evident.

Note

Only administrators can launch File Monitor because other users do not have the necessary permissions. If you want to examine accesses within user context, you need to start an RDP user session on a desktop that belongs to an administrator. By running File Monitor from this administrator session you will see system-wide activity including that of unprivileged sessions.

Securing Network Shares

Under Windows Server 2003, all drives are automatically shared through their logical name, that is, driveletter$, for example, C$ or D$. However, access permissions for these administrative shares are very restricted. Only if a user is a member of the Administrators or Backup Operators group is it possible for the user to access the administrative shares via the network. If the NTFS permissions for all objects of the administrative share are set accordingly, administrative access to their directories and files is unrestricted.

Important

Windows Server 2003 no longer supports access to an administrative share through an administrator account with a blank password. This significantly improves system security because it eliminates accidental loopholes due to incorrectly configured administrator accounts.

The following steps further improve the security of administrative shares:

• Strong administrator password Assigning a strong password to the administrator account that is hard to guess. Windows Server 2003 security settings also allow settings that require increased password complexity (special characters, capitals, numbers) or minimum password length.

If the administrator password must remain weak, sharing can be blocked with these steps:

• Disable server service If this service is disabled, directories can no longer be shared. This means that users can no longer connect to a drive or directory on this computer. Users working with this computer can still access shared directories on other computers. If server service is to be disabled permanently, the start type must be set to Manual or Disabled. Otherwise, the service relaunches automatically when the computer reboots.

• Uninstall file and printer sharing for Microsoft Networks This option is located under the network and dial-up connection properties. Use the Uninstall button to remove this component (but not the check box File and Printer Sharing for Microsoft Networks).

  Note

  To temporarily block a drive from being shared, the context menu of the relevant drive must be opened. Under the Sharing and Security... menu item you will find the Do not share this folder option. However, you need to keep in mind that under Windows Server 2003, the drive will automatically be shared again after a reboot.