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 aren't 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 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:
Read & Execute
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 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:
Traverse Folder/Execute File
List Folder/Read Data
Read Extended Attributes
Create Files/Write Data
Create Folders/Append Data
Write Extended Attributes
For example, the specific advanced permissions that are used to create the Read standard permission include:
List Folder/Read Data
Read Extended Attributes
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 won't 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 don't 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.
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, let's look at a scenario that you too can create to prove that Deny permissions don't 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 Allow-Read & 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:
Permissions are almost the same from Windows NT's NTFS 4.0 to Windows 2000/XP/2003's 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.