Section 3.3. NTFS File and Folder Permissions

3.3. NTFS File and Folder Permissions

File- and folder-level permissions are one of the most dreaded and tedious tasks of system administration. However, they are significant in terms of protecting data from unauthorized use on your network. If you have ever worked with Unix permissions, you know how difficult they are to understand and set: complex CHMOD-based commands, with numbers that represent bits of permission signaturesit's so easy to get lost in the confusion. Windows Server 2003, on the other hand, provides a remarkably robust and complete set of permissions, moreso than any common Unix or Linux variety available today. It's also true that no one would argue how much easier it is to set permissions in Windows than to set them in any other operating system. That's not to say, however, that Windows permissions are a cinch to grasp; there's quite a bit to them.

3.3.1. Standard and Special Permissions

Windows supports two different views of permissions: standard and special . Standard permissions are often sufficient to be applied to files and folders on a disk, whereas special permissions break standard permissions down into finer combinations and enable more control over who is allowed to do what functions to files and folders (called objects) on a disk. Coupled with Active Directory groups, Windows Server 2003 permissions are particularly powerful for dynamic management of access to resources by people other than the system administratorfor example, in the case of changing group membership. (You'll meet this feature of Active Directory, called delegation, in Chapter 5.)

Table 3-1 describes the standard permissions available in Windows.

Table 3-1. Windows Server 2003 standard permissions
Type	Description
Read (R)	Allows user or group to read the file.
Write (W)	Allows user or group to write to the contents of a file or folder and to create new files and folders. It is possible to have read permissions without write permissions.
Read & Execute (RX)	Allows user or group to read attributes of a file or folder, view its contents, and read files within a folder. Files inside folders with RX rights inherit the rights onto themselves.
List Folder Contents (L)	Similar to RX, but files within a folder with L rights will not inherit RX rights. New files, however, automatically get RX permissions.
Modify (M)	Allows user or group to read, write, execute, and delete the file or folder.
Full Control (FC)	Similar to M, but also allows user or group to take ownership and change permissions. Users or groups can delete files and subfolders within a folder if F rights are applied to that folder.

The following key points should help you to understand how permissions work:

File permissions always take precedence over folder permissions. If a user can execute a program in a folder, he can do so even if he doesn't have read and execute permissions on the folder in which that program resides.
Similarly, a user can read a file for which he explicitly has permission, even if that file is in a folder for which he has no permission, by simply knowing the location of that file. For example, you can hide a file listing employee Social Security numbers in a protected folder in Payroll to which user Mark Evaul has no folder permissions. However, if you explicitly give Mark read rights on that file, by knowing the full path to the file, he can open the file from a command- line or from the Run command on the Start menu.
Permissions are cumulative: they "add up" based on the overall permissions a user gets as a result of his total group memberships.
Deny permissions always trump Allow permissions. This applies even if a user is added to a group that is denied access to a file or folder that the user was previously allowed to access through his other memberships.

Windows also has a bunch of permissions labeled special permissions, which, simply put, are very focused permissions that make up standard permissions. You can mix, match, and combine special permissions in certain ways to make standard permissions. Windows has "standard permissions" simply to facilitate the administration of common rights assignments.

There are 14 default special permissions, shown in Table 3-2. The table also shows how these default special permissions correlate to the standard permissions discussed earlier.

Table 3-2. Windows Server 2003 special permissions
Special permission	R	W	RX	L	M	F
Traverse Folder/Execute File
List Folder/Read Data
Read Attributes
Read Extended Attributes
Create Files/Write Data
Create Folders/Append Data
Write Attributes
Write Extended Attributes
Delete Subfolders and Files
Delete
Read Permissions
Change Permissions
Take Ownership
Full Control

The default special permissions are further described in the following list:

Traverse Folder/Execute File: Traverse Folder allows you to access a folder nested within a tree even if parent folders in that tree deny a user access to the contents of those folders. Execute File allows you to run a program.
List Folder/Read Data: List Folder allows you to see file and folder names within a folder. Read Data allows you to open and view a file.
Read Attributes: Allows you to view basic attributes of an object (read-only, system, archive, and hidden).
Read Extended Attributes: Allows you to view the extended attributes of an objectfor example, summary, author, title, and so on for a Word document. These attributes will vary from program to program.
Create Files/Write Data: Create Files allows you to create new objects within a folder; Write Data allows you to overwrite an existing file (this does not allow you to add data to existing objects in the folder).
Create Folders/Append Data: Create Folders allows you to nest folders. Append Data allows you to add data to an existing file, but not delete data within that file (a function based on file size), or delete the file itself.
Write Attributes: Allows you to change the basic attributes of a file.
Write Extended Attributes: Allows you to change the extended attributes of a file.
Delete Subfolders and Files: Allows you to delete the contents of a folder regardless of whether any individual file or folder within the folder in question explicitly grants or denies the Delete permission.
Delete: Allows you to delete a single file or folder, but not other files or folders within that folder.
Read Permissions: Allows you to view NTFS permissions on an object, but not to change them.
Change Permissions: Allows you to both view and change NTFS permissions on an object.
Take Ownership: Allows you to take ownership of a file or folder, which inherently allows the ability to change permissions on an object. This is granted to administrator-level users by default.

You also can create custom combinations of permissions, known as special permissions, other than those defined in Windows Server 2003 by default; I cover that procedure in detail later in this section.

3.3.2. Setting Permissions

Setting permissions is a fairly straightforward process that you can perform through the GUI. To set NTFS permissions on a file or folder, follow these steps:

Open My Computer or Windows Explorer and navigate to the file or folder on which you want to set permissions.
Right-click the file or folder, and select Properties.
Navigate to the Security tab.
In the top pane, add the users and groups for whom you want to set permissions. Then click each item, and in the bottom pane grant or disallow the appropriate permissions.

Figure 3-8 shows the process of assigning write rights to user Lisa Johnson for a specific folder.

Figure 3-8. Granting permissions on a folder to a user

If a checkbox under Allow or Deny appears gray, this signifies one of two things: that the permissions displayed are inherited from a parent object (I discuss inheritance in more detail in the next section), or that further special permissions are defined that cannot be logically displayed in the basic Security tab user interface. To review and modify these special permissions, simply click the Advanced button. On this screen, by using the Add button you can create your own special permissions other than those installed by default with Windows Server 2003. You also can view how permissions will flow down a tree by configuring a permission to affect only the current folder, all files and subfolders, or some combination thereof.

3.3.3. Inheritance and Ownership

Permissions also migrate from the top down in a process known as inheritance . This allows files and folders created within already existing folders to have a set of permissions automatically assigned to them. For example, if a folder has RX rights set, and you create another subfolder within that folder, users of the new subfolder will automatically encounter RX permissions when they try to access it. You can view the inheritance tree by clicking the Advanced button on the Security tab of any file or folder. This will bring up the screen shown in Figure 3-9, which clearly indicates the origin of rights inheritance in the Inherited From column.

Figure 3-9. Viewing the origin of permissions inheritance

You can block this process by unchecking the Allow inheritable permissions from parent to propagate to this object checkbox on the screen in Figure 3-9. Any children of the folder for which you've stopped inheritance will receive their permission from that folder, and not from further up the folder tree. Also, if you ever decide to revert to standard permissions inheritance on an object for which you've blocked the process, simply recheck the checkbox. Custom permissions that you've defined will remain, and all other permissions will automatically trickle down as usual.

There also is a concept of ownership. The specified "owner" of a file or folder has full control over the file or folder and therefore retains the ability to change permissions on it, regardless of the effect of other permissions on that file or folder. By default, the owner of the file or folder is the object that created it. Furthermore, there is a special permission called Take Ownership that an owner can assign to any other user or group; this allows that user or group to assume the role of owner and therefore assign permissions at will. The administrator account on a system has the Take Ownership permission by default, allowing IT representatives to unlock data files for terminated or otherwise unavailable employees who might have set permissions to deny access to others.

To view the owner of a file, click the Owner tab on the Advanced Permissions dialog box. The current owner is displayed in the first box. To change the ownerassuming you have sufficient permissions to do sosimply select a user from the white box at the bottom and click OK. Should the user to whom you want to transfer ownership not appear in the white box, click Other Users and Groups, then click Add, and then search for the appropriate user. You also can elect to recursively change the owner on all objects beneath the current object in the filesystem hierarchy. This is useful in transferring ownership of data stored in a terminated employee's account. To do so, select the checkbox for Replace owner on subcontainers and objects at the bottom of the screen. Click OK when you've finished. (This operation can take a while.)

3.3.4. Determining Effective Permissions

As a result of Microsoft's inclusion of RSoP tools in Server 2003, you can now use the Effective Permissions tab on the Advanced Permissions screen to view what permissions a user or group from within Active Directory or a local user or group would have over any object. Windows examines inheritance, explicit, implicit, and default ACLs for an object, calculates the access that a given user would have, and then enumerates each right in detail on the tab. Figure 3-10 demonstrates this.

The Effective Permissions display has two primary limitations. First, it does not examine share permissions. It concerns itself only with NTFS filesystem-based ACLs, and therefore, only filesystem objects. And second, it functions only for users and groups in their individual accounts. It will not display correct permissions if a user is logged in through a remote access connection or through Terminal Services, and it also might display partially inaccurate results for users coming in through the local Network service account. Although these are reasonably significant limitations, using the Effective Permissions tool can save you hours of head scratching as to why a pesky Access Denied message continues to appear. It's also an excellent tool to test your knowledge of how permissions trickle down, and how allow and deny permissions override such inheritance at times.

Figure 3-10. The Effective Permissions tab

3.3.5. Access-Based Enumeration

ABE is a great feature that (and I'm not sure why) hasn't been included in releases of Windows Server to date. Essentially this removes any access-denied errors for users by showing them only what they're allowed to access; if they don't have permission to use a file, browse a folder, or open a document, then it won't appear in whatever file management tool they're using at the time. This also closes an arguably moderately significant security hole, in that if users can see folders they're not able to access it might prompt hacking attempts or other tries to circumvent security, whereas one is less likely to hack what one doesn't know is there. Or so the theory goes.

It looks like the real drawbacks at this point are:

ABE only works when you're connecting via UNC to a network share. It won't work for local files. Perhaps this will be fixed in Longhorn Server? Of course, this doesn't seem like a terrible drawback since not many users are browsing locally on Windows Server 2003 machines.
You do need to be running Windows Server 2003 with Service Pack 1 installed. R2, however, is not required.
It isn't bundled in the box. It's an out of band release, and as of this writing it is not included on the second CD in Windows Server 2003 R2. That's a minor setback, since it's freely available for download.

You can download the ABE installer from:

http://www.microsoft.com/downloads/details.aspx?FamilyID=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en

or, if you'd rather not type in a URL that long, I've provided a link to the tool from my blog entry at:

http://www.learning2003.com/blog/2005/05/allow-users-to-see-only-what-they-can.html

It's easy to install. Simply download the tool and double-click on the resulting installable file. You'll be asked for the appropriate disk to install on, and then you can select whether you'd like to have ABE enabled on all shared folders on that particular system or if you'd rather enable it on a folder-by-folder basis.

ABE needs to be installed on each server that hosts shared folders you'd like to protect with its services.

Once installation is complete, you can see the extremely simple ABE interface by right-clicking on any shared folder from within Windows Explorer, selecting Properties, and then clicking on the Access-Based Enumeration tab. This is shown in Figure 3-11.

To apply ABE to the current folder, click the first checkbox. You can also choose to apply the setting in the first checkbox to all other shared folders on that particular machine by selecting the second checkbox.

What will your users see? Nothingthat is, nothing that they don't have permissions to access. It's a seamless add-in.

3.3.6. Auditing

Object access auditing is a way to log messages concerning the successful or unsuccessful use of permissions on an action against an object. Windows Server 2003 writes these messages to the Security Event Log, which you can view using the Event Viewer in the Administrative Tools applet inside the Control Panel. First, though, you must enable auditing at the server level and then enable it on the specific files and folders you want to monitor.

Figure 3-11. The Access-based Enumeration tab

You can enable auditing overall in one of two wayseither on a system-by-system basis by editing the local system policy, or on selected machines (or all machines) participating in a domain through GP. In this section, I'll focus on editing local system policies. To begin, follow these steps:

Select Start All Programs Administrative Tools, and click Local Security Policy.
Double-click Audit Object Access.
To enable auditing, select which eventsa successful access of a file or folder, an unsuccessful attempt, or bothto audit, and then click OK.
Close the Local Security Policy box.

Audit events for the appropriate types of accesses will now be written to the Security event log as they happen.

Here is a quick summary of enabling auditing through domain-based GPs: create a new GPO linked to a selected container of machines, and navigate through Computer Configuration, Windows Settings, Security Settings, and Local Policies to Audit Policy. Select the appropriate events, and click OK. Give the domain controller a few minutes to replicate the policy to other domain controllers in the domain, and then refresh the policy on your client machines through gpupdate /force or by rebooting the machines.

Now, select the objects within the filesystem you want to audit and right-click them. Choose Properties and click the Security tab in the resulting dialog box. Then click Advanced and select the Auditing tab. You'll be presented with a screen much like the one shown in Figure 3-12.

Figure 3-12. Enabling auditing on an object

Assigning audit objects in Windows is much like assigning permissions. Simply click Add, and a dialog will appear where you can enter the users to audit. Note that audit instructions work for both users and groups, so although you might not care what members of the Administrators group do, those in Finance might need a little more monitoring. Click OK there, and then select what actionsa successful object access or a failed useof an event should be written to the log. You can easily specify different auditing settings between the various permissions, saying that you don't want to know when someone fails to read this object but you want to know whenever someone adds to it.

Auditing is a helpful way to keep track of what's happening on your file shares.