Understanding and Using NTFS Permissions on Citrix and Terminal Servers

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.

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:

  1. Traverse folder is not enforced by default. This is controlled by the user right “Bypass Traverse Checking”
  2. Anything after a “/” in the article is a file permission
  3. The ability to open and modify files is controlled by Read Data, Write Data, and Append Data permissions
  4. The ability to run a program is controlled by the Execute File permission
  5. Explicit Deny overrides any other permission
  6. 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:

  1. Set the deny permission on the group that shouldn’t have access
  2. 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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Hi jeff,

Nice document!, there are still alot customers for who NTFS file/share permissions is a black hole for them. This article helps them understanding it better.
Thanks for sharing,

Ruben Spruijt
Yeah nice article, it is a very common question in the forums and hopefully this will be read first ;)
Good going Jeff
Nice job Jeff.
Thanks everyone. I hope people are able to get something from it.
The most important places to restrict access to when locking-down a "new" server installation are:

%SystemDrive% (the root of the hard drive on which the OS is installed)
%ProgramFiles% (The Program Files directory)
%WinDir% (the Windows Directory)

Under no circumstance should non-administrators have carte blanche write permissions to any of these directories, if you want your server to continue to operate the way it does when you deliver it to the customer. Write permissions to anything in these directories should be given on a case-by-case basis. The preferred permissions to these directories are:

System & Administrators - Full Control
Authenticated Users - Read & Execute

WARNING!!!! You should never apply these permissions to a production server. These should be appied via Group Policy when the server is joined to AD and before applications are installed. You can use Filemon from sysinternals.com to determine which exact files/direcories users need write permission to, instead of blindly giving them full control permissions to fix (create) a problem.

Using these restrictive permissions virtually eliminates spyware/malware, and prevents users from installing anything (unless they're an administrator).

Patrick Rouse
Microsoft MVP - Terminal Server

I have no idea what this article is all about, but I like the pictures. :-)
Hope to see you @next PubForum in Nice ;-)

With the citrix print engine running as a local user you have to be careful on the permissions on the documents and settings folder. The installer goes under the assumption that everything is set as default. Unless you plan on switching the print engine over to a system process, plan on waiting to lock down your server as the last item in your build.
We had a consultancy agency over here telling us it is not possible to hide files and folders you do not have permission to like it is in Novell.
According to you it is.

Now lets have a chat with those consultants and slap em around the ears a bit.

In Windows, the "List" permission is what allows you to see the folder/file. Take that away and the user cannot see it.
Re: stopping users from executing files

Say you set the user's personal folder (C:/Documents and Settings/Visitor/) to be non-executable. All very well; programs saved to the desktop are not executable any more. But the user can then just right-click on the program, select "Properties > Security", and grant themselves executable permissions right back again!

Even if you uncheck "change permissions" on the folder, the user still has a workaround. They open the security settings as before, uncheck "inherit permissions from parent", and now they can set up their own permissions for the file!

Fine, you may think, but this takes a lot of knowledge, doesn't it? Well, which user are you more worried about: the bumbling beginner who clicks on every "install toolbar" link he sees, or the tech-savvy kid who installs a keylogger so he can discover the password to the Administrator account? (Hey, it's a worry for me; I work in an internet centre that's open to the public.)
Bad form to reply to my own post, I know, but:

This link may hold the key to how to properly stop people from executing files in a certain directory:

The rather hard-to-find feature is buried in Control Panel > Administrative Tools > Local Security Policy > Security Settings > Software Restriction Policies > Additional Rules

Select Action > New Path Rule from the menu, then type in the desired path and choose "disallowed". Works like a charm, and all without needing to change any permissions. A more informative error message, too.