Because AD lets you apply permissions to a specific type of object in a container, you can delegate limited permissions over a broad area. For example, you might want to delegate to a group of users the ability to manage the replication schedules of all the sites in your enterprise. To do so, you can create a group called Site Replication Schedulers. Right-click the Sites container in the Active Directory Sites and Services snap-in, select Properties from the pop-up menu, and click the Security tab. Click the Advanced tab, click Add, type Site Replication Schedulers, and choose Site Settings Objects in the Apply under field. Click the Properties tab and select the Allow check box for Read schedule and Write schedule as Figure 6, page 30, shows. These two rights give this group the ability to manage the site-replication schedules throughout your enterprise.
Blazing Your Own Trail
The sidebar "Learning More About AD Delegation," page 30, offers resources that discuss AD delegation in more detail, but the topic is still largely unexplored territory. However, don't let the fact that you're nearly on your own hinder you. I recommend that you use the following techniques when you head off the beaten path:
Document, document, document. AD is so complex and broad that you could easily lose control of your delegation model. Also, when you find just the right combination of permissions for a specific team, you'll want to reproduce those permissions in other OUs. Many Microsoft and third-party tools can help you administer and document your AD delegation model (see "Tools for Managing AD Delegation"), but the most important and the easiest to use is pencil and paper—or the computer equivalent, a spreadsheet.
Use nonproduction machines for testing. Testing the exact combination of permissions required to perform a given task can adversely affect your production network, especially if the permissions are in the configuration or schema naming context. To test your scenarios, set up a few machines in a separate forest.
Use domain local groups to assign permissions. Assigning permissions to individual users might seem straightforward, but consistently and accurately replicating a set of permissions can be difficult. When you assign permissions to a specific group, giving identical authority to someone else is as easy as adding that person to the group.
Use the Runas command to verify permissions. The exact set of permissions required to perform a given task might not be obvious at first, so you need to experiment before you deploy delegation scenarios beyond those I discuss in this article. The Runas command lets you run a program under a different user context. I like to open one MMC console under the Enterprise Admins context, in which I can modify permissions, and run another MMC console in the context of the test account to which I'm granting access. This approach is much quicker than logging on and logging off as the other user. I simply use Alt+Tab to switch between modifying permissions and seeing the effect of the modifications on the test account's administrative capabilities.
You'll find exploring the possibilities that AD delegation offers to your organization an adventure. With the information and tools I've given you, you're well on your way to delegating limited authority to other administrators without compromising the security of your enterprise.