NTFS Permissions

download NTFS Permissions

of 22

  • date post

  • Category


  • view

  • download


Embed Size (px)


NTFS Permissions

Transcript of NTFS Permissions

NTFS Permissions, Part 2

NTFS Permissions, Part 2

Richard Civil

While security is essential in todays network, unfortunately some administrators think they are secure if they just have a good firewall. Various studies suggest that up to 65 percent of all network compromises happen from inside the firewall.

There are three areas of security where having a firewall will not helpand these are perhaps more important than having a firewall. Physical security is number one on my list. One of the Microsoft 10 Immutable Laws of Security states "If a bad guy has unrestricted physical access to your computer, its not your computer anymore." You must ensure that any computer that has sensitive data stored on it is physically secure.

Number two on my list is a solid authentication method. Unfortunately, many organizations have very relaxed password policies. Another of the 10 Immutable Laws of Security states, "Weak passwords trump strong security." If I can impersonate you I do not need physical access.

Number three on the list, and the one that requires the most ongoing attention, is proper NTFS permissions. NTFS permissions can seem overwhelming at first. There is a lot to understand: file system permissions, share permissions, inherited and direct permissions, effective permissions, ownership, Kerberos, NTLM, Ticket Granting Tickets, Access Tokens, and more. Lets see if I can help you make sense of all this and learn some neat tricks along the way.

Basics of NTFS Permissions

NTFS permissions include both standard and special permissions. Standard permissions on a folder are Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. Standard file permissions are the same, with the exception of List Folder Contents. Special permissions are considerably more granular, as you can see in Figure 1.


Full Control Specifies whether a user has all other permissions for a file or folder.

Traverse Folder/Execute File For folders, specifies whether a user can move through folders to reach other files or folders. For files, specifies whether a user can run an executable.

List Folder/Read Data For folders, specifies whether a user can view file names and subfolder names within the folder. For files, specifies whether a user can view data in files.

Read AttributesSpecifies whether a user can view the attributes of a file or folder, such as read-only and hidden.

Read Extended AttributesSpecifies whether a user can view the extended attributes of a file or folder.

Create Files/Write DataFor folders, specifies whether a user can create files within the folder. For files, specifies whether a user can change files or overwrite data.

Create Folders/Append DataFor folders, specifies whether a user can create folders within the folder. For files, specifies whether a user can make changes to the end of the file, but not change, delete, or overwrite existing data.

Write AttributesSpecifies whether a user can change the attributes of a file or folder.

Write Extended Attributes Specifies whether a user can change the extended attributes of a file or folder.

Delete Subfolders and Files Specifies whether a user can delete a subfolder or file, even if the Delete permission has not been granted on the subfolder or file.

Delete Specifies whether a user can delete a file or folder.

Change Permissions Specifies whether a user can change permissions on a file or folder.

Take Ownership Specifies whether a user can take ownership of a file or folder.

Each permission, whether standard or special, has both an Allow and a Deny setting. Deny beats Allow if they are applied on the same file or folder. If the permissions are inherited, then the Allow and Deny work a bit differently (for more information regarding this topic, see my column in the November-December 2005 issue of TechNet Magazine at How IT works: NTFS Permissions.

So how do you control what objects receive the permissions you assign? Permissions do not have to apply to the default of "This folder, subfolders and files." You have quite a bit of control in this process, and there are some neat tricks as well. When you assign permissions to a user or group and click Advanced, you have the opportunity to assign very granular permission settings. Near the top of this property sheet is the Apply onto menu, shown in Figure 2. If you select This folder only, the permissions will be inherited by new objects placed in the folder, but existing files and folders will not be affected by the new permissions. With the Apply onto setting, you are controlling which object types will inherit the assigned permissions. These granular permission settings can be used in some very creative ways with useful results.

Figure 2Specifying Where to Apply PermissionsSeveral of my clients have wanted a shared folder in which employees can add and modify their own files, but only have Read permission for the files other employees have created. This is an easy procedure.

1. Grant the Read & Execute and Write permissions for This folder only (selected in the Apply onto list) to the users you want to have access to the folder.

2. Grant the Read & Execute permission for the Subfolders and files only to the same users.

3. Grant the Write permission to the special user Creator Owner.

The effect of this is that all of the users will be able to add files to the folder and read each others files, but only the user that created a file will be able to modify it.

One of the challenges of NTFS permissions is that it follows the discretionary access control list (DACL) model. The difficulty of the DACL model is that the creator of an object is the owner of that object and can set any permissions they choose. This can pose a major security challenge in a high security area of your file system. Unfortunately, not all users have the same level of discretion when it comes to security issues.

One of the better solutions I have come across involves scripting. You will find instructions for using the File Ownership Script Tool at HOW TO: Use the File Ownership Script Tool (Fileowners.pl) in Windows 2000. This Knowledge Base article should help you get started using the script even if you have limited scripting or programming skills.

Once you take ownership of the file or folder, the user who created the object cannot change the permissions you set unless, of course, you give them that permission. The next questions are when does the administrator take ownership, and what happens if the user changes the permissions before the administrator takes ownership. There is excellent information at Watching Folder Activity in VB.NET. You will need some programming skills and the Microsoft .NET Framework installed, as well as Visual Studio .NET (version 1.0 or later). This site takes you through the steps to create code that can monitor a folder for activity and direct how to respond to that activity. If you combine both of these resources, you can monitor a folder and take ownership automatically as soon as a user creates an item.

Permissions and File Systems

Maintaining the correct set of permissions is much easier if you have designed your file system with permissions in mind. Most of my clients have a complete jumble of permissions in each branch of the directory tree, which takes careful planning and lots of time to fix. To maintain security of your file system, one of the most important things you can do is arrange the system so that each branch of the directory tree has one set of permissions. This lets inheritance work for you instead of against you.

Lets assume that you are using the D: drive for departmental files and each department has managers, workers, and assistants. To get started, create a global group for each job description and add the appropriate users to the appropriate group. It is a very good idea to give permissions to groups rather than individuals. (Ill discuss more on this topic in a bit.) Next, assign the Administrators Group Full Control of D:\. Administrators will have full control of everything by inheritance. Finally, give the different groups the permissions shown in Figure 3.

Figure3Group Permissions


Managers Modify

Workers Read & Execute, Write

Assistants Read & Execute

Remember to use the permissions that are appropriate in your organization. If permissions have been modified in one of the departmental folders, its very easy to restore the permissions you set. To do so, just right-click on the departmental folder and choose Properties. In the properties dialog box, click on the Advanced tab, click the Advanced button, and check Replace permission entries on all child objects with entries shown here that apply to child objects. This will force the departmental folder permissions down the tree and will remove any other permissions. This will even force these permissions on files and folders that have inheritance blocked.

Groups and Permissions

Understanding groups and how to use them is essential to proper permissions. There are four different types of groups you can use: local, domain local, global, and universal. Each group type has its own rules for membership and where it can be used. Local groups exist on member servers and workstations. Local groups can only be used to assign permissions to resources on the local computer, but can have members from any domain in the forest. Domain local groups can have permissions to resources in the local domain and can have members from any domain in the forest. Global groups can have permissions anywhere in the forest (hence global), but can only have memb