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.
Figure 1 NTFS Special Permissions
Permission
Full Control
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
Change Permissions
Take Ownership

Description
Specifies whether a user has all other permissions for a file or folder.
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.
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.
Specifies whether a user can view the attributes of a file or folder, such as read-only and
hidden.
Specifies whether a user can view the extended attributes of a file or folder.
For folders, specifies whether a user can create files within the folder. For files, specifies
whether a user can change files or overwrite data.
For 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.
Specifies whether a user can change the attributes of a file or folder.
Specifies whether a user can change the extended attributes of a file or folder.
Specifies whether a user can delete a subfolder or file, even if the Delete permission has
not been granted on the subfolder or file.
Specifies whether a user can delete a file or folder.
Specifies whether a user can change permissions on a file or folder.
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 2 Specifying Where to Apply Permissions

Several 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.
Figure 3 Group Permissions
Group
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 members from the local domain. Universal groups can have members from any
domain in the forest and can have permissions to resources in any domain in the forest. The groups are
summarized in Figure 4.
Figure 4 Group Membership and Permissions
Group Type
Local
Domain Local
Global
Universal

Member Scope
Permission Scope
Any domain in the forest Local machine
Any domain in the forest Local domain
Local domain
Anywhere in the forest
Any domain in the forest Anywhere in the forest

I like the way Microsoft now presents the groups as being in two categories: user groups and resource groups.
The two user category groups are global groups and universal groups. Global groups are the primary group type
for users. Add users that need access to the same resources into the same global group. If there are several
domains in your forest and there are global groups in multiple domains that need access to resources in multiple
domains, add the global groups to universal groups.
Domain local and local groups are considered to be resource groups. Essentially, you give permissions to a
domain local or local group and then add global or universal groups to the domain local or local group to
receive the assigned permissions. Ill take a closer look at domain local and local groups later in this column.
The task of assigning permissions needs to be approached with care and attention to detail. Every time you
assign permissions there is a chance to compromise the security of your data. The basic idea is to assign
permissions to a group once, then add users to the group to get those permissions. That way, you assign
permissions a minimum number of times.
In a smaller environment, it is often an acceptable practice to use global groups for both organizing users and
for permissions. Name the global groups in a manner that gives you an idea of the group membership and group
type. A global group containing accountants from the ABC domain might be named gg_acountants_ABC.
Larger environments necessitate a bit more complexity. Give permissions to domain local groups and add the
global groups to the domain local groups to get the assigned permissions. Naming is also important with domain
local groups. The name should reflect the group type, the resource, and the assigned permission. Say you have a
folder named Data on a server named FileSrv1. If you want a domain local group to have Read permission for
this folder, the group should have a name like DL_Data_FileSrv1_read. Give the domain local group the desired
permission and add the global groups for the users that should get that permission. It can be time consuming to
set up, but once its done you can easily control access to resources just by moving users into and out of global
groups. The names of the groups should make it clear at a glance what permissions you are effectively granting.
If you hire a data entry person, you can just add him to the DataEntry global group and he automatically has
access to all of the resources that data entry workers should have. If your new employee does a great job and the
company promotes him to the help desk, you can take him out of the DataEntry group and add him to the
HelpDesk Group.
It should be obvious at this point that a well-planned and carefully implemented file system and proper
permissions are essential. Users can be in many global groups, which can be nested in many universal or
domain local groups. Even with the best planning, it can be difficult to determine exactly what permissions a
specific user has to a specific file or folder, though Windows XP and Windows Server 2003 make it much
easier.

Figure 5 Effective Permissions for a Particular User

To find the effective permissions for a user to access the property sheet of the file or folder, select the Security
tab, click the Advanced button, and then select the Effective Permissions tab. Click the Select button and select

the user you want to assess. Click OK and the property sheet will now show you the effective permissions for
that user (see Figure 5). You can only read, not change, permissions on the Effective Permissions tab.
Remember, though, that the information shown here only deals with the NTFS part of what comprises the actual
effective permissions. Share Permissions must also be taken into account to find the users actual permission to
a file or folder.
Share Permissions
To access a file or folder remotely, both NTFS and Share Permissions are evaluated to determine the actual
rights the user has to that object. Between NTFS and Share Permissions, the effective permissions are
whichever is most restrictive. If the NTFS permission is Read and the Share Permission is Full Control, the
effective permission is Read because it is the most restrictive. If the NTFS and Share Permissions were
reversed, Read would still be the effective permission.
NTFS and Share Permissions work quite differently from each other. NTFS has a rather complex process of
inheritance (see "NTFS Permissions" in the November-December 2005 issue of TechNet Magazine) but
essentially a user gets the combination of NTFS permissions assigned to them and any groups they are in,
including nested groups. In general, Deny overrides Allow. You have to enter the file system on a remote
computer by accessing a share. The Share Permissions are evaluated on the share you use to enter the file
system. There is no inheritance with shares. The Share Permissions assigned on the share you used to enter the
file system are the permissions you have in that branch of the directory tree, even if there is another share lower
in the tree with different permissions.

Figure 6 Hierarchy of Shared Folders

For example, I share a folder named TestFolder and allow Full Control permis-sion to the Everyone group.
There is a folder nested inside TestFolder named InsideTest. I share InsideTest and deny Full Control
permission to the Everyone group (see Figure 6).
When I access the computer using a UNC path, I see both TestFolder and InsideTest as top-level shared folders.
There is no indication that these are actually nested folders. If I double-click InsideTest, I am denied access, as
expected, due to the Deny permission. If I double-click TestFolder and then in the window that opens doubleclick InsideTest, I have Full Control permission to that folder. I entered the file system through the TestFolder
share, so I have the share permission of Full Control throughout that branch of the directory tree (see Figure 7).

Figure 7 Effective Share Permissions

In the previous example, the D: drive is being used for departmental files. Each department has managers,
workers, and assistants that need specific permissions as well as the administrators who need full control of the
entire volume. The administrators group has full control of each drive by default. Inheritance will propagate this
to all of the departmental folders, so the NTFS permissions for the administrators group are granted

automatically. The root of each drive is also shared as a hidden share (D$ in this case) with administrators
having full control. Each departmental folder needs to be shared with department managers getting Change
permission, department workers also getting Change permission, and department assistants assigned Read
permission.
The first thing I usually do with both share and NTFS permissions is remove the Everyone group. Everyone
includes anonymous accounts like Guest and IUSR_computername (the Internet guest account). In Windows
NT and Windows 2000 the Everyone group also includes null sessions. Authenticated Users includes all valid
user and computer accounts in the forest, but does not include any guest or anonymous accounts. Most of the
time if you want to give permissions to everyone, what you actually mean is Authenticated Users.
Permissions and Active Directory
Lets take a quick look at how the processes of authentication and authorization work in Active Directory.
Windows 2000 and later uses Kerberos, a certificate-based secure protocol, for both of these processes.
TechNet Online Resources
For more information on how NTFS permissions work and details about some handy tools to help you manage
NTFS, visit these TechNet Online resources.
How Permissions Work
Not sure of the difference between ACE and ACL? Confused by permissions on shared folders? For details on
working with NTFS permissions, read this article.
Planning File Server Security
When protecting your organization's data, it's important to plan ahead. Check out these best practices when
designing a security strategy for your file servers.
How Security Descriptors and Access Control Lists Work
Get a detailed overview of how security descriptors and access control lists work in Windows Server 2003, so
you can start securing objects individually.
Security Descriptors and Access Control Lists Tools and Settings
There are a number of tools available to help you work with security descriptors and access control listssome
are included with Windows Server 2003 and others can be downloaded as part of the Windows Server 2003
Resource Kit Tools. Here's an overview of some of these apps and what you can do with them.
When a user logs on to a domain, a Ticket-Granting-Ticket (TGT) is created. This ticket contains the security
identifiers (SIDs) of the user as well as all groups that the user is a member of, including nested groups. If the
user is in 25 global groups which are each in 25 domain local groups, that is a total of 650 SIDs on the TGT. A
SID looks something like this: S-1-5-21-3204519953-1226544935-3965933272-1009. The first part of the SID
identifies the database to which the account belongs. The last part is the Relative Identifier (RID). The RID of
this account is 1009. The RID increments by one for each new account and Active Directory can create literally
billions of accounts. The moral of this story is that SIDS can be large and having a TGT containing 650 SIDS
will be very large. Most users will have considerably fewer than 650 SIDS on their TGT, but even a small TGT
is a fairly substantial object.
The TGT is only part of the story. Every resource a user accesses on a remote computer causes quite a chain of
events. Lets say you try to access \\Computer1 through Explorer. Your computer sends your TGT (with all of
the SIDs) to the domain controller with a request to access Computer1. The domain controller verifies the SIDs
and puts them on a Session Ticket (ST), also called a Service Ticket, and sends it back to your computer. Your
computer sends the ST to Computer1 with the request for access.
Practically speaking, this authentication process means that all of the SIDs hit the network three times for each
network access. If you have plenty of bandwidth, this is fine. If you have bandwidth issues, especially when
everyone first logs on for the day, consider using local groups instead of domain local groups.
When the ST arrives at the destination, Computer1 extracts the SIDs from the ST and searches the local
Security Account Manager (SAM) database and retrieves the SIDs for local groups that the user belongs to. The
SIDs of these local groups are added to the Access Token on the computer where they reside. Local groups
never hit the wire. The SIDs on the Access Token are measured against the SIDs on the DACL to determine the

users access level to the requested resource. In the previous example, if I used local groups instead of domain
local groups, the tickets would have contained 25 SIDs instead of 650.
Another way to conserve on the number of SIDs on the tickets is to use each domain local group on multiple
resources. Unfortunately, security tends to slip when domain local groups are multi-purposed. Say your
organization has five administrators and each of these administrators has control of different resources.
Administrator Alex creates a domain local group and gives it permission to several resources under her control.
The other four administrators do the same. Now this one domain local group has been given access permissions
to many resources under different administrators control.
Heres where things come unglued. Some users from a specific department call administrator Alex and
complain that they do not have access to one of the resources. Alex solves the problem by adding a global group
containing the users in that department to the domain local group that has permissions to the resource. Now
those users have access to all of the different resources that each of the administrators have given that domain
local group access to. As you can see, its just too easy to combine users and groups in ways that affect
permissions on many resources unintentionally.
I recommend single-purposing domain local groups (one group for one permission on one resource) unless you
have a very organized IT department, or your organization has data that does not require much in the way of
security.
Conclusion
Physically securing computers that contain sensitive data and establishing a solid authentication methodology
such as smart cards or complex passwords are the first steps toward keeping your network secure. Within your
network, you can create a group permissions strategy that works for your organization.
The Microsoft strategy is embodied in the cryptic A-G-DL-P. Accounts go into global groups, which go into
domain local groups, which are assigned permissions to resources. This method will work for many
organizations. Remember to avoid giving domain local groups permissions for multiple resources, which can
circumvent your efforts at more granular control over permissions.
Also remember to carefully apply NTFS and share permissions. Give users the level of access that they need to
do their job and no more. Permissions can be inherited through shares, so plan your file system and share
strategy accordingly. A little foresight and planning will give you better results further down the road.

Understanding Windows NTFS Permissions

Understanding Windows NTFS Permissions
Even though Windows permissions have been around for a long time, I still run into seasoned network
administrators that arent aware of the new changes that came with Windows 2000 so long ago. When Microsoft
released Windows 2000, they released a new version of NTFS, which was versioned 5. The new NTFS
permissions were essentially the same logical control as the older version that was available in Windows NT,
however, there were some radical and essential changes that occurred to control how the permissions were
inherited and configured for each file and folder. Since NTFS permissions are available on every file, folder,
Registry key, printer, and Active Directory object, it is important to understand the new methods and features
that are available once you have Windows 2000, Windows XP, or Windows 2003 Server installed to control
resources.

Standard Permissions
Standard permissions are those permissions that control a broad range of detailed permissions. The most
popular and infamous standard permission is Full Control. This is what everyone wants, but in reality very few

should get. Full Control allows the user that is granted this suite of permissions to do virtually anything to the
object the permissions are associated with. The other standard permissions include the following:
Files:
Modify
Read & Execute
Read
Write
Folders have the same standard permissions as files, except there is one additional standard permission List
Folder Contents.
When you look at Registry keys, printers, and Active Directory objects, there is a totally different set of
standard permissions for these objects. The security tab of each object will list the standard permissions, as
shown in Figure 1 for a typical organizational unit (OU) within Active Directory.

Figure 1: Standard permissions for an OU in Active Directory

Advanced Permissions
Advanced permissions are the detailed permissions that are grouped together to create the standard permissions.
Since advanced permissions are used in combinations to create the standard permissions, there are more of them
overall. For a file, here is a list of the advanced permissions:
Full Control
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
Read Permissions

Change Permissions
Take Ownership
For example, the specific advanced permissions that are used to create the Read standard permission include:
List Folder/Read Data
Read Attributes
Read Extended Attributes
Read Permissions
When you evaluate the advanced permissions for a folder, they are identical to those of a file. However, when
you investigate the advanced permissions of a printer or Registry key, they are completely different. If you want
to see the power and control that NTFS 5.0 provides for access control, it is best to investigate the permissions
of an OU within Active Directory. Upon first glance, I calculate that you have over 10,000 individual advanced
permissions that you can set for an OU, as you can see a partial listing in Figure 2.

Figure 2: Advanced permissions for an OU in Active Directory

Inherited vs. Explicit Permissions

There are two variations of permissions that you will see for any one entry (user, computer, or group) listed on
the access control list (ACL). If we look at the root drive, C:, you can add or modify the permissions for any
entry on the ACL. If you create a new folder under C:, say a new folder named Data (C:\Data), you wont be
able to modify the permissions for any existing entries. This is because the permissions from C: inherit down to
all subfolders and files automatically. If you dont want the permissions from C: to inherit down the C:\Data,
but still want them to inherit down to other subfolders below C:, you would configure the C:\Data folder to stop
inheriting by removing the check from the Inherit from parent the permission entries that apply to child
objects. Include these with entries explicitly defined here, as shown in Figure 3.

Figure 3: You can control inherited permissions on any folder or file

At any level within the resource structure, you can always add new entries to the ACL. These entries,
specifically for the target resource, are called explicit permissions, since they are configured directly on the
resource. If the default inheritance is enabled for subfolders and files, these explicit permissions will inherit
down to subsequent resources, like the original permissions did from C:\ down to C:\Data. It is easy to tell the
difference between inherited permissions and explicit permissions, by the check mark on the permissions for the
entry. If the check is not grayed out, the permissions are explicit.

Allow vs. Deny Permissions

When establishing permissions, you need to specify whether the entry should have access (Allow) or not (Deny)
to the resource. The Local Security Authority (LSASS) then controls the access to the resource, based on the
security ID (SID) that you placed on the ACL to the SID placed on the security token that is given to the user at
logon. If the SID associated with the user is on the ACL, the LSASS must determine whether the access is set to
Allow or Deny. The Allow and Deny permissions inherit down through the structure as described in the section
above on inheritance.
You will get warnings from the ACL editor when you create Deny entries, as shown in Figure 4.

Figure 4: Deny entries on the ACL will cause the system to warn you about the limited access you are
providing
It is not common to configure resources with Deny permissions, because of the nature of how permissions are
evaluated. It is more common to exclude the user or group from the ACL instead of configuring them to have
explicit Deny permissions. The fact that the user or group SID is not on the ACL will have the same result of
No Access to the resource, without needing to configure any special entries on the ACL. It is only in the rare
instance that a user or group should be explicitly denied access that you configure Deny permissions. Denial of
access to resources by omission from the ACL is easier to troubleshoot, manage, and configure.

Permission Precedence
I hear all of the time from students and other network administrators (even the dialog box in Figure 4) that Deny
permissions take precedence over Allow permissions. Unfortunately, this is not always the case. To prove my
point, lets look at a scenario that you too can create to prove that Deny permissions dont always take
precedence over Allow permissions.
In our scenario, we are going to look at a folder, C:\Data\HR, which contains both public and private files. We
have allowed the C:\Data\HR folder to inherit the permissions from C:\Data, which includes just basic
permissions from the root folder. We have also included the HR group on the ACL, giving the Group AllowRead & Execute permissions. The final explicit entry on the ACL is for the non-HR group, which is given
Deny-Full Control.
Below the HR folder are two files: Public.doc and Private.doc. The Public folder just allows for normal
permission inheritance, so there are no special permissions added to the ACL. However, the private file has
some explicit permissions added to the ACL. Since the Executive group needs to be able to read the contents of
the private folder, this group is added explicitly with the Allow-Read & Execute permission. The result of this
configuration is shown in Figure 5, which clearly shows that the Allow permission for the Executive group has
a higher precedence than the Deny permission associated with the non-HR group. Since every executive is
included in both groups, you can see that here is a case where Allow permissions have precedence over Deny
permissions.

Figure 5: Allow permissions can have precedence over Deny permissions

The scenario proves that there is a hierarchy of permissions for NTFS 5.0 resources. The hierarchy of
precedence for the permissions can be summarized as follows, with the higher precedence permissions listed at
the top of the list:
Explicit Deny
Explicit Allow
Inherited Deny
Inherited Allow

Summary
Permissions are almost the same from Windows NTs NTFS 4.0 to Windows 2000/XP/2003s NTFS 5.0. One of
the main differences is the way that permissions inherit down through the structure with inherited and explicit
permissions. It used to be that, if there was a Deny permission on the ACL, it was always evaluated first, then
the Allow permissions would follow. Now, the permission hierarchy must be evaluated considering not only the
Deny vs. Allow, but whether the permission is explicitly set or inherited down from a parent resource.

NTFS Permissions
In any Windows network, you can set sharing permissions for drives and folders. On that network, each user
can choose to share entire drives or individual folders with the network.
NTFS (NT File System) permissions are available to drives formatted with NTFS. The advantage with NTFS
permissions is that they affect local users as well as network users and they are based on the permission granted
to each individual user at the Windows logon, regardless of where the user is connecting.
NTFS is the standard file system of Windows NT and all Windows operating systems that have come after it.
Windows 2000 and older introduced some far-reaching changes that included control over inherited permissions
and how permissions were configured to share files and folders. You use shared folders to provide network
users with access to file resources.
Administrators can use the NTFS utility to provide access control for files and folders, containers and objects on
the network as a type of system security. Known as the "Security Descriptor", this information controls what
kind of access is allowed for individual users and groups of users.
Along with the additional functionality that NTFS provides comes the potential for complex configurations that
can lead to administration headaches. If you don't have a thorough understanding of various permissions and
their relationships, it can be difficult to sort out a permission problem when it occurs.
For a more low-level description of NTFS SECURITY_DESCRIPTOR, see Metafile $Secure in this guide.
NTFS General Information > NTFS Permissions > Setting NTFS Permissions

Setting NTFS Permissions

The most common way to set permissions is to use Windows Explorer.
To set permissions for an object:
1. In Windows Explorer, right-click a file, folder or volume and choose Properties from the context menu.
The Properties dialog box appears.
2. Click the Security tab.
3. Under Group or user names, select or add a group or user.
4. At the bottom, allow or deny one of the available permissions.

Properties dialog box showing Security tab

File and Folder Advanced Permissions

The permissions that you can set on folders and files depend on how an object is being accessed.
The reason that these permissions are called "advanced" permissions is because they appear in the Advanced
Security Settings dialog box. To get to them, you must click the Advanced button in the Properties dialog box,
Security tab.
The following is a list of file and folder advanced permissions with a short description for each:

Traverse Folder/Execute File

o Traverse Folder: Allows or denies moving through a restricted folder to reach files and folders
beneath the restricted folder in the folder hierarchy. Traverse folder takes effect only when the
group or user is not granted the "Bypass traverse checking user" right in the Group Policy snapin. This permission does not automatically allow running program files.
o Execute File: Allows or denies running program (executable) files.
List Folder/Read Data
o List Folder: Allows or denies viewing file names and subfolder names within the folder. List
Folder only affects the contents of that folder and does not affect whether the folder you are
setting the permission on will be listed.
o Read Data: Allows or denies viewing data in files.
Read Attributes

Allows or denies viewing the attributes of a file or folder, for example, "read-only" and "hidden".
Read Extended Attributes
o Allows or denies viewing the extended attributes of a file or folder. Extended attributes are
defined by programs and may vary by program.
Create Files/Write Data
o Create Files: Allows or denies creating files within the folder.
o Write Data: Allows or denies making changes to a file and overwriting existing content.
Create Folders/Append Data
o Create Folders: Allows or denies creating subfolders within the folder.
o Append Data: Allows or denies making changes to the end of the file but not changing, deleting,
or overwriting existing data.
Write Attributes
o Allows or denies changing the attributes of a file or folder, for example, "read-only" or "hidden".
o The Write Attributes permission does not imply creating or deleting files or folders, it only
includes the permission to make changes to the attributes of an existing file or folder.
Write Extended Attributes
o Allows or denies changing the extended attributes of a file or folder. Extended attributes are
defined by programs and may vary by program.
o The Write Extended Attributes permission does not imply creating or deleting files or folders, it
only includes the permission to make changes to the extended attributes of an existing file or
folder.
Delete Subfolders and Files
o Allows or denies deleting subfolders and files, even if the Delete permission has not been
granted on the subfolder or file.
Delete
o Allows or denies deleting the file or folder. If you don't have Delete permission on a file or
folder, you can still delete it if you have been granted Delete Subfolders and Files on the parent
folder.
Read Permissions
o Allows or denies reading permissions of a file or folder.
Change Permissions
o Allows or denies changing permissions of the file or folder.
Take Ownership
o Allows or denies taking ownership of the file or folder. The owner of a file or folder can always
change permissions on it, regardless of any existing permissions that protect the file or folder.
Synchronize
o Allows or denies different threads to wait on the handle for the file or folder and synchronize
with another thread that may signal it. This permission applies only to multithreaded,
multiprocessing programs.
o

Moving and Copying NTFS Protected Files

Moving and copying protected files is similar to moving and copying a compressed file. When you copy a
protected file to a folder on the same, or a different volume, it inherits the permissions of the target directory.
However, when you move a protected file to a different location on the same volume, the file retains its access
permission setting as though it is an explicit permission.
When data is moved within the same volume, the data is not actually relocated, the pointer to it is merely
changed and that is why it retains the ACL (Access Control List).

NTFS General Information > NTFS Permissions > Explicit vs. Inherited Permissions

Explicit vs. Inherited Permissions

Each permission that exists can be assigned one of two ways: explicitly or by inheritance. For this reason,
permissions are referred to as explicit permissions and inherited permissions.

Explicit permissions are permissions that are set by default when the object is created, or by user action.
Inherited permissions are permissions that are given to an object because it is a child of a parent object.

Similar to the way rights are managed for groups of users, permissions are best managed for containers of
objects. Objects within the container inherit all the access permissions in that container.
For example, you might explicitly give permissions to a folder named MyFolder. All subfolders created within
MyFolder automatically inherit the permissions assigned to MyFolder.
In the example above, it is possible to stop subfolders from inheriting access permissions. To do this, you must
explicitly clear a setting that causes the inheritance.

Inherited permissions

Permission Precedence
Because of the fact that users have can have many different rights settings and objects can have many different
permission settings, it is possible that conflicting permission settings might apply to a particular object and
access method.
When this occurs, the system must engage in a process of resolving the various permissions to determine which
ones should govern the access.

Here are some rules for resolving permissions conflicts:

1. "Deny" permissions generally take precedence over "allow" permissions.
2. Permissions applied directly to an object (explicit permissions) take precedence over permissions
inherited from a parent (for example from a group).
3. Permissions inherited from near relatives take precedence over permissions inherited from distant
predecessors. So permissions inherited from the object's parent folder take precedence over permissions
inherited from the object's "grandparent" folder, and so on.
4. Permissions from different user groups that are at the same level (in terms of being directly-set or
inherited, and in terms of being "deny" or "allow") are cumulative. So if a user is a member of two
groups, one of which has an "allow" permission of "Read" and the other has an "allow" of "Write", the
user will have both read and write permission--depending on the other rules above, of course.
Although Deny permissions generally take precedence over allow permissions, this is not always the case. An
explicit "allow" permission can take precedence over an inherited "deny" permission.
The hierarchy of precedence for the permissions can be summarized as follows, with the higher precedence
permissions listed at the top of the list:

Explicit Deny
Explicit Allow
Inherited Deny
Inherited Allow

Also true:
File permissions override folder permissions, unless the Full Control permission has been granted to the folder.

Combining Shared Folder Permissions and NTFS Permissions

This section will be of interest to an administrator who is familiar with security settings on a FAT32 volume
where permissions for a shared folder are the only permissions protecting files and subfolders in the shared
folder.
When using share permissions and NTFS permissions together, if there is a conflict in the configuration, the
most restrictive permission prevails. For example, if a user has NTFS full access to a specific file in a folder that
is not shared, the user cannot access the file from the network. In this case, the user can sit down at the
computer that contains the file, log in and access the file, because sharing permissions do not affect local access.
One strategy for providing access to resources on an NTFS volume is to share folders with the default shared
folder permissions and then control access to shared folders by assigning NTFS permissions. When you share a
folder on an NTFS volume, both shared folder permissions and NTFS permissions combine to secure file
resources.
Shared folder permissions provide limited security for resources. You gain the greatest flexibility by using
NTFS permissions to control access to shared folders. Also, NTFS permissions apply whether the resource is
accessed locally or over the network.
When you use shared folder permissions on an NTFS volume, the following rules apply:

You can apply NTFS permissions to files and subfolders in the shared folder. You can apply different
NTFS permissions to each file and subfolder that a shared folder contains.

In addition to shared folder permissions, users must have NTFS permissions for the files and subfolders
that shared folders contain to gain access to those files and subfolders.
When you combine shared folder permissions and NTFS permissions, the more restrictive permission is
always the overriding permission.

Planning
The first step is planning how folders will be shared. To do this, make a list of what data will be stored and what
user groups will require access. For example, types of data may be employee data, customer account status data,
customer service data, management guideline data, and so on. Groups of users may be managers,
administrators, sales reps, customer service reps, and so on.
Create a table with three columns:

Column 1 displays each data folder by name and location

Column 2 displays the shared folder name
Column 3 displays the name of the user group with assigned folder permissions
File and Printer Sharing for Microsoft Networks

To share any folders or other network objects, you must have "File and Printer Sharing for Microsoft Networks"
as a networking component in your local area connection.
To add this component:
1. In the Windows System Tray, right-click the Local Area Connection icon and choose Status from the
context menu. The Local Area Connection Status dialog box appears.

2. Click Properties. The Local Area Connection Properties dialog box appears.
Local Area Connection Properties dialog box

3. To add the File and Printer Sharing for Microsoft Networks check box, click Install and choose it
from the Services category.
4. Select the File and Printer Sharing for Microsoft Networks check box and click OK.

Sharing and Adding Permissions

In this example, we will use a folder named MktApps. This example folder holds the applications that will be
used by all users. You must be logged on as a member of the Administrators group.
To share the MktApps folder:
1.
2.
3.
4.
5.
6.
7.

In Windows Explorer, locate the folder, named MktApps.

Right-click MktApps, and click Properties in the context menu. The Properties dialog box appears.
Click the Sharing tab.
Click Share This Folder. The Share Name defaults to the name of the folder.
To make the share name different from the folder's name, change it here.
In the Comment box, type Shared Marketing Applications.
Click Permissions. The Permissions dialog box appears.

The default permissions for a new folder shows that the Everyone group has Full Control permissions.

Permissions dialog box

1. Select Everyone.
2. Click Remove. The Everyone group is removed.
3. Click Add. The Select Users or Groups dialog box appears.
You computer name appears in the From this location box.

Select Users of Groups dialog box

1. Select Administrators and click OK.

If the object name (Administrators) does not appear, type it in the text box. You may type a user or group
name. If you do not know the exact name, click Advanced and select Find Now to search for available
choices.
2. Click OK to return to the Properties dialog box.

3. In the Permissions panel, under Allow, select the Full Control check box.
4. Click OK.
Windows Explorer changes the appearance of the folder icon by placing a hand under it to indicate that it is a
shared folder.
If you are sharing a drive, the process is slightly different. If a default share is already set up, the share name
displays a dollar sign ($). A share set up in this way is for administrative use only; ordinary users won't be able
to see or browse a drive shared in this way on the network. Consequently, if you want to share an entire drive
like this on your network, you must create an additional share for it.

Sharing properties

To create a new share for a drive, click the New Share button and then fill in the Share Name, any comment you
want to make, and a user limit for concurrent usage (if desired). While you're in the New Share dialog box (see
Figure C), you can click the Permissions button to specify who will have access to the shared drive or you can
save that for later.

New Share dialog box