|
|
To protect data from users in a Windows Server 2003 enterprise, the administrator should understand how NTFS employs permissions. NTFS permissions are divided into folder and file categories. Folder permissions control what files and subfolders a user or group may view and which folders a user may open. They also restrict what users and groups may create, delete, and change permissions on the contents of a folder.
Every file, folder, or other object has an owner. For example, every user owns his My Documents home directory, as well as all files he creates and saves in the My Documents folder. As the owner, the user has full control over his objects and can assign permissions for other users to access them. As we shall discuss later, this control ranges from total denial of access to granting ownership of a file or folder to another.
NOTE
As an administrator, you also have full control of a user's files and folders. This is particularly useful when the user requests intervention or leaves the organization. However, this privilege should not be abused. Direct administrative modification of a user's file and folder permissions is ordinarily on an "as needed" basis.
Windows Server 2003 uses access control lists (ACLs) to track an object's permissions. All objects have ACLs, which control what users and groups can do with them. The specific user or group is an access control entry (ACE).
The ACL is composed of a system access control list (SACL) and a discretionary access control is (DACL). The SACL configures auditing permissions and determines which file and folder operations will be written to the audit logs; the DACL contains security settings and permissions granted to specific users and groups. Each of the ACL's access control entries (ACEs) has security settings and audit settings (Tables 9.1 and 9.2).
Windows Server 2003 supports two overlapping categories of permissions: special and standard. Standard permissions are generally applied to objects; special permissions provide finer granularity to file- or folder-based security. The majority of this discussion centers on standard permissions. We will apply their use by example after we review the basic concepts.
|
Type |
Description |
|---|---|
|
Access Allowed |
Identifies users and groups that have explicit permission to use the object. |
|
Access Denied |
Identifies the permission denied expressly to a user or group. |
|
Type |
Description |
|---|---|
|
Audit Successful File/ Folder operation |
Users and groups logged when attempts to access and modify file/folder attributes and contents are successful. |
|
Audit Failed File/ Folder operation |
Users and groups logged when attempts to access and modify file/folder attributes and contents fail. |
Six types of permissions can be combined for different results: Read, Write, Execute, List Folder Contents, Modify, and Full Control. They are described in Table 9.3.
The Full Control permission level obviously is automatically provided to the object's creator/owner and to the Administrators group.
|
Abbreviation |
Type |
Description |
|---|---|---|
|
R |
Read |
Provides the designated user or group the ability to read the file or the contents of the folder. |
|
W |
Write |
Provides the designated user or group the ability to create or write files and folders. |
|
RX |
Read & Execute |
Provides the designated user or group the ability to read file and folder attributes, view folder contents, and read files within the folder. If this permission is applied to a folder, files with inheritance set will inherit it (see the inheritance discussion). |
|
L |
List Folder Contents |
Same as Read & Execute, but not inherited by files within a folder. However, newly created subfolders will inherit this permission. |
|
M |
Modify |
Provides the ability to delete, write, read, and execute. |
|
F |
Full Control |
Provides the ability to perform any action, including taking ownership and changing permissions. When applied to a folder, the user or group may delete subfolders and files within a folder. |
Users may overwrite, delete, read, execute, and own NTFS files. It is important to understand that file permissions take precedence over folder permissions. If a user has permission to execute a file she may do so even if she does not have permissions to read and execute the file's folder.
NOTE
It is possible for a user to navigate to a file for which he does not have folder permission. This involves simply knowing the path of the file object. Even if the user can't drill down the file/folder tree using My Computer, he can still gain access to the file using the Universal Naming Convention (UNC). In this example, the user does not have permissions to do anything in the folder called Book. However, he does have full control over the file called Chapter10.doc that resides in the Book folder. If the user attempted to user Explorer to see the contents of the Book folder, it would not be displayed. However, if the user wanted to execute the file within Notepad, he could do so by using either the Start 
Run dialog or the Start Accessories command prompt, and provide the full path to the object:
Notepad C:\Book\Chapter10.doc
The user must know the file's full path and name, but it is still possible to override the folder permissions.
Permissions apply differently to files and folders. In addition, NTFS permissions to other objects like applications are accessed and managed in the same way. Setting permissions is accomplished by following these steps:
Right-click My Computer and select Explore.
Find a folder on an NTFS volume and right-click Properties.
The Program Files Properties dialog box appears. Select the Security Tab.
Make changes by selecting Allow or Deny at each permissions category.
Folder permissions are listed with Allow and Deny check box columns. They are displayed for a user or group selected in the Group or user names window, also known as the ACL. The example in Figure 9.1 includes ACEs for Administrators, CREATOR OWNER, Software Config, SYSTEM, and Users.
Permissions are cumulative. If a user belongs to more than one ACE (multiple group memberships), her permissions are an accumulation of those of each group.
To illustrate how permissions are applied, let's provide and deny permissions to a specific user. Joe Engineer is once again our user.
Joe Engineer is assigned Read privileges, and he also belongs to the Software Config group, which is assigned Write privileges. The ACE permissions for both Joe Engineer and Software Config are shown in Figures 9.2 and 9.3, respectively. Joe Engineer will have the effective rights of both ACEs, including Read and Write.
The Allow permissions are cumulative, but the Deny permissions behave quite differently. Deny overrides Allow. For instance, Joe Engineer has been allowed to read specifically the Software Config folder. However, when he joins a new group called Engineers, he loses the previous permissions since this group has been denied access to the SOFTCONF folder.
Let's review how this is accomplished.
The new group is added to the ACL by clicking Add and choosing the Engineers group from the Select Users, Computers, or Groups dialog box (Figure 9.4).
From the Software Config Properties box (Figure 9.5), select the Engineers group and check Deny in the Read permission row.
Click Apply to apply the new permission and display a warning (Figure 9.6).
Answer Yes to the warning. Engineers now denies all members Read access to the Software Config folder.
No matter what group has granted Joe Engineer permission to read the folder, the Deny permission assigned to the Engineers group takes precedence.
The standard NTFS permissions just discussed provide general control over user and group access. However, on some occasions where greater granularity may be needed, the NTFS special permissions come into play. There are 14 special permissions. They are mapped to the standard permissions, as shown in Table 9.4.
Let's apply special permissions to our example of Joe Engineer:
Select Joe Engineer from the Software Config Properties dialog.
Assign Write permissions to the user by checking the Allow check box.
Click Advanced. The Advanced Security Settings for Software Config dialog appears (Figure 9.7).
Select Joe Engineer and click Edit. The Permission Entry for Software Config dialog box appears (Figure 9.8).
Notice that the allowed permissions, Create Files, Create Folders, Write Attributes, and Write Extended Attributes, correspond to the Write column of the previous table (Table 9.4). They are associated with the standard Write NTFS permission. Each of the six standard permissions is mapped to a subset of the 14 special permissions. In fact, as you add special permissions, the standard permission level changes to include them.
Check the Allow boxes next to the following four special permissions: List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions (Figure 9.9).
Click OK. Click the next OK.
The Software Config Properties dialog should now show the standard Read and Write permissions as allowed (Figure 9.10).
|
Types |
Full Control |
Modify |
Read & Execute |
List Folder Contents |
Read |
Write |
|---|---|---|---|---|---|---|
|
Traverse Folder/Execute File |
X |
X |
X |
X |
||
|
List Folder/Read Data |
X |
X |
X |
X |
X |
|
|
Read Attributes |
X |
X |
X |
X |
X |
|
|
Read Extended Attributes |
X |
X |
X |
X |
X |
|
|
Create Files/Write Data |
X |
X |
X |
|||
|
Create Folders/Append Data |
X |
X |
X |
|||
|
Write Attributes |
X |
X |
X |
|||
|
Write Extended Attributes |
X |
X |
X |
|||
|
Delete Subfolders and Files |
X |
|||||
|
Delete |
X |
X |
||||
|
Read Permissions |
X |
X |
X |
X |
X |
|
|
Change Permissions |
X |
|||||
|
Take Ownership |
X |
All folders and subfolders inherit permissions from their parent folder by default. This is true of files in a folder as well. In other words, a folder with Read and Write permissions for the Users group will pass these characteristics to subfolders and files unless otherwise changed.
Inheriting NTFS permissions can be prevented at the child folder or file level by clearing the Inherit from parent the permissions entries that apply to child objects option. Once permission inheritance has been stopped, permissions may be assigned to the object by copying them from its parents or by clearing all permissions currently assigned. All children of the object will inherit its permissions rather than those of its grandparents. This point is illustrated with the following example:
Create a subfolder within the Software Config folder called ProjectA.
Right-click the new folder and select Properties. The ProjectA Properties dialog appears. Select the Security tab and click Advanced. Clear the Inherit from parent the permission entries that apply to child objects check box (Figure 9.11).
The Security dialog box (Figure 9.12) appears, presenting three options:
Copy parent permissions to the new object.
Remove all permissions on the new object.
Cancel (abort) the block inheritance operation.
Selecting either Copy or Remove will block the inheritance of parent NTFS permissions and allow this branch of the directory tree to propagate its own set of permissions.
Click Remove and notice that all permissions have been eliminated from ProjectA subfolder.
New groups and users can be added by clicking Add, and their associated permissions can be assigned.
New files and folders created in the ProjectA subfolder will receive the permissions assigned to ProjectA rather than those assigned to the Software Config folder.
Moving and copying files can affect their permissions, so it is important to understand the basic rules associated with these actions.
The copy procedure simply duplicates an existing file or folder to another location. To copy, the user must have at least Read permission for the source file or folder and Write permission for the destination parent folder. Once the new file or folder has been created, it inherits its permission settings from the new parent folder. Permissions are not retained since this is a new object.
The process of moving a file or folder simply involves removing it from its current location and placing it in a new location. To do this, the user must have Read/Modify permission on the object and Write permission for the new parent folder. A file or folder moved within the same NTFS volume is not considered a new object and thus retains its permissions once in the new parent folder. However, a file or folder moved to another NTFS volume inherits permissions from the destination parent folder.
NOTE
Regardless of whether an object is copied or moved, a file or folder transferred from an NTFS volume to a FAT volume loses all permissions. Remember, FAT/FAT32 does not support permission assignment.
Every file and folder has permissions along with an owner. The owner has full control over the object regardless of what other permissions are assigned to that object. Anyone with Full Control can assign the special NTFS permission Take Ownership to someone else. Note, however, that having Take Ownership privilege does not make a user or group the owner. Users with the Take Ownership permission must make themselves owner to obtain full control over a file or folder.
In the following example, we will test the principle of ownership and folder access. The first step is to deny Joe Engineer Read permission.
Deny Joe Engineer the right to read the ProjectA subfolder (Figure 9.13).
Verify the Deny entry by clicking Advanced and viewing the ACL settings (Figure 9.14).
Select the Allow entry for Joe Engineer and click Edit.
Transferring ownership involves two primary steps. The first is allowing another user to take ownership. The second is the other user's accepting ownership. The following example walks through the steps required to allow Joe Engineer to take ownership. Once he accepts it, he can change permissions to view and edit ProjectA's contents. This example depends on settings from the preceding examples.
Set the allow Take ownership special permission (Figure 9.15).
Click OK. Notice that the modified Permission entry for Joe Engineer is now Special in the Permission column (Figure 9.16). Click OK again and log off the system.
Log back on as Joe Engineer.
Try to access ProjectA as Joe Engineer. Notice that it is not accessible.
Right-click ProjectA Properties and select the Security tab. No properties are visible. The Read attributes permission has been denied Joe Engineer, and security permissions are no longer readable.
From the ProjectA Properties window, select the Security tab.
Click Advanced.
Select the Owner tab from the Advanced Security Settings for ProjectA window.
Select Joe Engineer and click Apply (Figure 9.17).
Click OK. Click OK again.
Reopen the ProjectA Properties window and select the Security tab. Joe Engineer can now view and change permissions (Figure 9.18).
At this stage Joe Engineer has taken ownership of the ProjectA folder. He must now assign himself the permissions to access it.
In the Deny column, clear the Read permission and in the Allow column, check Full Control (see Figure 9.19).
Click OK.
Try to access ProjectA. Joe Engineer now has full control over the folder.
Users, security groups, and implicit groups are assigned varying levels of permissions for files and folders. Implicit groups are local to all Windows Server 2003 systems but not available through Active Directory or local account databases. They are accessible only when assigning file/folder permissions and reflect how the user accesses the resource. Membership in an implicit group is determined by the operating system, and group SIDs are not passed with Kerberos authorization information.
Implicit groups can be used to assign permissions to folders and files. They are defined as shown in Table 9.5 on page 369.
|
Group |
Description |
|---|---|
|
Anonymous Logon |
User without system identifier (SID) |
|
Authenticated Users |
Same as Everyone but does not contain guests or anonymous users |
|
Batch |
Batch program (*.cmd and *.bat) rights |
|
Creator |
Creator of the file/folder/print job |
|
Creator Owner |
Creator and owner of the file/folder/print job |
|
Dial-up |
User accessing the system via the Remote Access Service (RAS) |
|
Enterprise Domain Controllers |
Enterprise domain controllers remotely accessing the system |
|
Everyone |
Local and remotely logged-on users |
|
Interactive |
Locally logged-on user |
|
Network |
User logged on to the system through the network |
|
Restricted |
Users cannot install programs or make changes to the file system settings |
|
System |
Operating system, otherwise known as the local system |
|
Terminal Server User |
Terminal server client |
NOTE
With Windows Server 2003, the ACL editing functions have been increased. Enhancements to the standard ACLeditor user interface (ACLUI) include the ability to reset permissions to a default, show effective permissions for a selected security principal, indicate the parent from which permission was inherited, and indicate the existence of additional permissions. The ACL Editor is available from the Active Directory Users and Computers Snap-in Security.
 |
|
|
| Top |