Securing Files | Running Microsoft Windows 2000 Professional

[Previous] [Next]

For each file on a volume, the FAT file system stores the file's name, size, and last modification date and time. In addition to storing this information, NTFS also maintains an access control list (ACL), which defines the type of access that users have to the files and folders on the system. Every file and folder stored on an NTFS volume has an ACL associated with it.

SEE ALSO
For more information about ACLs, see "Introducing Windows 2000 Security."

NTFS file security is managed using the Security tab of a file's properties dialog box. To get there:

Right-click a file in Windows Explorer.

Choose Properties from the shortcut menu.

Click the Security tab to open a dialog box similar to the one shown in Figure 28-1.

NOTE
If the selected file isn't stored on an NTFS volume, the Security tab doesn't appear because file security is implemented only for NTFS volumes.

Figure 28-1. The Security tab displays the users and groups that are permitted to access a file.

NOTE
If you're not the file's owner, you might be warned that you are allowed only to view, not change, the permissions for the file. In this case, the Add and Remove buttons in the properties dialog box are unavailable. For information about owners, see "Taking Ownership of a File or Folder."

You use this dialog box to view and change a user's access to a file. In this example, the dialog box shows that the selected file, Yosemite Map, has four entries in its ACL—one for the local Administrators group (the computer name is GLACIER, and it's a member of the SIECHERTWOOD domain), one for the user Carl Siechert, one for the Domain Users group, and one for a special user called SYSTEM. (SYSTEM isn't really a user; it's the Windows operating system itself.)

When you select a name from the Name box, the Permissions box at the bottom of the dialog box displays the type of access the selected user or group has to the file. In this example, members of the Domain Users group have Read & Execute permission and Read permission. If neither Allow nor Deny is selected for a particular permission, the user or group might still have the permission by virtue of their membership in another group that has the permission. (For example, suppose the only selected check box for the CarlS account is the Allow check box for the Read permission. Because CarlS is a member of the Domain Users group, the CarlS account also has Read & Execute permission.) If neither Allow nor Deny is selected for a particular permission and the user or group doesn't have the permission because of membership in a different group, the permission is denied.

SEE ALSO
For more information about absent or conflicting permissions, see "How Permissions Conflicts Are Resolved."

A shaded check box indicates an inherited permission, which means the permissions have been inherited from the object's parent. The parent of a file object is the folder that contains it. A shaded check box, therefore, indicates a permission that is applied by default because the file was created in a folder with that check box selected.

SEE ALSO
For more information about inherited permissions, see "Securing Folders."

NOTE
In this chapter—and in the dialog boxes we discuss—object refers to a file or folder.

Understanding File Permissions

The Permissions box lists the basic permissions, and you can handle most of your security needs by using these basic permissions in various combinations. But in fact, each of the permissions listed in the Permissions box represents predefined combinations of permissions. Table 28-1 shows the individual permissions represented by each permission shown in the Permissions box.

For some situations, the predefined permissions don't provide enough control over the access that a user or group has to a file. To accommodate such situations, you can assign permissions individually. To view individual permissions:

On the Security tab of the file's properties dialog box, click Advanced.

On the Permissions tab of the Access Control Settings dialog box that appears, select the user or group you want to review, and then click View/Edit.

Table 28-1. Basic File Permissions

Permission	Description	Individual Permissions
Read	Allows the user to view the contents of a data file	List Folder/Read Data Read Attributes Read Extended Attributes Read Permissions Synchronize
Read & Execute	Allows the user to run a program file	All Read permissions listed above Traverse Folder/Execute File
Write	Allows the user to change the contents of the file	Create Files/Write Data Create Folders/Append Data Write Attributes Write Extended Attributes Read Permissions Synchronize
Modify	Allows the user to read, change, or delete the file	All Read & Execute permissions listed above All Write permissions listed above Delete
Full Control	Allows full control of the file	All permissions listed above Delete Subfolders And Files Change Permissions Take Ownership

As shown in Figure 28-2, a Permissions list similar to the one on the Security tab of the properties dialog box appears—but this one shows (and lets you set) individual permissions.

click to view at full size.

Figure 28-2. Clicking Advanced and then View/Edit leads to a dialog box where you can specify any combination of permissions.

How Permissions Conflicts Are Resolved

Using groups provides an easy way to assign and prohibit access to files and folders for many users. However, the effects of adding and removing permissions to a group are sometimes problematic. The most obvious problem involves granting access to a group when one or more members of the group shouldn't have a particular permission.

SEE ALSO
For information about user-account groups, see "User Groups."

When making security changes, be aware that permissions are cumulative. Therefore, you should always review a group's membership to be sure you aren't granting a permission to someone who shouldn't have that permission.

Using Groups for Setting Permissions
Because permissions are cumulative, you must devise your security management strategy with some care. Perhaps the simplest approach is to rely on groups for all security settings, rather than making settings and modifications for individual users. Instead of approaching the problem as granting access to users for particular files, think of granting access to groups. Do this only once—and then add and remove users from the groups.

For example, let's say the Accounting group should have Modify permission to the accounting files. Because Melinda works in Accounting, she is a member of the Accounting group and has all of the same permissions as her coworkers. Another group of users, called Accounting Supervisors, has Full Control permission for all accounting files. If Melinda is promoted to a management position, her new access needs can be addressed by moving her from the Accounting group to the Accounting Supervisors group. If her access is modified directly, she might not automatically receive all of the permissions she needs. Furthermore, in a large organization, explicitly managing permissions for individual users can become tedious.

For example, suppose Anthony, a member of the Human Resources group, is explicitly given Read permission for the January.xls file in the Payroll folder. If Write permission for the file is given to the Human Resources group, Anthony receives that permission because he is a member of the Human Resources group. Because permissions are cumulative, Anthony continues to have Read permission for the file, but he also gains Write permission.

Denying a particular permission is an exception to the cumulative rule. It overrides all other permissions, regardless of how the individual permissions are assigned. If the Human Resources group, for example, has the Deny check box selected for each permission, Anthony is denied access to the file—even if you explicitly give his user account Full Control permission.

WARNING
Because of the precedence given to the Deny check box, be sure you understand who is affected before you apply it—or you might lock yourself out. For example, you might have a top-secret file for which you give your user account Full Control. For extra safety, you add the Everyone group and deny each of their permissions. That would be a mistake, because your account is a member of Everyone, so you're now excluded too. (Even the file's owner—initially the user who created the file—won't be able to use the file, but the owner can go in and change the permissions.)