IT professionals appreciate the ability to decentralize the burden of administering an enterprise network. By empowering appropriate personnel with the ability to perform administrative tasks, you can reduce total cost of ownership (TCO). Windows networks permit administration decentralization through a variety of features and technologies. If you want to delegate control over Active Directory (AD), for example, you can use the Active Directory Delegation of Control Wizard and ACL Editor. You can also customize the Delegation of Control Wizard to better support the implementation of your plan. Let's take a look at the delegation process in general, then delve into the techniques for customizing the wizard.
Task, Role, Scope
Before you refine your administrative model, you need to take a look at your processes and personnel. Only after analyzing the human and business drivers of your enterprise administration can you turn to the task of implementing your model. A methodology that I've found particularly useful in large organizations that have complex hierarchies—but that also works in smaller organizations—is a top-down approach I call Task, Role, Scope.
Task. In the Task phase, you list each of your business's administrative tasks, regardless of who performs it or how it's performed. To ensure that you cover all aspects of your business, you might want to categorize these tasks. For example, Table 1 lists some common administrative categories and subtasks.
Role. After you list your enterprise's administrative tasks, you can move on to the Role phase. In this phase, you group the identified tasks based on the responsibilities you assign to each level of administration and support. For example, your Help desk role might include the tasks of resetting user passwords, unlocking accounts, and adding users to groups, whereas a higher-level role might include the task of creating users and groups in AD.
Scope. In the Scope phase, you apply roles to particular subsets of your enterprise. For example, your Level 1 Help desk role might include resetting user passwords, unlocking accounts, and adding users to groups. But in a large organization, you probably have Help desks in several regions. In that case, each region becomes a scope of administration. You'll probably discover that your scopes naturally create a hierarchy, in which certain roles have a broad (e.g., national, international) scope but within that scope are roles divided among smaller scopes (e.g., regions, sites). Scope tends to sneak in to other phases of the methodology. For example, your Level 2 support team might be able to create and join computers to the domain—but only for client computers. The Level 3 support team might be responsible for creating and joining servers to the domain. In this case, the distinction between clients and servers becomes a scope.
You can incorporate these three phases into your AD design. Scopes drive the organizational unit (OU) structure of your AD implementation. The first and most important rule of AD OU design is that it should reflect your administrative model—not, for example, your organizational chart. The OUs in your design should reflect the hierarchy that your scopes have naturally created. (For a list of tasks that you'll need to delegate through other means—such as Group Policy settings, ACLs, and group membership—see the sidebar "When Delegation Isn't Technically Delegation.")
Security Groups
After you establish an OU structure that supports scopes of administration, you create security groups for each role. These security groups contain the user accounts of personnel who can perform that particular role. Wherever you've divided roles among scopes, you must also divide your security groups. Suppose your Level 2 support team is national, but your Level 1 Help desk is local. In this case, you would need multiple security groups representing the Level 1 Help desk in each locality.
Often, in an administrative hierarchy, the security group created for a role will include members of security groups created for higher-level roles. For example, the security group for the Level 1 Help desk might include members of the security group for the Level 2 support team so that administrators in the support team can also reset passwords, unlock accounts, and add users to groups.
To implement the tasks you've identified—such as the task of resetting user passwords—you assign a security group (role) the correct permission (task) on the appropriate OU (scope). So, for example, you might grant the West region's Level 1 Help Desk Allow:Reset Password permission to user objects in the West Users OU. If you've carefully analyzed your tasks, roles, and scopes, you should have an OU hierarchy and a hierarchy of nested security groups that minimize the number of ACL changes that you need to make in AD.