Delegating the Administration of Windows Server 2008 Active Directory Domain Services

Active Directory Object Permissions

Every object in Active Directory has an access control list (ACL), which means that you can modify the permissions on that object. This includes objects visible through the Active Directory Users And Computers administrative console as well as objects visible through the Active Directory Sites and Services administrative console, ADSI Edit, or Ldp.exe. The most common tool used to modify Active Directory object access is Active Directory Users And Computers. However, each of the previously mentioned tools can be used to perform the common task of managing object access within the directory service.

Access control permissions on an Active Directory object are separated into two categories: standard permissions and special permissions. Special permissions are granular options that can be applied to an object. A standard permission is made up of a group of special permissions to allow or deny a specific function. For example, the Read standard permission is made up of the Read permissions, List contents, and Read all properties special permission entries.

Standard Permissions

To view the standard permissions for any Active Directory object in the domain directory partition, access the Security page for that object’s Properties sheet in the Active Directory Users And Computers administrative console.

The Security page displays the group or user names that are assigned permissions to the object. As you select a group or user entry, the associated allow or deny permissions for that entry are shown. Figure 9-3 illustrates the permissions for the Domain Admins group on the Sales organizational unit. Notice that, by default, the Allow box is checked for each permission to provide the Domain Admins group full control over the Sales OU.

Depending on the type of object being secured, you will notice that different permissions may be visible on the security page. For example, the following standard permissions are common with all objects:

• Full control

• Read

• Write

• Create all child objects

• Delete all child objects

Some Active Directory objects also have standard permissions that are applied to grouped sets of properties. For example, a user object has several read-and-write property sets such as General Information, Personal Information, Phone And Mail Options, and Web Information. Each of these property sets refers to a set of object attributes, so granting access to a single property set provides access to a set of attributes. For example, the Personal Information property set includes attributes such as homePhone, homePostalAddress, and streetAddress. Using the property sets to assign access to groups of attributes simplifies the process of assigning permissions without having to modify at the granular attribute level.

Special Permissions

One of the entries in the permissions list on the Security page is Special Permissions. In addition to being able to grant standard permissions, you can also grant special permissions to Active Directory objects.

As mentioned previously, special permissions are much more granular and specific than standard permissions. To simplify management, you would typically use standard permissions on an object; however, there may be specific needs that require you to modify the special permission entries.

To get access to special permissions, click Advanced on the Security page and then ensure that the Permissions page is selected. Figure 9-4 shows the interface. Table 9-2 explains the options available on the Permissions page.

Table 9-2 Special Permissions Configuration

Option	Explanation
Type	This value is set to either Allow or Deny. Normally, the interface sorts the permissions so that all Deny permissions are listed first, but the sort order can be changed by clicking any column header. Regardless of the order of appearance in this column, the Deny permissions are always evaluated first.
Name	This is the name of the security principal to which each ACE applies.
Permission	This column lists the level of permission granted for the security principal. Levels of permission can be standard rights, such as Full Control; special permissions such as Create/Delete User Objects; or just Special. The types of permissions available depend on the type of object and how granular the permission entry is.
Inherited From	This column lists the location where this permission is set and if the permission is inherited from a parent container.
Apply To	This column specifies the depth to which this permission applies. It has a variety of settings, including This Object Only, This Object And All Descendant Objects, All Descendant Objects, as well as many others.
Include Inheritable Permissions From This Object’s Parent	This option allows you to specify if parent permission entries are to be applied to the object.
Add/Edit/Remove buttons	These buttons allow you to add new ACEs, remove existing ACEs, or edit a specific ACE to provide more granular permission settings.

In many cases, the same security principals may be listed in multiple ACEs. For example, the Account Operators group has multiple Create/Delete entries for Computer objects, Group objects, User objects, Printer objects, and InetOrgPerson objects in separate ACEs. This happens whenever you specify a combination of permissions that cannot be stored within a single ACE. In this example, each ACE can only contain focus on one type of object (Computer, User, etc.), and cannot be combined into a single ACE.

If you add or edit the permissions granted to a security principal, you are provided two different options for applying permissions. Figure 9-5 shows the first option, which is applying permissions to the object.

The Object tab is used to apply permissions to various object scopes:

• This object only Permissions only apply to the object being secured or modified.

• This object and all descendant objects Permissions will apply to both the object being secured and all child objects within the object.

• All descendant objects Permissions will only apply to child objects within the object being modified.

• Individual descendant objects Windows Server 2008 provides a large selection of individual descendant objects that can be granularly secured. For example, if you are assigning permissions at the OU level, you may choose to only apply permissions to computer objects within the Sales OU. These options provide the capability to delegate permissions at a granular object level.

The second option for applying permissions is to control access to the object properties. Figure 9-6 shows the interface.

The Properties page is used to apply permissions for the security principal listed in the Name field to the individual properties for the object. For example, if you are applying permissions to a user object, you are given the option of assigning Read and Write permissions to each attribute available on the object class, such as general information, group membership, and personal information.

Permissions Inheritance

AD DS uses a static permissions inheritance model. That is, when permissions are changed on a container object in the Active Directory structure, the changes are calculated and applied to the security descriptor for all objects in that container. Consequently, if permissions are changed higher in the Active Directory structure and these permissions are applied to all descendant objects, calculating the new ACL for each object can be a processor-intensive process. However, this initial effort means that the permissions do not need to be recalculated when a user or process tries to access the object.

There are two primary methods that are used to control inheritance of permissions:

• Configuring inheritable permissions on the object By default, when an object is created in Active Directory, inheritable permissions are included from the object’s parent. You can determine if a permission entry is inherited by looking to see whether the check box on the Security page is shaded or not, or by viewing the Inherited From column of the Advanced Security Settings box.

• Configuring the scope of how permissions are applied As described previously, another way to control inheritance is to specify how permissions apply to descendant objects when security is applied to an object. By default, when a new group or user name is manually added to the ACE, the entry has permissions that apply to this object only. To force inheritance to a child object, you need to modify the scope to apply to descendant objects in addition to the current object.

If you have designed your OU structure with the goal of delegated administration, you will have created an OU structure in which top-level administrators that require permissions to all Active Directory objects are granted permissions high in the hierarchy with delegated permissions to all descendant objects. As you move further down the hierarchy, you may be delegating permissions to other administrators who should only have control over a smaller part of the domain. For example, Figure 9-9 shows the Sales OU. Within the Sales OU are two child OUs called Eastern Sales and Western Sales. The manager who is in charge of the entire Sales division may be delegated permissions to the entire Sales OU object and all descendant objects, whereas the Eastern Sales or Western Sales managers may be delegated permissions to their own specific OU only.

In some cases, however, you may want to block higher-level administrators from having any administrative permissions to a specific child OU. For example, if you create a child OU for a branch office in your company, you may assign a local administrative group full control of the OU. However, you may not want those local administrators to have access to any executive user accounts in the OU. To limit their access, you can create an Executives OU within the branch office OU and then remove the option to include inheritable permissions from the object’s parent. This, in effect, blocks permissions inheritance at the Executives OU level.

To block the inheritance of permissions on an Active Directory object, access the Advanced Security Settings dialog box for the object (shown in Figure 9-4). Then clear the Include Inheritable Permissions From This Object’s Parent option. When you clear this option, you are presented with the choice to copy the existing permissions or remove all permissions before explicitly assigning new permissions, as shown in Figure 9-10.

Blocking inheritance has the following implications:

• The permissions are blocked for the object and any descendant objects. This means that you cannot block the permissions inheritance at a container level and then reapply the inheritance from a higher container at a lower level.

• Even if you decide to copy the permissions before modification, permissions inheritance begins where you block the permissions. If you modify the permissions at a higher level, the permissions will not be inherited past the blocked permissions.

• You cannot be selective about which permissions are blocked. When you block permissions, all inherited permissions are blocked. Permissions that have been explicitly assigned to the object or child objects are not blocked.

Effective Permissions

As discussed so far in this chapter, a user can obtain permissions to a specific object in Active Directory in several ways:

• The user account may be granted explicit permissions to an object.

• One or more groups that the user belongs to may be granted explicit permissions to an object.

• The user account or one or more groups that the user belongs to may be given permissions at a container-object level and permissions inherited by lower-level objects.

All of these permissions are cumulative; that is, the user is granted the highest level of permissions from any of these configurations. For example, if a user is explicitly given Read permission to an object, the user belongs to a group that is explicitly given Modify permissions, and the user belongs to a group that is given Full Control at the container level, the user will have Full Control. When a user attempts to access an object, the security subsystem examines all of the ACEs that are attached to the object. All of the ACEs that apply to the security principal (based on user account or group SIDs) are evaluated and the highest level of permission is set. However, in addition to ACEs that grant permissions, Active Directory also supports Deny permissions. Deny permissions can be applied at two levels:

• The user object or one or more of the groups that the user belongs to may be explicitly denied permission to an object.

• The user object or one or more groups that the user belongs to may be denied permissions at a container level, and this denial of permission may be inherited to lower-level objects.

Deny permissions almost always override Allow permissions. For example, if a user is a member of a group that is given Modify permissions to an Active Directory object, and the user is explicitly denied Modify permissions to the object, the user will not be able to modify the object. This is because the ACEs that deny permissions are evaluated before the ACEs that allow permissions. If one of the ACEs denies permission to the security principal, no other ACEs are evaluated for the object.

The one situation in which Allow permissions do override Deny permissions is when the Deny permissions are inherited and the Allow permissions are explicitly assigned. For example, you can deny a user the permission to modify any user accounts in a container. But, if you explicitly allow Modify permissions to an object within the container, the user account will have Modify permissions on that object.

As you can see, configuring security on Active Directory objects can involve managing a large number of interrelated variables. Many companies may start out with a fairly simple security design in which a small group of administrators are given all the permissions in Active Directory. Most of the time, the initial Active Directory security configuration is clearly documented. However, as time goes by, this simple initial configuration often becomes much messier. Sometimes another group of administrators is given a set of permissions for a specific task and for a specific period of time. Granting the permissions is easy to do, but often the permissions are never removed. Often these security modifications made after the initial deployment are also not clearly documented.

For any Active Directory structure that has been deployed for some time, the current security configuration is likely more complex than was initially designed. Sometimes this results in users having more permissions than they should have. Fortunately, Windows Server 2008 provides a tool that can be used to easily determine the effective permissions a security principal has to any object in Active Directory.

To determine the effective permissions that a security principal has on an Active Directory object, access that object’s properties through the appropriate Active Directory administrative tool. Click the Security page, click Advanced, and then click the Effective Permissions page. To determine the effective permissions for a specific user or group account, click Select and then search for the user or group name. After you have selected the name, click OK. The Effective Permissions page displays all of the permissions the security principal has to the Active Directory object. Figure 9-11 shows the interface for the Active Directory Users And Computers administrative tool. Notice that the Effective Permissions page for the Sales OU displays the overall permissions assigned to the Don Hall user object.

Ownership of Active Directory Objects

Every object in Active Directory has an owner. By default, the user who created an object is the owner. The owner of an object has the right to modify permissions on the object, which means that, even if the owner does not have full control of an object, the owner can always modify the permissions on the object. In most cases, the owner of an object is a specific user account rather than a group account. One exception to this is when an object is created by a member of the Domain Admins group; the ownership of the object is then assigned to the Domain Admins group. If the owner of the object is a member of the local Administrators group but not a part of the Domain Admins group, the ownership of the object is assigned to the Administrators group.

To determine the owner of an Active Directory object, access that object’s properties using the appropriate Active Directory administrative tool. Select the Security page, click Advanced, and then select the Owner page. Figure 9-12 shows the interface for the Active Directory Users And Computers administrative tool.

If you have the Modify owner permission to the object, you can use this interface to modify the owner of the object. You can chose either to take ownership for your own account or to assign the ownership to another user or group. This last option is unique in Windows Server 2003 And Windows Server 2008 Active Directory. In Microsoft Windows 2000 Active Directory, you could only take ownership of an object; you could not assign the ownership to another security principal.