Beyond the Active Directory Delegation of Control Wizard

A real-world approach to delegating rights in a large domain

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.

You'll notice that Microsoft hasn't provided the ACL editor with a horizontal scrolling bar, so you can't see an entire username if it's longer than the width of the box. To work around this limitation, you need to click Advanced to access the Access Control Settings window. In this window, you can enlarge the username field so that you can display longer names. You'll also discover that the ACL editor's default settings won't let you assign permissions on more than one object at a time. Therefore, you can't assign permissions to an organizational unit (OU) folder structure and propagate the permissions to all subfolders. Figure 1 shows a standard permissions set that lets you assign basic permissions to only the current object—not to subordinate objects. If you need to assign a wider range of permissions to a folder structure, you must click Advanced, then select View, Edit to access the Apply onto drop-down list. As Figure 2 shows, you must select This object and all child objects.

The ACL editor contains another anomaly: When you use the window in Figure 2 to remove a permission from a user who has Full Control (e.g., clear the Allow check box next to Delete User Objects), the system creates a horde of single-permission entries for the user and displays them in the Permission Entries list. Even two such special permissions assignments will fill up the Permission Entries list so that you can no longer find a specific permission assignment. The ACL editor's poor design has had a direct impact on our efforts to manage permissions in our growing OU structure. Because of this problem and other anomalies, we avoid complicated security editing of AD ACLs unless absolutely necessary.

OU Folder Structure
To work around the ACL editor, and to ease the process of delegating control to our division's administrative units (i.e., the local managers who formerly administered NT 4.0 domains), we created a top-level OU folder structure for each of our three administrative units, as Figure 3 shows. Notice that each OU folder includes a standard set of OUs to help administrators manage their objects (e.g., Computers, Groups, Users). For the top-level OUs, we decided not to use typical naming conventions but rather to use numbers so that the OU names aren't tied to the names of locations or departments. Using numbers also helps us identify objects in the domain because we include the administrative-unit number as a prefix in our names for every group, service account, share, computer, and printer object.

Management of all Group Pol-icy Objects (GPOs), administrative groups, and accounts takes place within the DCSP OU folder structure (Administrative Unit Central). We assigned the local IT departments (Administrative Unit 1, Administrative Unit 2) Full Control over their respective folders, in-cluding all subfolders. This permissions assignment gives every administrative group the necessary rights to create, manage, and delete any type of object within its OU folder structure. Assigning single permissions (rather than Full Control) to a structure as large as ours—even with the help of some proprietary tools—simply isn't an effective solution.

Group Policies
Why did we create a special folder for GPOs? Because GPOs introduced a new set of problems that affected our OU structure. By default, Win2K stores GPOs in AD—in domain-naming context at LDAP:// cn=Policies,cn=System,dc=domain (e.g., LDAP://cn=Policies,cn=System,dc=mycorp,dc=com for the Group Policy container in the mycorp.com domain)—and stores Group Policy files in the%systemroot%sysvoldomainpolicies folder (e.g., C:winntsysvoldomainpolicies). GPOs aren't attached to OUs but rather reside in the file system and link to OUs. Remember that Win2K automatically replicates the sysvol folder to every DC in a domain. Creating a large number of GPOs has a strong performance impact on every DC that resides in the same domain. A large number of GPOs will not only affect user logon time but will also increase the amount of replicated data. When you make changes to a GPO, the File Replication Service (FRS) replicates the entire file—not just the changes—to every DC in the domain.

Another problem that we identified involves GPO removal. If you delete a GPO link without deleting the GPO, the GPO remains in the sysvol folder—and the FRS replicates it to every new DC. (You can see unlinked GPOs only on the All tab of the Add a Group Policy Object Link window.) If you don't check this list once in a while and clean it out, you can end up with hundreds of unused GPOs. At Siemens PG, we manage GPOs centrally, checking periodically for unused GPOs. You can also obtain a third-party product such as United Business Machines' (UBM's) Full Armor to manage your GPOs.

To prevent this unused-GPO clutter, we decided to deny local administrators the right to create GPOs (e.g., assigning specific desktop settings to users) unless they have an adequate reason to do so. We limited group membership of the Group Policy Creator Owners group to our DCSP administrators, who approve, create, manage, and delete GPOs within the GroupPolicies folder that you see in Figure 3. From this folder, local administrators can add a Group Policy link to an OU folder. DCSP administrators manage GPOs from the GroupPolicies folder's Properties dialog box, which shows every GPO available in the domain.

Single-DC Permissions
The domain's DCs presented another problem. We wanted to give local administrators rights to perform some maintenance tasks on the DCs in their group, but we didn't want to give them the same rights or access to DCs in other groups. Sensitive data varies according to location, and because we wanted to establish one domain for everybody, we needed to ensure that administrators couldn't interfere with one another. Our solution was to restrict access to DCs. Unfortunately, the permissions you grant using the Default Domain Controller Policy apply to every DC.

Therefore, we decided to create—under the Domain Controllers folder that Figure 3 shows—an OU folder for each administrative group, then move the respective DCs out of the Domain Controllers OU and into the AU1 and AU2 sub-OUs. From these subfolders, we could link certain GPOs to certain sub-OUs. Now we could assign specific user rights to only the DCs in a certain administrative group. We gave administrators the rights to

Other tasks, such as modifying system files or installing services on DCs, are prohibited for local administrators.

Remember that some groups or accounts must retain certain user rights (e.g., a backup service account must have the right to restore files and file folders) and others have inherited rights from a different GPO level (e.g., the domain level). You must manually add such accounts to your defined Group Policies. Table 2 shows a listing of default user rights on DCs. Remember to keep track of all your modifications. Some services (e.g., Microsoft Exchange Server) also require user rights on DCs.

DNS Server
In our AD environment, we wanted all computers to register dynamically; therefore, we decided to use AD-integrated DNS to automatically replicate all entries to every DC. AD matches DNS zones to AD domains, so our single large AD domain has one DNS zone for all computers. Because AD-integrated DNS is available only on DCs, every DC runs the DNS service so that local name resolution is available at every business location. The benefit of AD-integrated DNS is less maintenance effort for DNS replication.

We conducted several performance tests to determine whether AD-integrated DNS would be fast enough to handle as many as 20,000 entries in a single zone. Our results showed that such a load was feasible and that response times would remain fast.

However, a problem arose: How would local administrators handle static clients (such as UNIX servers or Web servers) that aren't running Win2K or that can't use dynamic DNS registration? The administrators would need to manually add these machines to the DNS zone, but the right that would let them do this would also let them accidentally delete an entry. You might think that the obvious solution is to give the administrators the Create All Child Objects permission in the MMC DNS snap-in. You would be incorrect. The DNS snap-in uses the DnsAdmins group as a built-in group; therefore, you must be a member of the DnsAdmins group to be able to open and use the DNS snap-in. If you try to grant a user who isn't a member of the DnsAdmins group access to the DNS snap-in, you'll fail.

We tried to restrict the DnsAdmins group to Read access to the DNS zone information and use other groups (e.g., Domain Admins) to handle Write access. Unfortunately, because the DNS snap-in uses DnsAdmins as a built-in group (i.e., with its unique built-in SID), members of the DnsAdmins group automatically get Full Control permissions on every DNS server's properties sheet. A member of the DnsAdmins group can change DNS property settings (e.g., set forwarders or enable monitoring) on any DC in the domain that runs DNS. Therefore, we couldn't accomplish this restriction. When we brought this problem to Microsoft's attention, we learned that this lack of management functionality is by design: Giving a user only Read permission to a DNS zone in the DNS snap-in is impossible.

However, because Win2K stores zone information in AD, you can use Lightweight Directory Access Protocol (LDAP) to grant permissions to the container and directly access the zone information. Win2K stores AD-integrated zone information in domain-naming context at LDAP://cn=MicrosoftDNS,cn=System,dc=domain.

We plan to develop an application that lets local administrators manage static client entries. Until then, only members of the DnsAdmins group can add or delete static client entries. Meanwhile, Microsoft expects to release a fix for this DNS delegation problem by the time you read this article. The fix won't be available in Win2K Service Pack 2 (SP2), but you can request it from Microsoft Product Support.

Plan and Test
With these tips and observations in mind, you should be able to more granularly plan permission delegation in your environment. Generally, the more specific the permissions you set in AD, the more difficult management of those permissions will be. Be careful not to drown in permission-delegation details, and be sure to clearly document every permission that you set. Don't lose sight of your larger AD goals.

At Siemens PG, we tried to keep our permissions as simple and straightforward as possible, and yet our environment is still extremely complex and difficult to manage. Our plan is to eventually implement a third-party permissions-management tool, such as FastLane Technologies' FastLane ActiveRoles, which should help us automate and record permissions assignment. Regardless of whether you implement a third-party tool, you must never underestimate the importance of planning and testing any AD permission strategy that you design for your company.