REVIEWING NTFS PERMISSIONS
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.NOTEAs 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).
Standard and Special Permissions
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. |
PERMISSIONS LEVELS
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. |
Working with Folder Permissions
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.NOTEIt 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.
SETTING 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.
Permissions Properties
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.
Figure 9.1. Software Configuration Properties
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.
Allow Permissions Example
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.
Figure 9.2. Joe Engineer Security Settings
Figure 9.3. The Software Config Group Security Settings
Deny Permissions Example
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).
Figure 9.4. Select Users, Computers, or Groups
Figure 9.5. Software Config Properties
Figure 9.6. A Security Warning
No matter what group has granted Joe Engineer permission to read the folder, the Deny permission assigned to the Engineers group takes precedence.
SPECIAL PERMISSIONS
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).
Figure 9.7. Access Control Settings
Figure 9.8. Permissions Entry for Subfolder
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).
Figure 9.9. A Permissions Entry
Figure 9.10. Special Permissions Update Standard Permissions
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 |
Permission Inheritance
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).
Figure 9.11. ProjectA Advanced Security Settings
Copy parent permissions to the new object.
Remove all permissions on the new object.
Cancel (abort) the block inheritance operation.
Figure 9.12. Permission Inheritance Options
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 FILE AND FOLDER PERMISSIONS
Moving and copying files can affect their permissions, so it is important to understand the basic rules associated with these actions.
Copying Files and Folders
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.
Moving Files and Folders
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.NOTERegardless 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.
Ownership
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.
DENYING RIGHTS TO A SUBFOLDER
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).
Figure 9.13. ProjectA Permissions
Figure 9.14. Access Control Settings
TRANSFERRING OWNERSHIP
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 (Owner tab from the Advanced Security Settings for ProjectA window.Select Joe Engineer and click Apply (Figure 9.17).
Figure 9.17. Ownership
Figure 9.18. Security
OWNER SETS PERMISSIONS
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).
Figure 9.19. Subfolder Properties
IMPLICIT GROUPS AND PERMISSIONS
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 |