Developing a Strategy for Delegation

Delegation is the process of decentralizing network administration by assigning some of the administrative duties to other individuals or groups in the business. Individuals or groups can be assigned specific administrative privileges to certain objects in the Active Directory structure without having control over all the objects. For example, an administrator from one location can be given control over objects within that location and that location only. This is a welcome change from NT 4.0, in which a user who is given privileges to administer user accounts can administer all user accounts in the domain.

Creating a strategy for delegation determines at which level in the Active Directory structure administrative permissions should be assigned: site, domain, or OU. The level at which the permissions are applied is determined by the scope of the administrative duties. Keep in mind that it is most common to delegate authority at the OU level because it is much easier to manage. If you start delegating authority on specific objects and object attributes, you'll soon find it difficult to track the permissions that have been assigned (remember, your goal is to make administration easier, not more complex).

Before you begin developing a strategy for delegation, be sure you've determined the answers to the following questions:

• Who will be assigned administrative privileges?

• What will she be administering?

• What is the scope of her administrative duties?

This section of the chapter covers the Delegation of Control Wizard, inheritance and inheritance modifications, designing an OU hierarchy for delegation, and design guidelines.

The Delegation of Control Wizard

Anyone who has worked with Windows should be familiar with wizards and what they are used for. Wizards walk you through the process of completing a task, such as adding a printer or creating a user account. The Delegation of Control Wizard serves the same purpose: It walks you through the process of assigning administrative control over an OU or a container. Within the wizard, you'll assign the user or group specific rights to an OU or other container object. Keep in mind that the rights you assign then apply to all objects in the OU or container.

Use the following steps to delegate control using the Delegation of Control Wizard:

1. Open the Active Directory Users and Computers MMC snap-in.

2. Select the OU or container you want to delegate control over.

3. From the Action menu, select Delegate Control.

4. The Delegation of Control Wizard appears, as shown in Figure 5.8.

   Figure 5.8. The Delegation of Control Wizard's welcome screen.

   

5. Click Next , and the dialog box that appears will allow you to select additional users or groups for delegation. The list is always empty when you first start the wizard (see Figure 5.9).

   Figure 5.9. From this dialog box, you can add the users or groups to whom you want to assign administrative permissions.

   

6. Click Next, and the dialog box that appears enables you to select the users or groups that will administer the OU or container (see Figure 5.10).

   Figure 5.10. From this dialog box, you can select the users or groups from the list of domain accounts.

   

7. After you've selected the users or groups, you can then select the tasks to delegate. You have two options: The first option is to select the common tasks from the list presented in Figure 5.11. For example, if a user needs administrative control over passwords, he could be assigned the Reset Passwords on User Accounts Permission option. If the common tasks do not meet your requirements, the second option is to create a custom task to delegate (see Figure 5.12).

   Figure 5.11. Select the tasks you want to delegate. You can either choose from the list of common tasks or choose the second option and create a custom task to delegate.

   

   Figure 5.12. From this dialog box, you can specify the scope of a user's or group's control.

   

8. If you choose to use the common tasks, you then must select from the list the tasks for which the users or groups will be responsible. The next dialog box to appear enables you to summarize who has been given control and the type of permissions they have been assigned. From this box, you can click Finish (see step 11). You should pay attention to the summary just to ensure no errors have been made.

9. If you select Create a Custom Task to Delegate, you're not finished yet; there are a few more steps to complete. The dialog box shown in Figure 5.12 appears; it's where you can specify the scope of the control. Will it apply to all objects in the container and any new objects created? Or is control limited to only specific objects in the container?

10. After the scope of control has been configured, you then are prompted to select the permissions you want to assign to the users or groups (see Figure 5.13).

    Figure 5.13. The permissions that can be delegated to individual users or groups.

    

11. After you've selected the types of permissions you want to assign, the last dialog box shows you a summary of who has been assigned what permissions (see Figure 5.14).

    Figure 5.14. The last dialog box in the Delegation of Control Wizard shows you a summary of who has been assigned what permissions over the container object.

    

Table 5.3 summarizes the three options presented in the permissions window (shown in Figure 5.13).

Table 5.3. Permissions Window Options

Option	Description
General	The general permissions are common permissions that can be assigned to the container object.
Property-Specific	This option enables you to specify the permissions on the attributes associated with the object. For example, one of the attributes associated with an object might be an administrative description. You can assign a user or group permission to Read adminDescription. If the user or group needs to be able to change the administrative description, you can assign Write adminDescription.
Creation/Deletion of Specific Child Objects	Select this option if you want to assign the individual or group the permission to create or delete child objects. After you select this option, you must specify the types of objects that can be created or deleted. For example, if a user needs to be able to create printer objects within the container, he can be assigned the permission to only create this type of object.

Inheritance and Inheritance Modification

Permissions in Active Directory are typically inherited from parent container to child container. This behavior is appropriate in most circumstances. However, sometimes a child object must be managed independently of the parent. In such a case, use inheritance modification to override the default inheritance rules.

Inheritance

Inheritance in Active Directory enables permissions that have been set on a parent container to apply to the child containers within the hierarchy. It is the same idea as folder and file permissions: When you set permissions on a folder, you have the option of specifying whether those permissions should apply to the subfolder and files beneath it. The permissions only have to be set once, thus simplifying the process of administration.

With inheritance, a user or group can be assigned permission to a container and all the objects it contains. Permissions can be set once on a container, as opposed to having to set the permissions on each individual object, and they can save administrators a lot of time and effort.

For example, within the paris .xyz.corp domain shown in Figure 5.15, an OU has been created for the training department (parent object). Child objects have been created within the Training OU for administrative purposes. If a group of users in the Paris domain need administrative privileges over the Training OU and all its child objects, permissions need to be set only once as a result of inheritance.

Figure 5.15. Using inheritance, permissions can be set once on the parent object and applied to the child objects.

To take advantage of inheritance, be sure the Allow Inheritable Permissions from Parent to Propagate to This Object option is selected (this is selected by default).

Inheritance Modification

Conversely, if you do not want permissions to apply to all the child objects within a parent object, you can modify inheritance. Using inheritance modification, you can specify which child objects should inherit permissions and which ones should not.

Using the example in Figure 5.15, if it is determined that the Full Control permission set on the Training OU should not apply to the Clients OU, inheritance modification could be used to block it. Blocking inheritance is as simple as clearing the Allow Inheritable Permissions from Parent to Propagate to This Object check box.

Use the following steps to block inheritance on a child object:

1. Open the Active Directory Users and Computers MMC snap-in.

2. Select the object you want to block inheritance on; then select Properties from the Action menu.

3. Select the Security tab from the object's Property dialog box.

4. To block inheritance, clear the Allow Inheritable Permissions from Parent to Propagate to This Object check box.

After you've cleared this check box, you are prompted to choose whether you want to copy previously inherited permissions to this object or remove inherited permissions and only keep those permissions that have been explicitly set on the object.

Designing an Organizational Unit Hierarchy for Delegation

OUs are created in a domain to logically group objects for administrative purposes. After OUs are created, a user or group can be assigned the task of administering the objects contained within. Creating OUs enables you to limit the scope of administrators' control and provides a finer granularity of control when assigning administrative rights and permissions to other individuals and groups.

The OU structure that is designed should be relative to the way administration is currently dispersed throughout the business; it is also dependent on how the administrative tasks are delegated. Here are some questions to keep in mind:

• Is the delegation of administration based on location, and are there individuals in each geographical location who are responsible for performing administrative tasks?

• Have the administrative tasks been divided into different roles, such as user account administration and printer administration?

• Is the delegation of administrative tasks based on department, and are there individuals or groups in each department who are responsible for performing administrative tasks?

The OU structure that's designed should be based on the current delegation of tasks. For example, if the XYZ Corporation has divided the administrative tasks into different job roles, this should be reflected in the OU structure implemented (see Figure 5.16). This enables the corporation to continue with its current strategy of distributing administrative authority.

Figure 5.16. The OU hierarchy should represent the current strategy for assigning administrative authority.

Because the XYZ Corporation divides the administrative tasks into separate roles, OUs can be created for each of the roles. The individual or group responsible for an administrative role can be assigned delegation of control over the appropriate OU. When you're designing the OU hierarchy, keep in mind that the structure should allow the business to continue to use the same strategy of assigning administrative control that it's currently using.

One of the important features of using OUs is that they can be nested within one another, which becomes a benefit when delegating control. Objects in one OU can be subdivided in child OUs. Referring to the Paris domain in Figure 5.15, a hierarchy of OUs is created by nesting the OUs within one another. You might be asking yourself why you would want to do this, but it makes perfect sense for delegating authority. If an OU is created to hold all user accounts, you might not want to assign one user or group control over all of them. In this case, you can divide the user accounts into child OUs (Clients and Employees), which would be contained in the parent OU (Users). This way, a user or group can be assigned administrative permissions over certain user accounts without having control over all of them.

Nesting is a powerful feature in Windows 2000, but keep in mind that an OU hierarchy that is very deep can soon become difficult to keep track of and manage.

Design Guidelines

When designing Active Directory for delegation, keep the following guidelines in mind:

• Perform a thorough assessment of the business and its internal IT organization so their needs are identified.

• Make sure the model you create allows for flexibility and growth within the business. Growth or reorganization within a business should not have a major impact on the Active Directory structure.

• The OU hierarchy should reflect the structure of the organization.

• When at all possible, delegate authority at the OU level and use inheritance. This makes the tracking of permissions much simpler.

• If an individual needs authority over an OU, assign the appropriate administrative permissions. Avoid putting the individual into the Domain Admins group, though, because this gives her privileges throughout the domain. Assign the most restrictive permission that will allow the user (or group) to perform the required tasks.