You begin to develop your delegation model by centrally defining each delegated role (e.g., OU Manager, User Account Manager, Computer Account Manager). You then assign each of these roles a specific set of permissions, which you need to document initially and revise as requirements change. Test these roles in the lab, then deploy them in a pilot phase New York OU, for instance. If your roles work there, they'll work anywhere. See Web Table 1 and Web Table 2 (http://www.winnetmag.com, InstantDoc ID 25640) for worksheets that will guide you through this role-documentation process.
When you create each OU, create a sub-OU called the Admin OU. In the Admin OU, create a domain local group for each of the roles you defined, prefixed with the OU's site code. In our New York Admin OU, for instance, I created groups called NY-OUMgr, NY-UsrMgr, and NY-CompMgr. Figure 4 shows these sample groups and the structure of my hypothetical New York OU. Grant these groups the permissions you defined for that role. For example, the NY-OUMgr domain local group will have Read All Properties, Write All Properties, Create All Child Objects, and Delete All Child Objects permissions over the entire New York OU, as Figure 5 shows. None of those permissions lets anyone in the group modify existing permissions. When I put Chip's account into the NY-OUMgr domain local group, he'll have nearly full control over the objects in that OU and he can give another user any of the defined rights merely by adding the user to the corresponding group. In fact, you could have a domain local group called NY-RoleMgr and enable it merely by giving that group the Read Members and Write Members permissions for group objects over the New York Admin OU. In any case, none of these group members can modify the permissions you laid down centrally.
If you find this approach compelling for your organization, you'll probably want to ensure an even greater level of consistency through automation. Some enterprises build custom scripts that create the OUs and domain local groups and assign the correct permissions automatically. Third-party tools can also help you manage your OUs and permissions. (See the sidebar "Tools for Managing AD Delegation" for more information about such management tools.)
Exploring Site-Management Delegation
So far, our delegation discussion has been limited to the most visible portion of AD, the domain naming context. The domain naming context contains the users, groups, computer accounts, and OUs. However, AD has two other important but less visible naming contexts: the configuration naming context and the schema naming context. As its name implies, the configuration naming context contains information about AD configuration (e.g., site, replication, and routing configuration information). The schema naming context contains descriptive information about AD and lists all the objects the directory can contain (e.g., a user's email address but not shirt size).
You can secure both of these naming contexts, but I'll limit this discussion to the configuration naming context. The configuration context lets you delegate several functions that would usually be reserved for enterprise administrators. The Enterprise Admins group is a universal group that resides in the AD forest's root domain. Members of the Enterprise Admins group have complete authority over the forest, including the ability to add and remove domains and manage trust relationships. Although many administrators argue that they need to be included in this powerful group to perform important infrastructure-related tasks, good security policies limit this group's membership to a small handful of administrators. Nevertheless, you can extend to others rights to perform many of the tasks normally reserved to Enterprise Admins. These tasks include the ability to manage trusts, create child domains, install additional domain controllers (DCs), and authorize DHCP and Microsoft Remote Installation Services (RIS) servers. You assign these abilities through security settings on various parts of the Configuration container. One task that Enterprise Admins typically might want to delegate to others is site management, so let's look at how to do that.
To delegate complete site-management authority, create a group called Enterprise Site Admins. Then, launch the MMC Active Directory Sites and Services snap-in. Right-click the Sites icon in the right-hand pane, and click the Security tab. Click Add, select the Enterprise Site Admins group you created, and give it full control by selecting the Allow check box for Full Control. Anyone you place in this group will have full control over site management.
You can grant full control over just one site by going one level deeper in the snap-in and setting the security on a specific site, although you probably also need to assign rights over the Subnets container (sites are meaningless until they're associated with one or more subnets). Give the group that will control the site both the Read right and the Create All Child Objects right over the Subnets container, then grant the built-in CREATOR/OWNER group full control over the entire Subnets container. Now, all members of the group can create subnets and can control the subnets that they create.
Be aware that with full control over sites, administrators can also create Inter-Site Transport objects. Doing so has a far-reaching effect on your network. Each time a new site transport object is created, the Knowledge Consistency Checker recalculates the replication topology for your entire forest. Site transport objects affect WAN performance over the longer term as well. Thus, Inter-Site Transport objects should be created only by people who thoroughly understand the potential impact. To prevent your Enterprise Site Admins group from creating these objects, give the group Deny permission to the Create Inter-Site Transport Container Objects right.
Register
