Beyond the Active Directory Delegation of Control Wizard

How do you delegate permissions in Windows 2000's Active Directory (AD)? According to Microsoft, you can use AD's delegation and security model to delegate all the rights you need in Win2K. Microsoft's general answer to the question is, "Just use the Active Directory Delegation of Control Wizard." However, my company's experience shows that even though the wizard is valuable for basic procedures such as user creation and group management, it's fairly useless if you want to take a more granular approach to delegating AD permissions.

In her September 2000 article, "The Active Directory Delegation of Control Wizard," Paula Sharick introduces the wizard's functionality. That article is all you need if you're just beginning to delegate control in your Win2K environment. (For more basic information about AD delegation, see "Related Articles in Previous Issues," page 54.) But imagine that your intention is to implement one worldwide domain in a very large AD forest (e.g., a division that contains more than 10,000 users). How do you start?

At Siemens Power Generation (PG), we faced exactly that challenge. At Siemens, each division operates as its own company and has a dispersed IT staff with employees in different locations operating independently. We wanted to create one domain for the division—instead of more than 88 domains with more than 400 trusts around the globe (as the division existed in its Windows NT 4.0 environment). Our intention was to operate the domain independently of Siemens' Active Directory Forest Root Service Provider (FRSP)—the company's primary internal IT department that manages all forestwide configurations, such as schema extensions. However, we recognized early that we would need to establish a similar IT department to be responsible for general domain management and act as a single point of contact for our division's domain. We called this department the Domain Central Service Provider (DCSP). We also wanted to give the division's local administrators adequate permissions to do their job in much the same way that they worked under NT 4.0.

We encountered problems along the way, and we developed solutions with which to work around those problems. In the end, we found that we had obtained a new perspective about AD's permission set—a much deeper perspective than any article or book could possibly provide. If you decide to adapt this article's techniques to your AD implementation, remember to be extremely careful. Some of the tips listed here might produce unpredictable results if you don't first carefully test them. For our implementation, we used the version of AD that accompanied Win2K's initial release.

Independence Day
When you're part of a large forest design, you typically need to relinquish many aspects of your administrative authority in favor of a central companywide service provider that monitors and supports your infrastructure. At Siemens PG, however, we decided not to give the company's FRSP the right to access any of our division's resources (e.g., file shares). We didn't want the FRSP to be able to accidentally modify objects in our domain. To accomplish this separation from the FRSP, we simply removed certain Enterprise Admins group permissions from our domain.

In Win2K, you can revoke Enterprise Admins or Domain Admins rights from ACLs, but those groups retain Take Ownership rights. In other words, although you deny administrative rights to those groups, enterprise administrators can still access your domain and give themselves permissions on an object. You can't change this Win2K feature, but you can establish strict audit policies and carefully monitor the activity within your AD domain to prevent enterprise administrators from making accidental or purposeful modifications. (At Siemens, we grant administrators only as many permissions as necessary to do their jobs.) For more information about removing Enterprise Admins rights from your domain, see the Lucent white paper "Windows 2000 Active Directory Design: Restricting the Enterprise Administrators Group" (http://www.lucent.com/livelink/161922_Whitepaper.pdf).

Limit Domainwide Operations
One of our first steps at Siemens PG was to limit all domainwide operations to the DCSP, denying our local administrators the ability to perform tasks that affect the entire domain. Examples of such tasks are DNS management, site replication, Group Policy implementation, AD recovery, and domain controller (DC) maintenance.

We decided to create a table of permissions, which Table 1, page 58, shows, so that we would have a quick-reference overview of which permissions are open to delegation and how that delegation best occurs. Over the past year, this table has grown rapidly and has been our central resource for designing a permission-delegation model. The table should also be a valuable resource for other environments that want to understand AD permission delegation but want to skip the trial-and-error process that we endured.

The ACL Editor
The Active Directory Delegation of Control Wizard performs only limited functions. You can't use the wizard to define any roles (e.g., Printer Administrator), and you can't revoke or remove any permissions that you use the wizard to set. In addition, the wizard is tightly integrated into Win2K and is therefore impervious to modification efforts.

If you need to step beyond the wizard, you'll need to use the ACL editor to assign permissions. To access the ACL editor, simply go to a specific object's Security tab, which Figure 1 shows. By default, Win2K doesn't display the Security tab on an object's Properties sheet. To enable the Security tab, you need to select Advanced Features from the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in's View menu. Please remember that the ACL editor is a powerful tool that allows much room for error. Always be sure of what you want to modify, and record any changes you make.

   Previous  [1]  2  3  Next