AD Delegation: Beyond the Basics

AD delegation enhances IT productivity securely

When you use Windows 2000 Active Directory's (AD's) delegation capabilities appropriately, they can greatly enhance your organization's IT productivity and keep your enterprise secure. However, when you implement your delegation model, several key areas can trip you up because the way your administrators need to work doesn't necessarily correspond to the way Microsoft designed AD. As you structure your delegation model, you must translate real-world job functions into specific AD access rights. Although you can designate which tasks different IT staffers need to perform, how to map those tasks to AD permissions isn't always self-evident. I present some techniques that go beyond simple delegation scenarios to address problems you'll probably encounter in your enterprise. These real-world examples can help you design and deploy a secure AD delegation model that meets the needs of your environment.

At first glance, AD's delegation model seems quite simple. Just as you can assign NTFS permissions to give users access to a portion of the file system, you can write access control entries (ACEs) in AD to grant (or deny) users access to a portion of your directory. You can assign rights to certain object types (e.g., computer accounts) and not to others (e.g., group accounts) in the same container. You can also assign rights to an entire object so that, for example, an administrator has full control over an entire user account. But you can also secure each object attribute individually. You could, for example, let administrators change users' phone numbers but not users' passwords. When you understand the rules, designing your delegation model flows naturally. You want to give delegated administrators read and write permissions to those portions of the AD forest that they need to do their jobs—nothing more, nothing less.

First, I discuss delegating Account options rights—in particular, the ability to force password changes—as an AD delegation primer. Second, I address delegating the rights to move objects in and out of organizational units (OUs) to show you how to solve a delegation limitation efficiently and securely. With those discussions as a foundation, I take you through the process of defining a centralized delegation model.

Finally, I move from the domain naming context, in which the delegation tasks discussed up to this point reside, into another AD naming context, the configuration naming context, to explore site-management delegation. (For information about AD's three naming contexts—the domain naming context, the schema naming context, and the configuration naming context—see Darren Mar-Elia, "Planning for Active Directory," September 2000, InstantDoc ID 9643.)

Delegating Account Options Rights
After you launch the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, select a given user, and click the Accounts tab, you'll see the Account options section, which contains a list of 10 options with check boxes. The first 2 options are User must change password at next logon and User cannot change password. A single bitmask attribute called User Account Control controls the remaining 8 options. Although a bitmask is an efficient way to store many items in a small space, which streamlines replication and storage, it presents a delegation problem. Object attributes are the atoms of AD delegation; delegation can't get any more granular than a single attribute. Therefore, the eight properties under the User Account Control attribute are handled on an all-or-nothing basis. If you grant your Help desk staff members the User Account Control right, they can not only enable a user's account but also set the user's password to never expire. Administrators are properly reluctant to let their Help desk staff members exempt user accounts from periodic password changes because nonexpiring passwords present a significant security risk.

Many administrators wrongly assume that the User Account Control right also covers the first two options in the Account options list. The first option—the User must change password at next logon option—is a right that many administrators delegate to their Help desk staff members, usually in conjunction with the right to unlock accounts and change passwords. With these rights, Help desk staff members can help users regain access to their accounts after users have locked themselves out because of a botched password change. Forcing users to change their passwords at next logon ensures that the Help desk staff members no longer know the users' passwords.

I'll walk you through the process of delegating the ability to force password changes (which I haven't been able to find documented elsewhere). This explanation will also serve as an AD delegation primer for those not familiar with the delegation process in general. You usually perform delegation tasks through the Security tab in the Active Directory Users and Computers snap-in (see the sidebar "Tools for Managing AD Delegation," page 26, for a list of Microsoft and third-party delegation management tools). By default, the Security tab is hidden in the snap-in; click View, Advanced features to view the Security tab.

You control the ability to force password changes through an attribute called pwdLastSet. But by default, this attribute isn't exposed through the Security GUI. The dssec.dat file, located in the system32 directory, lists all hidden attributes. To display this attribute, open the file, scroll down to the User section heading, locate the line "pwdLastSet=7," and change the 7 to 0, as Figure 1 shows. The Security GUI displays any attribute with a value other than 7. (While you have dssec.dat open, you might want to change the lockoutTime value from 7 to 0; the lockoutTime attribute, which is also hidden by default, lets you delegate the ability to unlock accounts.) You must either edit dssec.dat on every server and workstation on which you administer delegation or copy the edited file to each machine.

Return to the Active Directory Users and Computers snap-in and right-click the OU containing the user objects that your Help desk will administer. Click the Security tab, then click Advanced, New. The dialog box will ask you to enter or scroll to the user or group account to which you want to grant permissions. Enter the name of your Help desk group and click OK. Click in the Apply onto area and select User objects to view a list of object-level permissions. Click the Properties tab and select the Allow check box for the Read pwdLastSet and Write pwdLastSet attributes, as Figure 2, page 26, shows. (If you don't see these attributes, relaunch the Active Directory Users and Computers snap-in to make them appear.) If you wish, you can also select the Allow check box for Read Lockout Time and Write Lockout Time to grant your Help desk group these rights. Repeat these steps for each OU you want the Help desk to administer.

After you make these changes, when a member of your Help desk group opens a user account in the OU, all the attributes will be shaded out except User must change password at next logon, as Figure 3 shows. If you want to let your Help desk group members disable accounts without delegating the whole User Account Control kit and caboodle to them, check the Allow box for Read accountExpires and Write accountExpires in the same permissions tab instead. Although group members won't be able to directly disable user accounts, they can obtain the same result by setting the account's expiration date to a date earlier than the current date.

Moving Objects to Different OUs
One important administrative right you want to delegate is the right to move objects in and out of OUs. However, delegating this right without compromising security requires some creativity. AD requires that you have delete permissions to move an object out of an OU. Moving an object into an OU requires create permissions. Unless you have those two rights, any attempt to move an object (by right-clicking the object and choosing Move in the Active Directory Users and Computers snap-in) will fail. Because of the way AD is designed, if you have the ability to move objects, you can also delete them—even though, in a practical sense, delete and create operations are distinct from move operations. As an administrator, you might be comfortable letting local administrators move an object—a reversible operation—but not comfortable letting them delete an object—an irreversible operation. Clearly, you have a challenge.

One common delegation scenario is to grant a site-level administrator full control over a specific OU hierarchy. For example, you might have two site-specific OUs in your domain: New York and Detroit. You grant Chip full control over the New York OU and give Maria full control over the Detroit OU. Administrators often need to move individual user accounts and occasionally need to move computer and group accounts to different OUs (e.g., employees relocate or are promoted, IT responsibilities shift). Maria has full control over her OU, so if Jack relocates to New York, she has no problem moving him out of her Detroit OU: As a site-level administrator, she has permission to delete objects in her OU. The problem is, she has no create rights within the New York OU, so she can't move the object to New York. If you have to give Maria create rights over the New York OU (and every other OU to which her Detroit users might relocate), you compromise the security advantages of a geographically limited administration model.

The solution is to create a special OU (I call it the depot OU) for which all your site-level administrators have create and delete permissions. When Jack relocates to New York, Maria moves Jack out of her Detroit OU and into the depot OU. She then tells Chip that he has jurisdiction over Jack's account, which is in the depot OU waiting to be moved. Chip then moves Jack's account from the depot OU to the New York OU.

This solution also eliminates surprise account appearances. No accounts will appear in Chip's OU unless he moved them there. Domain-level administrators can monitor the depot OU to make sure users aren't orphaned there. If necessary, you can create several different depot OUs across your organization. You still have to grant create and delete rights in several places, but much less extensively than you would have to without this solution.

Defining a Centralized Delegation Model
Now that you have the primer information and a sample solution, let's consider how you might define your delegation model. The nature of delegation makes having a well-defined model essential. Consider that Domain Administrators can delegate control over portions of the directory to others without making them administrators over the entire domain. Furthermore, anyone with the Change permissions right to an object can grant or revoke permissions for that object to anyone else he or she specifies. To extend the example from the last section, I might have full confidence in Chip's ability to manage the New York OU (e.g., create and delete objects, maintain group memberships), but I might not want him extending this level of authority to others. I might also want to prevent him from removing any rights I grant to others. But if he has the Change permissions right over his New York OU, he can do both these things. He could let the mailroom clerk delete accounts in the OU, and he could remove the central Help Desk group members' ability to reset passwords within the OU. A poorly thought out approach to delegation administration doesn't provide a secure environment because the heart of good security is a centrally defined and consistently applied security model. However, you can still give OU-level administrators a limited ability to further delegate their authority without wreaking havoc on your centrally determined delegation model.

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.

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.