In Windows 2000 (Win2K), Microsoft redesigned how NTFS handles access control to files and other objects. You might have noticed that Security Configuration Manager (SCM), which Microsoft released in Windows NT 4.0 Service Pack 4 (SP4), handles access control like Win2K does. The new NTFS access control model takes a while to get used to, but it adds some important features. The redesign changes access control in three areas. First, permissions are much more granular, which means you can fine-tune user access. Second, if you come from the Novell NetWare world and like NetWare's dynamic inheritance, the dynamic way Win2K and SCM handle the inheritance of permissions will especially impress you. Third, Microsoft completely revamped the access control dialog boxes.
Granularity Enhancements
Before you use this new model, you need to know how the changes compare with NT's earlier access control model and how to take advantage of the new features. The internal NT access control model has always supported finer control granularity than the interface exposed. Before SP4, you controlled access to files and folders through seven high-level permissions: No Access, Read, Change, Add, List, Add & Read, and Full Control. The high-level permissions are convenient combinations of six low-level special permissions: Read, Execute, Write, Delete, Change Permissions, and Take Ownership. If NT's prebuilt permissions don't fit your needs, you can specify special access and select a custom combination of special permissions. Although these special permissions appear to be at the lowest level, they comprise even lower-level permissions. For example, List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions make up special permission Read (R), so inside NTFS, the permissions that constitute Read (R) are separate. However, before SP4, you couldn't use the Windows Explorer's permissions dialog box to access these special permissions in NTFS. Now you can control this low-level access because Win2K and SCM expose all 14 special permissions, which Table 1 shows, and organize them into 6 higher-level permission groups, including a Special group.
You'll see that No Access is missing from the Win2K and SCM permission groups. Before SP4, an access control entry (ACE) with the No Access permission overrode any access the user might gain through other entries in the ACL. Pre-SP4 NT doesn't provide a way to explicitly deny individual permissions because No Access denied all access. However, Win2K and SCM don't need the No Access permission because of a new enhancement Microsoft added to your granularity of control. Win2K and SCM provide two types of ACEs: Allow and Deny, which Screen 1 shows. You can select the Allow or Deny check boxes in the Security dialog box's Permissions list to control which permissions you grant and which you deny. You can even deny access at the special permissions level. For example, John is a college intern working with the engineering department and needs the same access that the engineering group has except for Write access to the ProjectSchedule folder. The ProjectSchedule folder ACL grants the Engineering group Change access. To avoid completely redoing your group structure to prevent John from accessing this folder, you can create an Interns group with John as a member and add another ACE that denies interns Write access. John will still be able to read the folder but not write to it.
Dynamic Inheritance
In NT's pre-SP4 model of static inheritance, each object receives a copied ACL from its parent at the time of the object's creation. After creation, the object is independent of the parent, and changes to the object's parent ACL don't affect the child object unless you select the Replace Permissions on Subdirectories and Replace Permissions on Existing Files check boxes in NT's Folder Permissions dialog box. Selecting these check boxes forces the parent's ACL to copy to all child objects, and you use these check boxes when you need to change the permissions for an entire branch of the folder tree. Microsoft designed ACLs this way to speed up access control evaluation. However, this design complicates maintenance for administrators because the process overwrites any legitimate exceptions to the parent's ACL that are further down the tree. Consequently, when you create a new group using pre-SP4 NT, you have no way to grant the group access to a given branch of folders without affecting existing permissions.
Win2K and SCM address these inheritance problems. Now permissions automatically flow down from a parent folder to all child folders and files. When you change a folder's ACL, the ACEs automatically copy to the child objects' ACLs. However, the process doesn't overwrite ACEs that you directly defined on child objects. This exception is possible because a flag on each ACE specifies whether the object inherited the ACE or whether an administrator defined the ACE (noninherited). When the system copies ACEs down to child objects, it replaces only the entries with the inherited flag and leaves the noninherited entries alone.
At this point, you might wonder what the system does when inherited and noninherited permissions conflict and when you don't want permissions to propagate down the tree. Win2K and SCM use the sequence in which the Security Reference Monitor (SRM) evaluates ACEs to handle conflicts between inherited and noninherited permissions. The Win2K and SCM SRM component approves or denies access when a program tries to open an object. The SRM processes noninherited permissions first, then inherited permissions. The SRM processes these entries one at a time, comparing the specified user or group SID in the ACE with the SIDs in the program's access token.
When you run a program, it receives an access token consisting of your SID and the SIDs of groups that you belong to. When the SRM encounters an ACE that matches a SID in your access token, the SRM evaluates that ACE's permissions. If the ACE explicitly denies the type of access your program is requesting, the SRM immediately exits the loop, denying access. Otherwise, the SRM accumulates the permissions the ACE granted. Then, the SRM checks whether it has accumulated all the permissions that the program requested. If the SRM has accumulated all requested permissions, it grants the requested access; if the SRM hasn't accumulated all requested permissions, it processes the next ACE. If the SRM reaches the end of the ACL before accumulating the requested permissions, the SRM exits, denying access. Therefore, when conflicts between noninherited and inherited ACEs exist, the noninherited ACEs win. For example, Fred, who is a member of the SalesReps group, tries to open commission.doc for Read and Write access. Commission.doc has one inherited ACE that denies Read access to the SalesReps group and also has a noninherited ACE that grants Fred Read and Write access. Fred will succeed in opening the file because the SRM will satisfy the request for Read and Write access before it encounters the inherited permission that denies access.
What happens when an allow-type ACE conflicts with a deny-type ACE and both ACEs have the same inheritance? The SRM always processes deny-type ACEs first for each kind of inheritance. Consequently, when multiple ACEs are applicable for a user, the permissions are cumulative; however, noninherited ACEs prevail over inherited ACEs, and within each kind of inheritance, deny-type ACEs prevail over allow-type ACEs, as Figure 1 shows. You can specify general permissions high in the folder tree and augment these permissions as needed for lower folders. You can also use deny-type permissions for limited exceptions to group membership.
Controlling Inheritance
You might need to block permissions from propagating down from parent folders to child folders and files. Win2K and SCM let you block inheritance at the child level or parent level. For example, you might want to block inheritance at the child level for a file or folder that requires a different set of permissions from its parent. In the child's ACL, you can simply clear the Allow inheritable permissions from parent to propagate to this object check box from the Properties dialog box's Security tab, which Screen 1 shows. Clearing this check box closes a gate above the child object and blocks any inherited permissions. When you use this method to disable inheritance, a dialog box gives you the option to remove the inherited permissions and start with an empty ACL or choose to make a noninherited copy of the inherited permissions that you customize for that child.
You can control inheritance at the parent level in two ways. First, each parent ACE has a flag that determines whether the system will apply the ACE at a level lower than the parent's immediate children. When you select the Apply these permissions to objects and/or containers within this container only check box from the Permission Entry for Projects dialog box's Object tab, which Screen 2 shows, the system won't recursively propagate that particular ACE to grandchild objects. This flag is an ACE-specific setting and doesn't apply to the entire ACL.
The second method you can use to control inheritance at the parent level is also an ACE-specific setting and lets you specify whether the ACE applies to the folder, files within the folder, or subfolders within the folder. The Apply onto drop-down list on the Permission Entry dialog box's Object tab lets you select any combination of folders, subfolders, and files that you want to apply the ACE to.
You can use the Apply onto drop-down list to produce the same results that you get when you use pre-SP4's Add and Add & Read permissions (which don't exist in Win2K and SCM). Let's say you have a rudimentary file-based client/server application in which the client application creates a file in a shared folder to submit requests to the server process. For confidentiality purposes, you need to provide users access to their request files, but you want to deny the users access to other users' request files. When you use pre-SP4 NT, the ACL requirements look like those in Table 2, page 92. When you use Win2K or SCM, the ACL requirements look like those in Table 3, page 92.
At the parent level, you can use the two control methods together to determine exactly how deep and to which child objects parent permissions will propagate. However, you can easily confuse these two methods. The Apply these permissions to objects and/or containers within this container only check box controls recursive propagation, and the Apply onto drop-down list controls which kinds of objects receive the permissions.
You use a third method to control permission propagation when you need to force a branch of a folder tree to have consistent permissions. For example, several administrators have managed the engineering department's Projects folder, so you find several subfolders with incorrect permissions and decide to reset the permissions. You edit the Projects folder's ACL and select the Reset permissions on all child objects and enable propagation of inheritable permissions check box on the Access Control Settings dialog box's Permissions tab, which Screen 3 shows. Selecting this box clears the ACLs of all child objects and propagates the Project folder's permissions down to all children.
New Interface
The access control interface has changed significantly to accommodate the new features. You need to explore the new interface because Microsoft found presenting an entire ACL at a glance too complex. The Security tab of an object's Properties dialog box provides an overview of the object's permissions. The Name list displays each user or group that the ACL includes. The Permissions list displays high-level permissions specified for the user or group selected in the Name list. Unfortunately, you can see only one user or group's permissions at a time, and this dialog box doesn't display whether an administrator has granted a user or group a customized set of special permissions. However, when you select an entry in the Name list, the dialog box displays a message notifying you that additional permissions are present but not in view. This Security dialog box also doesn't reveal permission inheritance, and you can't determine the individual ACE settings that control whether permissions propagate to child objects.
If you use the standard permission groups and avoid controlling special permissions, this dialog box suffices. However, to improve the Security dialog box, Microsoft needs to combine the Name and Permissions lists so that, provided you stick with the predefined permission sets, you can see all the permissions at a glance rather than needing to scroll through the list. Also, this initial dialog box needs to alert you that customized permissions are present somewhere in the ACL without requiring you to scroll through the entire Name list.
Selecting Advanced from the Security tab of an object's Properties dialog box displays the Access Control Settings dialog box. This dialog box shows you almost every detail of the entire ACL. An ellipsis in the Permission column alerts you that more detail is available if you stretch the dialog box. However, you can't change many options from this dialog box, and it doesn't show which ACEs have recursive propagation turned off. To manage special permissions and recursion, select the relevant Permission entry, then select View/Edit. The View/Edit option displays the Permission Entry dialog box. This dialog box lets you maintain each ACE property and the Apply onto drop-down list of files and folders.
The NTFS dynamic inheritance model is a dream come true for many administrators, and the access control features give you more control and flexibility. But this granularity comes at a price because the interface is more complex and requires more interaction to assess permissions. Good security depends on your ability to specify granular access control and to ascertain at a glance who has which permissions.
