AD Delegation: Beyond the Basics

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.