Access control information is first written to an object’s security descriptor when the object is created. This information can later be modified. In both cases, the information that goes into a security descriptor can come from one of the following sources:
When a subject creates a new object, it can assign a security descriptor to the object. If the subject does not assign a security descriptor, the operating system uses access control information inherited from the parent object to create one. If no information is available to inherit, the operating system uses default access control information provided by the object manager for the particular type of object that the subject wants to create.
After an object is created, information in its security descriptor can be changed by the object’s owner or by another user who has the owner’s permission. Changes can also come from the parent object when that object’s owner modifies its security descriptor. Every time the security descriptor on a container object is changed, the object manager propagates any changes that are marked as inheritable to all objects in the container.
Some objects can contain other objects. For example, an NTFS folder object can contain file objects and other folder objects. A registry key object can contain subkey objects. An Active Directory organizational unit (OU) object can contain other OU objects as well as user objects, group objects, and computer objects. Terminal objects contain Window Station objects that contain Desktop objects that contain Window objects. Any object that is contained by another object is called a “child” object. A “child” object’s container is its “parent” object.
Child objects can inherit access control information from their parent object. For example, suppose that the administrator for a server creates a file share with one folder, Public$. The administrator creates this folder so that users can have a place to store information that they want to share. With this purpose in mind, the administrator sets the permissions, which are implemented as ACEs, as shown in the following figure.
Permission Entries on Public Folder (Owner: Administrators)
.gif)
None of the permissions that are listed in this figure were acquired through inheritance. This is because the administrator cleared the check box for Inherit from parent the permission entries that apply to child objects. Clearing the check box sets the security descriptor control flag SE_DACL_PROTECTED, which protects a child object’s DACL by blocking inheritance from the parent object’s DACL.
Permissions that are acquired through inheritance are called “inherited” permissions. Permissions that are not inherited, but are instead defined directly on an object, are called “explicit” permissions. One way to tell an explicit permission from an inherited permission is to select an entry in the Permission Entries list and read the text that is displayed after the list. In this figure, the second entry is selected, and the text after the list says This permission is defined directly on this object. In other words, the permission is explicit, not inherited.
The text in this figure also says This permission is inherited by child objects. Permissions on a parent object that apply to child objects are called “inheritable” permissions. To see which of the permissions that are set on a parent object are inheritable, examine the Apply to column of Permission Entries. If Apply to says This object only (or, for folder objects, This folder only), the permission is not inherited by child objects. Of the four permissions that are shown in this figure, three are inheritable and one is not.
To see how inheritable permissions become inherited permissions, suppose that Alice creates a subfolder in Public$. Alice is an engineer, so she names her folder Engineering Data. Because this new object is a child of Public$, its DACL inherits permissions from the DACL on Public$. The new object’s permissions are shown in the following figure.
Permission Entries on Engineering Data Folder (Owner: Alice)
.gif)
Note that Alice has not cleared the check box for Inherit from parent the permission entries that apply to child objects, so inheritable permissions in the parent object’s DACL are inherited by the child object’s DACL. Inherited permissions are indicated in Permission Entries by a disabled (unavailable) symbol at the beginning of each entry. The permission is still effective; all that is disabled is the ability to modify the entry. Because inherited permissions are defined on a parent object, they can be changed only by modifying the parent object’s DACL.
Even though inherited permissions cannot be changed, the owner of a child object can add explicit permissions to the object’s DACL. For example, suppose Alice decides that inherited permissions that are given to Creator Owner are too restrictive because they allow only the user who creates a file to make changes to the file. She wants all members of the Engineering group to be able to edit and add information to the Engineering Data folder, so she explicitly gives this group Modify permission for all objects in the folder. Alice also feels that people in her company’s marketing department will misuse information in Engineering Data, so she decides to explicitly deny the Marketing group full control of (and therefore all access to) the folder, subfolders, and files. The results of Alice’s changes to the access control settings are shown in the following figure.
Modified Permission Entries on Engineering Data Folder
.gif)
The list of permission entries in this figure now includes two explicit permissions, both with enabled symbols indicating that the entries can be edited. Note that explicit permissions appear at the top of the list. Permissions are listed in the order in which they will be processed during an access check. Because explicit permissions are listed before inherited permissions, they are processed first. The assumption is that the owner of a child object adds explicit permissions in order to qualify inherited permissions. For example, in this figure, an inherited permission allows Everyone to read the folder, subfolders, and files. Alice has added an explicit permission that denies all access to a subset of the group Everyone — the Marketing group. The explicit deny entry is placed before any inherited entries; therefore, it is processed before any inherited entries. For more information about ACE order, see “Order of ACEs in a DACL” later in this section.
Alice applied both of her explicit permissions to This folder, subfolders, and files because she wants child objects in her folder to inherit the new permissions. If the Engineering Data folder were on a server running Windows NT, the new explicit permissions would affect only new objects created in her folder, because the access control model used in Windows NT supports inheritance only at the time that an object is created. To change permissions on existing objects in a Windows NT system, Alice would need to take the additional step of setting explicit permissions on each existing subfolder and file. What is new in Windows 2000 and later is inheritance after the time of creation. New or changed inheritable permissions in the DACL on a parent object are automatically propagated to existing child objects every time the DACL on the parent object changes. If Alice’s folder were on a system running Windows 2000 or later, the entry denying Marketing permission to access the Engineering Data folder would be propagated to subfolders as soon as Alice clicked Apply in the Advanced Security Settings dialog box.
Automatic propagation of inheritable permissions is a powerful capability because you can use it to change permissions on an entire tree of objects by changing permissions on the top-level object in the tree. For example, suppose a member of the Administrators group realizes that information in the Public$ folder and its subfolders is proprietary, not public. In that case, it is inappropriate to allow Everyone access because that group includes the Guest account. The administrator decides that it is more prudent to allow access only to Authenticated Users, a group that includes only users whose identities can be authenticated by the server or by a trusted security authority. To tighten security on the folder, the administrator simply needs to change Everyone to Authenticated Users for two entries in the permissions list. The change is shown in the following figure.
Modified Permission Entries on Public Folder
.gif)
When the administrator applies the changes to the access control settings on the parent object, all inheritable permissions in the parent object’s DACL are propagated to DACLs on subfolders and files. The impact on the Engineering Data folder is shown in the following figure.
Permission Entries Propagated to Engineering Data Folder
.gif)
Note that propagation of inheritable permissions from the Public$ folder to the Engineering Data folder does not change explicit permissions in the child’s DACL. Only inherited permissions are replaced when inheritable permissions are propagated to existing child objects. However, if explicit permissions are also inheritable, the propagation process reapplies them as it moves down the tree. For example, both explicit permissions that Alice added to the DACL on her folder are inheritable by child objects in the folder. As the propagation process moves downward from Alice’s folder, it picks up these additional inheritable permissions and applies them to the DACL of any child object that it finds.
The owner of a parent object can choose to overwrite explicit permissions that are defined on child objects. This is done by selecting the Replace permission entries on all child objects with entries shown here that apply to child objects check box in the Advanced Security Settings dialog box. When the owner of a parent object chooses this option, the propagation process removes explicit permissions from the DACLs on all child objects. It also sets the option Inherit from parent the permission entries that apply to child objects on all child objects, removing any protection from inheritance that might have been set by the objects’ owners.