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.
Delegating in AD
To delegate administrative tasks in AD, you manage AD objects' ACLs. Each task has an associated permission. For example, the task of resetting a password has the Reset Password permission, which you can allow or deny (explicitly or by inheritance), just like the Read or Write permissions on a file or folder.
You access an AD object's ACL just as you would access a file's or folder's ACL. First, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, choose the View menu, and select Advanced Features. Now, when you right-click the AD object and choose Properties, you'll see a Security tab, which is the ACL Editor interface.
The ACL Editor interface contains several layers of dialog boxes. The first dialog box displays basic information about the permissions templates assigned to particular security principals (e.g., users, groups, computers). You'll notice minor interface differences between the administrative tools in Windows Server 2003 and Windows 2000 Server. (Figure 1 shows the Windows 2003 interface.) For example, in Windows 2003, inheritance is controlled only in the Advanced Security Settings dialog box, but in Win2K, you can access the inheritance check box in both the Security Settings and Advanced Security Settings dialog boxes. Also, if a security principal has permissions that fall outside the standard permission templates that appear in the dialog box, Win2K alerts you with fine print at the bottom of the dialog box stating that the dialog box doesn't display all existing permissions. That information is easy to miss in Win2K. Windows 2003 adds a permissions template called Special that you're more likely to notice as you scroll through the permissions assigned to an account. Note, however, that Microsoft has placed the Special template at the bottom of the permissions list, so you need to scroll down to see it.
Clicking Advanced on the Security tab takes you to the second dialog box. Again, you'll notice differences between Windows 2003's Advanced Security Settings and Win2K's Access Control Settings dialog boxes. Windows 2003's Advanced Security Settings dialog box, which Figure 2 shows, introduces the Inherited From column, which lets you more easily determine at which point in an OU tree a particular permission was applied. Another welcome addition in Windows 2003 is the Default button, which wipes out the ACL and replaces it with the default ACL that the Schema defined for the object. Finally, the new Effective Permissions tab lets you evaluate the resultant permissions for a specific security principal.
When you add or edit a permission entry in the Permission entries list, the Permission Entry dialog box—the third level in the security dialog box chain—appears. This dialog box, which displays the most granular object and property permissions, hasn't changed significantly from Win2K to Windows 2003.
The Delegation of Control Wizard
Knowing about the ACL Editor dialog boxes is helpful—as is the functionality of the Effective Permissions tab—but I don't recommend that you use these dialog boxes to implement delegation. Because they expose too much granularity, simple mistakes can easily occur and lead to disasters.
The Delegation of Control Wizard masks the complexities of ACL modification. To launch the wizard, you right-click a major container (e.g., site, domain, OU) and choose Delegate Control. Other AD objects (e.g., users, groups) don't provide the Delegate Control option. You might correctly assume that all AD objects have ACLs and therefore support delegation, but modifying ACLs on individual leaf objects in AD isn't a good idea. Such modifications would become unruly and would be difficult to document, analyze, and troubleshoot. I recommend using containers as points of delegation, then letting ACL inheritance modify the ACLs of the objects within those containers. Microsoft encourages this practice by displaying the Delegate Control option on only a few major containers.
By using the Delegate Control option from a container, you're automatically specifying the scope of the delegation. The wizard asks you to specify
- to whom you're trying to grant control. You specify this entity by adding security principals, specifically the administrative group that represents the role. Figure 3 shows the wizard screen in which you add these security principals.
- the type of control the security principals should have. You'll notice that the wizard uses the word task, as Figure 4 shows. You can select from a list of what the wizard categorizes as common tasks, or you can create a custom task. Your definition of common tasks will likely differ from these defaults. But as you'll see in a moment, you can customize the Delegation of Control Wizard to display tasks that are common for you.
So, even the wizard is following best practice—a top-down implementation of Task, Role, Scope. After you specify these three delegation components, the wizard modifies the ACL on the container accordingly.
Customizing Delegation Interfaces
Unfortunately, the Delegation of Control Wizard's limited list of common tasks oversimplifies delegation to the point that the wizard becomes useless for any thoroughly thought-out delegation plan. For example, one common administrative task is unlocking accounts that have been locked by a user who has forgotten his or her password. Another example is password resets. When an administrator resets a user password, best practice is to require the user to change the password at his or her next logon. This task isn't available in Win2K's Delegation of Control Wizard. (However, this task is available in Windows 2003's Delegation of Control Wizard.) Strictly controlling the deletion of objects—especially of users, groups, and computers—is also common, particularly in larger organizations, because the deletion of an object results in the loss of its SID. The wizard's common task provides for the creation, management, and deletion of user objects, but what if you want to divide those tasks?
To customize the tasks that the wizard provides, you can modify the delegwiz.inf file, which resides in the hidden \%windir%\inf folder. The delegwiz.inf file has a simple structure in which each common task is defined by a template that provides the task with a user-friendly name and details the ACL changes that the wizard must make to implement the delegation. Near the top of the delegwiz.inf file is a section labeled DelegationTemplates. The Templates parameter that follows lists the templates in the file. If you add or remove a template, you must add or remove the template name from this list.
Listing 1 shows a template that's part of the standard delegwiz.inf file. The code at callout A in Listing 1 states that the template will apply when you invoke the wizard from a domain, OU, or container object. The code at callout B contains a user-friendly description of the task. The code at callout C indicates that if the task is selected in the Delegation of Control Wizard, the wizard will modify permissions on the scope container and on user objects. A permissions template exists for the scope and for the user objects. The scope permissions template permits the creation and deletion of user objects. The user objects permissions template assigns full control (i.e., GA in Listing 1) to all properties of user objects.
By using the templates that Listing 2 shows, you can implement two of the common tasks that Microsoft missed when it designed the wizard. You'll need to add templatecustom01 and templatecustom02 to the list in the Templates parameter of the DelegationTemplates section. You must modify delegwiz.inf on the computer from which you administer AD. If you want multiple administrators to use a custom delegwiz.inf file, distribute it appropriately. A service pack or OS upgrade could potentially overwrite your file, so be sure to back it up. After you customize your Delegation of Control Wizard, you'll be able to easily delegate control without having to dig into the AD objects's ACLs and risk mistakes.
For more information about the structure of delegwiz.inf, check out the Microsoft article "HOWTO: Customize the Task List in the Delegation Wizard" (http://support.microsoft.com/?kbid=308404). You can find information about specific Lightweight Directory Access Protocol (LDAP) property and object names and permissions specifiers at TechNet and the Microsoft Developer Network (MSDN).
Missing Permissions
One unfortunate characteristic of the ACL Editor in both Windows 2003 and Win2K is that it doesn't show you all available permissions. The reason is that far too many exist. That reason is understandable, but what if you assign a permission but can't see it in the UI? By modifying dssec.dat, a text file in the \system32 folder, you can determine which permissions appear in the ACL Editor. The dssec.dat file is divided into sections, each of which displays a property. A property value of 7 means hide, and a property value of 0 (or no mention of the property at all) means show. Listing 3 shows part of the \[user\] section of a sampledssec.dat file.
In the \[user\] section, the property lockoutTime is set to 7, so it won't appear in the ACL Editor. Changing that property to 0 causes the property to appear, as Figure 5 shows. Windows 2003's dssec.dat file doesn't include lockoutTime under the \[user\] section, so the property does appear in the ACL Editor.
The dssec.dat file also determines which properties appear in the custom tasks portion of the Delegation of Control Wizard. As with delegwiz.inf, you must modify dssec.dat on the machine from which you administer AD. You should back up dssec.dat so that you're safe in the event of a service pack or upgrade overwrite. If you customize delegwiz.inf so that you can easily delegate otherwise unavailable tasks, you should ensure that dssec.dat makes visible the permissions you're setting. For example, if you use the second template in Listing 2 to provide an Unlock locked user accounts task, be sure to set lockoutTime to 0 in dssec.dat.
Eliminate Human Error
By carefully planning your delegation and distributing customized dssec.dat and delegwiz.inf files that provide for the implementation of that model, you create an environment that's more productive and less conducive to human error. If you're going to manually delegate control over AD and your organization's roles group tasks in a way that differs from the way that the Delegation of Control Wizard groups tasks, these techniques can make a world of difference.