by
Jeff Pitsch
Even though NTFS permissions have been around for over ten years, in Terminal Server and Citrix environments it’s vital that you truly understand how they work and how they should be applied.
Many people wonder whether the default NTFS permissions are adequate or whether they should apply more customized permissions. While the answer is always “it depends,” this article will provide some background information you’ll need to understand to be able to make design decisions about NTFS permissions in your environment.
NTFS Intricacies
Windows 2000 introduced a several new concepts when it comes to using NTFS permissions, including:
The addition of access to the granular permissions that make up the basic permissions.
The addition of real inheritance. NT4 SP4 introduced inheritance but it was not implemented well. Inheritance is simply the ability to assign permissions at a top level folder and to have the permissions flow to the folders beneath. This is a concept very familiar to Novell administrators.
The ability to select where the permissions will be applied. You can specify folder, subfolder, files, and everything in between.
Most—and I would truly hope all—Windows administrators are very familiar with the default permissions of Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. (Folders and files have the same permissions except files don’t have “List Folder Contents.”) These are called the basic permissions by Microsoft. There are also advanced (or “special,” as Microsoft calls them) permissions that many administrators are unfamiliar with. The advanced permissions are where the real power is for NTFS.
The basic permissions are really just preconfigured groups of advanced permissions. For example, the basic permission “Read” is a grouping of List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read permissions and is set to apply onto ‘This folder, subfolders, and files.’ The ‘apply onto’ is a very important concept to understand because it controls how far down the folder/file chain that permissions will be applied. Explanations and the relationship between basic and advanced permissions are shown in this article from Microsoft. A few key points:
- Traverse folder is not enforced by default. This is controlled by the user right “Bypass Traverse Checking”
- Anything after a “/” in the article is a file permission
- The ability to open and modify files is controlled by Read Data, Write Data, and Append Data permissions
- The ability to run a program is controlled by the Execute File permission
- Explicit Deny overrides any other permission
- Inherited Deny can be overridden by granting the user/group explicit permissions
Unlike Novell, granting user/group permissions to a folder/file deep in a hierarchy does not grant them the ability to get to the folder/file. The user/group must be given the List Folder Contents permission and the ‘Apply onto’ should be set to This folder only on each folder starting at the top level. Also, the user will be able to see folders and files at each level. They will not be able to open the files though.
Windows 2003 Service Pack 1 solves the viewing problem. SP1 adds a new feature called Access-based Enumeration (a separate download is required to activate the feature). Essentially what this does is hide anything the user does not have access to. For example, in the above picture, the Secure and Shared_PH folder would not be seen by the end user.
By default, whenever an administrator adds permissions to a folder, it is automatically set to apply to this folder and subfolders and more than likely files as well. In the above example, we effectively cut off the user from accessing folders that they didn’t need by setting the ‘apply onto’ to this folder only. Now let’s say there was a subfolder under the Customer Experience Work Plan folder and we wanted to grant the user rights to modify files but not get to the subfolder. In this case we would grant the user Read/Write to ‘This folder and files’.
Inheritance is a nice feature but there are some limitations to what you can do to control it. Again, for those who are used to Novell permissions, there is no way of filtering inheritance for individual groups or users. For example, you have two groups with permission to a folder and you want to prevent one group from going into a subfolder. You have two choices at this point:
- Set the deny permission on the group that shouldn’t have access
- Remove inheritance completely and set the permissions appropriately
Neither of these are particularly great solutions. The deny permission seems easy enough but if any user from the allowed group is added to that denied group, then they have lost permissions. The remove inheritance now creates a “one off” that you need to document and keep track of. Unfortunately there is not a way of gracefully getting around this.
Default Windows Permissions
Now that we’ve refreshed some of the details of NTFS permissions, let’s take a look at the permissions that Windows is configured with out-of-the-box.
One of the ways that Windows 2003 is more secure out-of-the-box is because it uses the “Authenticated User” account instead of the “Everyone” group. It also only allows Read access to those areas that a user may need access to.
Windows 2000, on the other hand, is not so secure. The easiest way of dealing with Windows 2000 is to download the Microsoft Solution for Securing Windows 2000 Server and use the “MSS Optional File System ACLS.inf” to lock down the file system. This .inf uses the local Users group instead of the domain group Authenticated Users but it can easily be changed over.
The other option is to download the NSA template called ‘W2k_Server.inf’. This .inf does more than just lockdown the file system (it does the same thing as the Microsoft template). It also locks down the registry and sets other security settings. I recommend editing it first to make sure you understand what it is going to do. Again, it can be edited to only do what you want it too. You can use the Security Templates MMC snap-in to edit an .inf. You can also import the .inf files into Group Policy by editing a GPO and right-clicking on Security Settings and choosing Import in the Computer portion of the GPO.
What can be done with NTFS?
NTFS permissions can be used effectively for a number of things. They can be used to restrict access to software, prevent execution of software, and prevent users from writing to areas you don’t want them to.
The simplest way to restrict access to software is to create a group for the users that you want to access the software. For example, if you want users to access Word, then you could create a group called TS-Word and assign the proper users. You would then remove the authenticated users group from the permissions of winword.exe and add the TS-Word group. Now only the TS-Word group users can access Word. Keep in mind that this is not foolproof. A classic example is explorer.exe. You can remove permissions from this executable but you cannot completely prevent it from being run by users. The reason why is because it is tied too strongly into the operating system.
One of the big questions asked is how to prevent users from installing or running software? This can be easily accomplished by using the Execute File permission. This permission is what allows executables to actually execute. It’s set only on files, not folders. An effective way of using this permission is to remove it from then the My Document folder, temp folders, home directories, and wherever else users may download files to. In fact, most shared areas could easily live without this permission.
The last piece is the most obvious but can also be the most underused. You can prevent users from writing to areas you may not want them to. Start menus, desktops, and program files are areas that can be targeted by this. For example, even if a user manages to download and run the installation of a piece of software, if the software is not capable of putting icons on the desktop or start menu, how would the user start the program? Most users are not savvy enough to be able to browse to the correct folder and find the executable and run the program. Now, let’s say the user didn’t even have access to write to the program files folders. Again, most end users would not know how to change the installation folder.
While much of this seems time consuming and onerous, there are rewards. As an administrator, you can now effectively control the user experience. There is also a very big plus to all this upfront work—less chance of viruses and spyware infecting the server. If a user doesn’t have write capabilities or execute permissions, then viruses and spyware would not be able to install or run.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.