Permissions

A permission is authorization to perform an operation on a specific object, such as a file. Permissions are granted by owners. If you own an object, you can grant any user or security group permission to do whatever you are authorized to do with it. This includes granting permission to take ownership.

Tip

Although you can give permissions to individual users, it is more efficient to give them to a security group. That way you can grant permission once to the group rather than several times to each individual. Every user added to a security group receives the permissions defined for that group.

When permission to perform an operation is not explicitly granted, it is implicitly denied. For example, if Alice allows the Marketing group, and only the Marketing group, permission to read her file, users who are not members of the Marketing group are implicitly denied access. The operating system will not allow users who are not members of the Marketing group to read the file.

Permissions can also be explicitly denied. For example, Alice might not want Bob to be able to read her file, even though he is a member of the Marketing group. She can exclude Bob by explicitly denying him permission to read the file. In fact, this is exactly how explicit denials are best used—to exclude a subset (such as Bob) from a larger group (such as Marketing) that has been given permission to do something.

Each permission that an object's owner grants to a particular user or group is stored as an ACE in a DACL that is part of the object's security descriptor. In the user interface, ACEs display as Permission Entries in the Access Control Settings dialog box. Figure 12.2 shows the ACEs in the DACL for Alice's file.

Figure 12.2 Permissions for Alice's File

Note

You can set permissions at the file level only if the files are stored on an NTFS volume. On a FAT volume, you can set permissions for shares but not for files and folders within a share. Moreover, share permissions on a FAT volume restrict network access only, not access by users working directly on the computer. There is no good reason to use FAT on a shared volume. It is recommended that you use an NTFS volume.

Setting Permissions on Active Directory Objects

You can set permissions for an object in Active Directory just as you do for an object on an NTFS volume. Right-click the object, then click Properties . When the Properties dialog box displays, click the Security tab.

If you are using Active Directory Users and Computers, the Properties dialog box might not have a Security tab. Viewing the security settings for an object is considered an advanced feature of Active Directory Users and Computers. If the Properties dialog box for the object you have selected does not have a Security tab, click Cancel . In Active Directory Users and Computers, click the View menu, then click Advanced Features .

The Security tab shows only a high-level view of an object's access control settings. For complete information, including information on how permissions set on a container object are inherited by child objects, click Advanced . In the Access Control Settings dialog box, click the Permissions tab. If the object is a container, the Permission Entries list indicates which permissions apply only to the object itself (that is, only to the container), which apply only to child objects (that is, only to objects in the container), and which apply only to certain types of child objects (only to User objects, for example).

This aspect of the user interface reflects an important difference between how permissions are propagated from container objects in NTFS and how they are propagated from container objects in Active Directory. If you own a folder object in an NTFS volume, you can control who has access to the folder and all that it contains by setting a permission on the folder that applies not only to the folder but to all objects in the folder. For example, you can add a permission to the Folder object that allows, say, the Marketing group read access. If you apply the permission to This folder, subfolders and files , it is propagated to all objects contained within the folder. The Marketing group then has read access to the folder and to all its subfolders and files. Propagation of permissions works a bit differently for Active Directory objects. If you own a container object in Active Directory, you have the option to allow access to certain types of objects in the container without allowing access to other types of child objects. For example, if you own an Organizational Unit (OU) object, you can add a permission that allows the Marketing group read access and then apply the permission to a particular type of child object contained by the OU. If you apply it to Contact objects, for example, the permission is propagated only to Contact objects but not to User objects or to any other type of child object. In other words, permissions propagated from container objects in Active Directory can be object-specific , whereas permissions propagated from container objects in an NTFS volume cannot.

Setting Per-Property Permissions

You can manage permissions for objects in Active Directory at two levels:

• At the object level . Permissions allowed or denied at the object level apply to the entire object. For example, you can set an object-level permission on an OU object that allows a particular group, such as Account Operators, to create child objects in the OU.

• At the property level . Permissions allowed or denied at the property level apply only to specific properties. For example, you can set a property-level permission on a User object that allows a particular user, such as Principal Self (that is, the user represented by the object), to change the Home Address property of the User object.

Per-property permissions cannot be managed directly from the Access Control Settings dialog box, but that is a good place to start. To open the Access Control Settings dialog box, select an object in one of the tools used to manage Active Directory, such as Active Directory Users and Computers. Right-click the object, then click Properties . When the Properties dialog box displays, click the Security tab, then click Advanced .

To add new per-property permissions, click Add . When the Permission Entry dialog box displays, click the Properties tab. The list of available per-property permissions is displayed under Permissions .

To view or edit existing per-property permissions, open the Access Control Settings dialog box, click an item in Permission Entries , and then click View/Edit . When the Permission Entry dialog box displays, click the Properties tab. Per-property permissions are listed under Permissions . The per-property permissions allowed and denied to the Authenticated Users group for the user Alice are shown in Figure 12.3.

Figure 12.3 Per-Property Permissions for a User Object

The Properties tab does not list every property of an object, only those that are commonly used for controlling access. The properties of objects in Active Directory and the object types themselves are defined in the schema The number of object types and properties (or attributes ) is quite large. The user interface for access control filters out object types and properties in order to make the list easier to manage.

The list of filtered object types and properties is kept in the file Dssec.dat located in the % systemroot %\System32 folder on every domain controller. You can modify the behavior of the filter by adding or removing items from the list. Dssec.dat is a text file in the following format:

[objectType]

@ = 7

attributeName = 7

Object types are in brackets. If an "@" sign is on the next line below the bracketed object type, and it is set to 7, then the object type is filtered. To stop filtering for that object type, change the setting to 0. The names of filtered attributes are listed below the object type. If an attribute name is set to 7, it is filtered. To stop filtering, change the setting to 0.

When you change Dssec.dat, your changes are not reflected on the Properties tab until you close Active Directory Users and Computers—or whatever other tool you are using—and restart it. Filter data is read when the tool initializes.

For more information on object types and their attributes, see "Active Directory Schema" in this book.

Access Masks

In an ACE, permissions are represented by one or more bits in a 32-bit value called an access mask. When a thread requests access to an object, it specifies the type of access that it desires by using an access mask as well. During an access check, the operating system compares the desired access mask supplied by the thread with the access mask in each ACE of the object's DACL, looking for bits that match. Figure 12.4 illustrates the layout of an access mask.

Figure 12.4 Layout of an Access Mask

Each bit corresponds to an access right—a particular operation or set of operations that can be performed on the object. Turning a bit on in a desired access mask signals that the thread requests the right to perform the corresponding operation. Turning a bit on in the access mask for an ACE signals that the corresponding operation is either allowed or denied, depending on the type of ACE.

Although many of the access rights in an access mask correspond to permissions that can be set through the user interface, not all of them do. Some can be set only by a process, such as the process that creates an object, and cannot be manipulated through the user interface. Windows 2000 uses an access mask format that includes the following types of access rights:

Generic access rights    These rights apply to all objects, but they mean different things for different object types. Each object type maps each generic access right to a different set of standard and object-specific access rights. Table 12.2 lists generic access rights

Table   12.2 Generic Access Rights

Standard access rights    These rights are more specific than generic access rights but still apply to operations available for most object types. Table 12.3 lists standard access rights.

Table   12.3 Standard Access Rights

SACL access right    This right controls the ability to read or change an object's SACL, which controls auditing for the object. The operating system allows access to the SACL only if the subject's access token includes the Manage auditing and security log (SeSecurityPrivilege) privilege.

Object-specific access rights    Each type of securable object defines its own set of access rights. For a list of the specific access rights that apply to each type of object, see the Microsoft Platform Software Development Kit (SDK) link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .

Extended Rights

In Active Directory, you can control which users have the right to perform a particular operation on an object or one of its properties just as you do in the NTFS file system—by setting permissions. However, there are certain operations that have semantics that are not tied to specific properties. These operations might also require access control. For example, you can grant users a Send As right that an email program can use to determine whether a particular user can send mail on another user's behalf. Access controls on custom actions or operations are called extended rights .

Extended rights are not defined by an access mask. Instead, each extended right is identified by a globally unique identifier (GUID). This GUID corresponds to a controlAccessRight object that is stored in the Extended-Rights container within a forest's Configuration container. An ACE that grants an extended right specifies a GUID corresponding to a particular controlAccessRight object.

The list of extended rights is not fixed. Developers can create new extended rights for custom operations by adding controlAccessRights objects to the Extended-Rights container for a forest. For information about creating extended rights, see the Microsoft Platform Software Development Kit (SDK) link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .

You can view the Configuration container and see the extended rights defined for your forest by using ADSI Edit. To see the complete set of extended rights defined for your forest, open ADSI Edit, connect to the Configuration container, and then click the Extended-Rights container. Figure 12.5 shows the Extended-Rights container for one forest.

Figure 12.5 Extended-Rights Container

For more information about using ADSI Edit to view the Configuration container, see "Active Directory Data Storage" in this book.

Although the operating system treats extended rights differently from other access rights, the difference is not apparent in the user interface. They display along with ordinary permissions on the Security tab of an object's Properties dialog box. You allow or deny an extended right just as you allow or deny a permission—by checking the appropriate box.