FORESTS, TREES, AND DOMAINS

To this point, we have been discussing the Windows NT family in the context of individual
computers. A group of Windows NT family systems can be aggregated into a logical unit
called a domain. Windows domains can be created arbitrarily simply by promoting one
or several Windows Servers to a domain controller (DC). Domain controllers are secured
storage repositories for shared domain information and also serve as the centralized
authentication authorities for the domain. In essence, a domain sets a distributed
boundary for shared accounts. All systems in the domain share a subset of accounts.
Unlike NT, which specified single-master replication from primary domain controllers
(PDCs) to backup domain controllers (BDCs), Windows 2000 and later domain controllers
are all peers and engage in multi-master replication of the shared domain information.
One of the biggest impacts of the shift to Active Directory in Windows 2000 was that
domains were no longer the logical administrative boundary they once were under NT.
Supra-domain structures, called trees and forests, exist above domains in the hierarchy of
Active Directory. Trees are related mostly to naming conventions and have few security
implications, but forests demarcate the boundary of Windows 2000 and later directory
services and are thus the ultimate boundary of administrative control. Figure 2-4 shows
the structure of a sample Windows Server 2003 forest.
Although were glossing over a great deal of detail about Active Directory, we are
going to stop this discussion here to keep focused on the aspect of domains that are the
primary target for malicious attackers: account information.
Scope: Local, Global, and Universal
Youve probably noticed the continuing references to local accounts and groups versus
global and universal accounts. Under NT, members of local groups had the potential to
access resources within the scope of the local machine, whereas members of global groups
were potentially able to access resources domain-wide. Local groups can contain global
groups, but not vice versa, because local groups have no meaning in the context of a
domain. Thus, a typical strategy would be to add domain users (aggregated in a global
group to ease administrative burden) to a local group to define access control to local
resources. For example, when a computer joins a domain, the Domain Admins global
group is automatically added to the Local Administrators group, allowing any members
of Domain Admins to authenticate to and access all resources on the computer.
Active Directory complicates this somewhat. Table 2-7 lists the scopes relevant to AD.
Depending on the mode of the domain (native versus mixed-modesee References
and Further Reading), these types of groups have different limitations and behaviors.
Trusts
Windows can form interdomain relationships called trusts. Trust relationships only
create the potential for interdomain access; they do not explicitly enable it. A trust
relationship is thus often explained as building a bridge without lifting the tollgate. For
example, a trusting domain may use security principals from the trusted domain to
populate access control lists (ACLs) on resources, but this is only at the discretion of the
administrators of the trusting domain and is not inherently set up.
two-way. A one-way trust means that only one
Trusts can be said to be one-way or
domain trusts the other, not vice versa. Two-way trusts define two domains that trust
each other. A one-way trust is useful for allowing administrators in one domain to
define access control rules within their domain, but not vice versa.
Trusts can also be transitive or nontransitive. In transitive trusts, if Domain A transitively
trusts Domain B and Domain B transitively trusts Domain C, then Domain A transitively
trusts Domain C.
By default, all domains within a (post-NT) Windows forest have transitive, two-way trusts
between each other. Windows can establish one-way, nontransitive trusts to other domains
It can also establish trusts with other
outside of the forest or to legacy NT domains.
forests. (See the upcoming section Forest Trusts.)
Administrative Boundaries: Forest or Domain?
We are frequently asked the question, What is the actual security boundary within a
Windows foresta domain or the forest? The short answer to this question is that
while the domain is the primary administrative boundary, it is no longer the airtight
security boundary that it was under NT, for several reasons.
One reason is the existence of universal groups that may be granted privileges in
any domain within the forest because of the two-way transitive trusts that are
automatically established between every domain within the forest. For example,
consider members of the Enterprise Admins and Schema Admins who are granted
access to certain aspects of child forests by default. These permissions must be manually
removed to prevent members of these groups from performing actions within a given
domain.
You must also be concerned about Domain Admins from all other domains within
the forest. A little-known fact about Active Directory forests, as stated in the Windows
2000 Server Resource Kit Deployment Planning Guide, is that Domain Administrators of
any domain in the forest have the potential to take ownership and modify any
information in the Configuration container of Active Directory. These changes will be
available and replicate to all doma
in controllers in the forest. Therefore, for any domain
that is joined to the forest, you must consider that the Domain Administrator of that
domain is trusted as an equal to any other Domain Administrator. The Deployment
Planning Guide goes on to specify the following scenarios that would necessitate the
creation of more than one forest. The following material is quoted directly from the
Windows 2000 Server Resource Kit Deployment Planning Guide (see the References and
Further Reading section).
If individual organizations:
Do Not Trust Each Others Administrators
A representation of every object in the forest resides in the global catalog. It is possible
for an administrator who has been delegated the ability to create objects to intentionally
or unintentionally create a denial of service condition. You can create this condition
by rapidly creating or deleting objects, thus causing a large amount of replication to the
global catalog. Excessive replication can waste network bandwidth and slow down
global catalog servers as they spend time to process replication.
Cannot Agree on a Forest Change Policy
ins to a forest
Schema changes, con? guration changes, and the addition of new doma
have forest-wide impact. Each of the organizations in a forest must agree on a process
for implementing these changes, and on the membership of the Schema Administrators
and Enterprise Administrators groups. If organizations cannot agree on a common
policy, they cannot share the same forest.
Want to Limit the Scope of a Trust Relationship
Every domain in a forest trusts every other domain in the forest. Every user in the forest
can be included in a group membership or appear on an access control list on any
computer in the forest. If you want to prevent certain users from ever being granted
permissions to certain resources, then those users must reside in a different forest than
the resources. If necessary, you can use explicit trust relationships to allow those users
n speci? c domains.
to be granted access to resources i
If you are unable to yield administrative control of your domain, we suggest that you
maintain separate forests. Of course, you then lose all the benefits of a unified forest
model, such as a shared global catalog and directory object space, and you also add the
overhead of managing an additional forest. This is a good illustration of the trade-off
between convenience and security.