Designing Forests for Active Directory Security

The forest is the largest management unit of Active Directory as well as the ultimate unit of autonomy and isolation of authority. Active Directory design begins with answering the question, How many forests will my organization require? The answer to this question is based on security considerations for autonomy and isolation of authority. Characteristics of forests and security considerations that can affect your design include the following:

Enterprise administration boundaries
Default permissions and schema control
Global Catalog boundaries
Domain trust requirements
Domain controller isolation
Protection of the forest root domain

Enterprise Administration Boundaries and Isolation of Authority

The forest is the boundary of enterprise administration. The built-in Administrator account in the forest root domain is the forest owner because this account, along with members of the Enterprise Admins and the forest root Domain Admins security groups, has ultimate authority over all objects in all domains in the forest. Collectively, members of the Enterprise Admins and forest root Domain Admins groups are known as enterprise administrators. Enterprise administrators control the Active Directory objects in the configuration container that do not belong to any one domain, including Enterprise Certification Authority objects and other configuration data that affects all domains in the forest. Needless to say, these accounts have high security requirements.

Because enterprise administrators have authority over all domains in the forest, the domain administrators in each domain must trust the enterprise administrators. You cannot truly restrict enterprise administrators from managing objects in any domain in the forest. Enterprise administrators can always regain control over objects. Some organizations with political challenges, such as those frequently encountered in mergers and acquisitions, might find the scope of this enterprise authority too great and require more than one forest. If your organization requires strict isolation of authority between domains, you will need to deploy multiple forests with manually created trusts between domains in the different forests. These are similar to the structures commonly used in Windows NT domains.

Default Permissions and Schema Control

Each Active Directory forest has one collection of object classes and attributes defined in the Active Directory Schema container and used as templates for objects created in the directory. Object classes in the schema can be instantiated in any domain in the forest. The default permissions on all objects created in the forest are derived from the schema. Thus, alterations or extensions to the schema affect the security of the entire forest, and permissions to make changes to the schema must be restricted. The only user accounts that can make changes to the schema of a forest are members of the Schema Admins security group, which is created by default in the forest root domain and contains only the built-in Administrator account for the forest root domain. Only enterprise administrators (members of the forest root domain Administrators, Domain Admins, and Enterprise Admins groups) can modify membership in the Schema Admins group. If your organization employs multiple groups that require autonomy and isolation of object classes or default security on objects, you will need to create multiple forests.

Global Catalog Boundaries

The Global Catalog contains a read-only listing of all objects and a subset of attributes from every object in every domain in the forest. The Global Catalog is used by applications to locate objects and look up attributes of objects. The Global Catalog also provides a boundary of searchable objects that can be accessed by all security principals in the forest. Therefore, if objects that should not be universally searchable exist, your organization will require multiple forests. Similarly, Microsoft Exchange 2000 Server uses the Global Catalog to populate the global address list (GAL) for internal e-mail recipients, with a single Exchange organization mapping to a single forest. Thus, creating multiple forests impacts your organization s Exchange design as well.

Domain Trust Requirements

In Active Directory, all domains are connected by Kerberos trusts. Kerberos trusts are two-way and transitive in nature. This differs from Windows NT style trusts, which are one-way and intransitive. Each child domain trusts its parent domain, and each tree root trusts the forest root domain. Thus, the forest root domain is the key to transitive trust in the forest. Removal of the Kerberos trusts between domains in the forest will destroy Active Directory functionality. In Windows NT, it was common to create a domain that trusted logons from another domain that itself did not trust logons from the trusted domain in other words, implementing one-way trust relationships was common.

In Active Directory, however, all Kerberos key distribution centers (KDCs) in the forest are trusted equally and implicitly. Therefore, credentials from a compromised KDC and a legitimate KDC are indistinguishable by other KDCs and will be implicitly accepted. If your organization s security requirements dictate that domains must have only one-way trusts with other domains in your organization or isolation of Kerberos KDCs, the domains must be created in separate forests. The only external Kerberos trust relationships that can be created in Windows 2000 are trusts between a Windows 2000 domain and an MIT Kerberos realm. You can create Windows NT style trusts between Active Directory domains in a different forest, but those trusts cannot be used by other domains in either forest. If you require trusts between multiple domains in different Windows 2000 forests, each trust must be created manually between each of the domain pairs.

Domain Controller Isolation

In Active Directory, each domain controller holds replicas of at least three logical partitions in the Active Directory database: the schema container, the configuration container, and the domain naming context for the domain controller s domain. The first two containers are replicated among all domain controllers in the forest, and the latter is replicated among all domain controllers for the same domain. Because all domain controllers replicas of the Active Directory database are writeable and can replicate shared information to domain controllers in other domains, compromise of a single domain controller can affect the entire forest.

For example, it is possible for an attacker who has physical access to any domain controller to view or manipulate data stored anywhere in the forest or on any computer in the forest. That attacker can even make offline changes to forestwide partitions in the directory database, thus compromising the entire implementation. Consequently, physical access to all domain controllers must be restricted to trusted personnel. Similarly, any account with Active Directory service administrator privileges in a domain can potentially hijack a domain controller under its control to compromise the entire forest, either by data manipulation or denial-of-service attack. If your organization requires complete isolation of domains, even from other domain administrators as is commonly seen in large holding corporations or hosting solutions you must deploy multiple forests.

Protection of the Forest Root Domain

Regardless of how many forests your organization implements, you must protect the forest root domain. This is because compromise of this domain could have catastrophic effects on your network. You must protect the two main components of a forest root domain shown below.

Enterprise administrative accounts
Physical security of forest root domain controllers

Enterprise Administrator Accounts

The forest root domain contains the built-in Administrator account for the root, which by default is the only member of the Enterprise Admins, Schema Admins, and Administrators security groups. If an attacker compromises this account or any accounts placed into these groups, the attacker can gain complete control over the entire forest. You can build several safeguards into your Active Directory design to protect these accounts and security groups. The following list describes these safeguards:

Limit the number of enterprise administrators.
Make only the accounts that require enterprise authority members of the Enterprise Admins, Domain Admins, and Schema Admins security groups. In most organizations, this should amount to less than five people. You should use these accounts only when absolutely necessary.
Use Restricted Groups.
You can use Restricted Groups in the Group Policy security settings to limit membership in built-in Administrators, Enterprise Admins, Domain Admins, and Schema Admins security groups. Restricted Groups, by default, are enforced every 5 minutes on each domain controller.
Perform all administration locally.
Restrict the enterprise administrator accounts to logging on interactively to forest root domain controllers. This will prevent enterprise administrator accounts from being attacked on nondomain controllers.
Use smart cards.
For accounts that require enterprise administrator rights or permissions, require the use of smart cards for interactive logon and enable the smart card removal behavior to lock the computer if the smart card is removed from the reader. Before enabling the option to require a smart card for interactive logon, be sure to change the password on the account to a strong password. Ideally, this password should be random and longer than 50 characters to prevent brute force attacks.
Use strong passwords.
For the built-in Administrator account, which cannot be disabled or required to use smart card logon, create a password with a minimum of 15 characters. This will prevent a LAN Manager (LM) password hash from being created. Ideally, use a longer password.
Provide physical security over the forest root domain controllers.
If the physical security of a forest root domain controller is compromised, all accounts in the forest root domain are vulnerable, including enterprise administrative accounts. Remember, even if strong passwords are employed, any password can be broken, given adequate hardware resources and time.

Physical Security of Forest Root Domain Controllers

In a multiple domain forest, the forest cannot function without the presence of the forest root domain. For example, suppose your organization houses all the domain controllers from the forest root domain in a single facility and that facility is destroyed by a natural disaster such as a tornado or hurricane. If the forest root domain cannot be recovered by using backup media, your organization s Active Directory must be completely rebuilt. Similarly, the physical compromise of a domain controller can lead to the exposure of Active Directory account password hashes. The password hashes can then be attacked offline.

As previously discussed, the physical compromise of a domain controller can compromise the entire forest if an attacker exploits a domain controller s ability to write data to other domain controllers in the forest, or if the attacker utilizes implicit and equal trust given to all KDCs by other KDCs to attack other domains. You must design Active Directory with the location and physical security of domain controllers in mind, and you might need to implement multiple forests to isolate sensitive accounts or operations.