Managing Domain and Enterprise Administration

Perhaps the two most important administrative groups in the Windows Server 2003 Active Directory are the Domain and Enterprise Admins groups. Because of their importance, membership in these groups should be very limited. As has been detailed earlier in the chapter, it is very easy to delegate permission to varying degrees of access within the Active Directory structure. By delegating control, you are able to limit the membership of the Domain and Enterprise Admins to only those individuals who are responsible for making changes that affect the entire domain or forest.

This section provides an overview of the management of the domain and enterprise admins groups.

Managing the Domain Admins Group

Members of the Domain Admins group have full control of the domain. By default, this group is a member of the Administrators group on all domain controllers, all domain workstations, and all domain member servers at the time they are joined to the domain. By default, the Administrator account is a member of this group.

Clearly a secure IT infrastructure will have a very limited Domain Admins group for each domain in the forest. This is easily accomplished when setting up a new domain from scratch. You simply identify those individuals (or services) who will have domainwide responsibility, and limit the membership of this group to those individuals. Domain group membership can be enforced via Group Policies, which will be discussed later in this chapter.

If you are upgrading a Windows NT or Windows 2000 domain to Windows Server 2003, it is important to review and validate the Domain Admins group membership before proceeding with the upgrade. One can often find built-in NT 4.0 domain local groups added to the Domain Admins, such as Account Operators. Depending on the membership of Account Operators, the integrity of the Domain Admins group could be compromised after the upgrade.

BEST PRACTICE: Domain Administration Rights

Rather than placing all administrators into the Domain Admin group, because Active Directory has granular security delegation capabilities, it is best practice to limit Domain Admin group membership.

Senior administrators can be placed in the Domain Admin group; however, they should have an administrative account and a separate day-to-day access account. The day-to-day access account should have the same access privileges as all other network users. This will limit the risk of the day-to-day user account being compromised and allowing full access to network resources.

When a situation requires domain admin access, the administrator can log in with his secondary account belonging to the Domain Admin group, perform the task, and log out. As a shortcut to this process, the individual could use the Run As feature of Windows 2000, Windows XP, and Windows Server 2003.

The Run As feature enables a user logged in with a primary user account to run a particular application or command from the security context of a secondary user account. To execute an application using the Run As feature, for example Active Directory Users and Computers, simply do the following:

1. Browse to Active Directory Users and Computers in Administrative Tools.

2. While holding down the Ctrl key, right-click the Active Directory Users and Computers.

3. Choose Run As.

4. In the Run As dialog box shown in Figure 4.6, check The Following User and provide an administrative account and password.

   Figure 4.6. Using Run As to open an administrative application.

   

Managing the Enterprise Admins Group

Members of the Enterprise Admins group have full control of all domains in the forest. By default, this group is a member of the Administrators group on all domain controllers in the forest. By default, the Administrator account is a member of this group. The Enterprise Admins group only appears in the forest root domain.

All of the precautions that apply to the Domain Admins group also apply to the Enterprise Admins group. In a forest that contains multiple domains, members of the Enterprise Admins have administrative control over Active Directory in every domain; hence the membership of this group should be even more limited.

The Schema Is the Most Critical Component of Active Directory

Unauthorized access to the schema master domain controller for a forest can cause serious problems with the potential to corrupt the entire directory. Implementing a peer root domain segregates the keys to schema modification from the user base of the forest.

BEST PRACTICE: Limiting Administrative Access

Limit this group to a single user account, usually the default administrator account. An added layer of security can be accomplished by renaming the administrator account and using a complex password. The new name and password should only be known by those individuals responsible for making forestwide changes to Active Directory. Further, the account should only be used when such changes are warranted.

In addition to the earlier prescribed precautions, you can provide additional security to your Enterprise Admins group through your forest structure by creating a peer-root or placeholder domain. The peer-root and placeholder domain concepts are detailed in Chapter 10 "Advanced Active Directory Design," but essentially what these models provide is a separate domain that is unpopulated save the Enterprise and Schema Admins groups.

By placing these security principles in an empty root, membership of these groups will be protected from any other administrative accounts in the forest. For example, by default the only member of the Schema Admins group is the administrator account. Isolating the Schema Admins group in an otherwise empty root domain preserves and protects the membership of this group from domain level administrators.