Designing Domains for Active Directory Security

After your organization decides whether to require more than one forest, you should design the domain structure for your organization. The forest is the ultimate security boundary in Active Directory. Domains, on the other hand, are limited security boundaries with respect to the autonomy of domain accounts and administration, although the forest root domain is a special case in domain security. As previously mentioned, the forest root domain is central to the forestwide Kerberos trusts and houses the enterprise administrative groups and accounts.

With the exception of the forest root domain, the Domain Admins security group has autonomous authority over all objects in the domain but has only user access outside its own domain. Members of the Domain Admins security group in the forest root domain can manipulate the membership of the Enterprise Admin and Schema Admins security groups and thus can control all objects in the forest. You might have trusted administrators who require domainwide administrative privileges for some part of their duties but not forestwide administrative capabilities. By creating a separate domain, you avoid having to place these administrators into the Domain Admins group of the forest root domain.

All Active Directory service administrators in domains including Domain Admins, Server Operators, and the other built-in domain administrator security groups must be highly trusted because they have the ability to jeopardize forest security via domain controller compromise. If your organization s administrators do not meet this isolation criteria, you must decide on one of the following:

Accepting the risk and using a single forest
Mitigating the risk by not granting administrators who are not as trusted as other administrators membership in Active Directory service administrator groups
Avoiding the risk by creating separate forests

If you build two domains in your forest, each containing resources and accounts, you need to consider that the domain administrators in the forest root domain will also be domain administrators in the other domain. This is because all members of the Administrators group in the root domain have enterprise administration rights. In this situation, which is generally true for multiple domain scenarios, you might consider deploying an empty root forest design. In this design, the forest root is used only to contain the enterprise administrative accounts; all production resources and user accounts reside in child domains. By employing an empty root design, you can preserve the ability to centrally manage the forest and use a single Global Catalog, while enabling autonomy and limited isolation between domains.

Although enterprise administrators can create Group Policy objects (GPOs) at the site level, the domain is also the unit of isolation for domain account policies. This is because domain account policies do not flow from parent domain to child domain and cannot be set in a more granular way than in a domain, such as by an OU. These settings apply to all computer and user accounts in the domain and are not inherited by child domains. Account policies include the following:

Password policy
Determine the password composition and validating rules that must be met, such as password length and complexity requirements
Account lockout policy
Define thresholds for the automatic locking of accounts
Kerberos ticket policy
Determine the lifetime of Kerberos tickets, as well as parameters relating to renewal of existing Kerberos tickets

Account policies are discussed in depth in Chapter 3, Securing User Accounts and Passwords.

The account policy for the domain is configured, by default, in the default domain policy GPO. Although you can configure account policies on GPOs linked to OUs, those settings affect only local computer SAM databases, not domain accounts. If your organization consists of business units that require different account policies, you must create multiple domains.

Because domain administrators can create data administrators by delegating control over all domain resources to other user accounts, including Group Policy, you should limit the number of domain administrators in your organization. The Domain Admins security group is automatically added to the local Administrators security group on all computers that are members of the domain. Because this gives domain administrators full control over all computers in the domain, including servers, domain administrators are also data administrators for all computers, accounts, and information in the domain. If possible, you should apply the same security thresholds for domain administrators as enterprise administrators because these accounts are inherently powerful in a manner similar to enterprise administrative accounts.