Where Access Control Information Comes From

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:

• The subject

• The object manager

• The parent object

When a subject creates a new object, it can assign the object a security descriptor. 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 operation 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 marked as inheritable to all objects in the container.

Subjects

A subject is a thread executing in the security context provided by an access token. A subject's access token contains information that can be used in security descriptors for new objects that the subject creates and existing objects that the subject modifies. This information includes the following fields:

Owner    This field of an access token contains the SID that identifies the security principal who, by default, becomes the owner of objects that the subject either creates or takes ownership of. Typically, the default owner is the individual user represented by the access token. If the user is a member of the Administrators group, the Default Owner field contains the SID for the group, not the user. If the user is a member of the Domain Admins group, objects that the user creates or takes ownership of in the domain's Active Directory are owned by the Domain Admins group, not by the user. When the SID in the Default Owner field of the subject's access token is copied to the Owner field of an object's security descriptor, SE_OWNER_DEFAULTED is set in the security descriptor's control flags.

Primary Group    This field of an access token contains the SID for the user's primary group. When the SID in the Primary Group field of the subject's access token is copied to the Primary Group field of an object's security descriptor, SE_GROUP_DEFAULTED is set in the security descriptor's control flags.

Default DACL    This field of an access token might contain a DACL, or it might be empty. If the subject's access token contains a DACL, it can be used as the DACL in a new object's security descriptor. If the Default DACL field is used in the security descriptor for a new object, SE_DACL_DEFAULTED is set in the security descriptor's control flags.

Object Managers

The object manager can provide default security information for new objects. Objects of different types have different requirements, thus each type has its own object manager. Table 12.6 lists common object types and the object manager for each type.

Table   12.6 Object Managers for Common Object Types

Active Directory is the only object manager that currently supplies default permissions for new objects. For more information, see "DACLs for Newly Created Active Directory Objects" later in this chapter.

Parent Objects

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 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 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 shown in Figure 12.14.

Figure 12.14 Access Control Settings for Public$ (Owner: Administrators)

None of the permissions shown in Figure 12.14 were acquired through inheritance. This is because the administrator cleared the checkbox for Allow inheritable permissions from parent to propagate to this object . Clearing the checkbox 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 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 displayed after the list. In Figure 12.14, 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 Figure 12.14 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 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 ), then the permission is not inherited by child objects. Of the four permissions shown in Figure 12.14, 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 Folder object is a child of Public$, its DACL inherits permissions from the DACL on Public$. The new object's permissions are shown in Figure 12.15.

Figure 12.16 Access Control Settings for Engineering Data (Owner: Alice)

Note that Alice has not cleared the checkbox for Allow inheritable permissions from parent to propagate to this object , 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 (grayed-out) 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 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 within the folder. And suppose 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 result of Alice's changes to the access control settings is shown in Figure 12.16.

Figure 12.16 Modified Access Control Settings for Engineering Data

The list of permission entries in Figure 12.16 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. Explicit permissions are listed before inherited permissions so that 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 Figure 12.16 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, so it is processed before any inherited entries.

Alice applied both of her explicit permissions to This folder, subfolders, and files because she wants child objects within her folder to inherit the new permissions. If Engineering Data were on a server running Windows NT, the new explicit permissions would affect only new objects created in her folder. The access control model used in Windows NT supports inheritance only at the time an object is created. To change permissions on existing objects, Alice would need to take the additional step of setting explicit permissions on each existing subfolder and file. What is new in Windows 2000 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. In the case of Alice's folder, the entry denying Marketing permission to access Engineering Data is propagated to subfolders as soon as Alice clicks Apply in the Access Control Settings dialog box.

Automatic propagation of inheritable permissions is a powerful capability because it allows you 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 all users who can access the network, even anonymous users and guests. The administrator decides that a more prudent choice is Authenticated Users, a group that includes only users who are authenticated by the server. 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 Figure 12.17.

Figure 12.17 Modified Access Control Settings for Public$

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 Engineering Data is shown in Figure 12.18.

Figure 12.18 New Inherited Permissions for Engineering Data

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 defined on child objects. This is done by selecting the Reset permissions on all child objects and enable propagation of inheritable permissions checkbox in the Access Control 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 Allow inheritable permissions from parent to propagate to this object on all child objects, removing any protection from inheritance that might have been set by the objects' owners.