Active Directory Design and Security Concepts - MCTS Guide to Microsoft Windows Server 2008 Active Directory Configuration - page 130

Intrasite replication occurs 15 seconds after a change is made on a domain controller, with
a 3-second delay between each replication partner. The KCC also configures the topology for
intersite replication, but it's different from intrasite replication's topology (discussed later in
“Understanding Sites”).
Trust Relationships In Active Directory, a trust relationship defines whether and how
security principals from one domain can access network resources in another domain. Windows
NT domains must be specifically configured with trust relationships before users in one domain
can access resources in another domain. Starting with Windows 2000 and Active Directory,
trust relationships are established automatically between all domains in the forest. Therefore,
when a user authenticates to one domain, the other domains in the forest accept, or trust, the
authentication.
Although trusts between domains in the same forest are created auto-
matically, there's no automatic trust between domains in separate forests.
Don't confuse trusts with permissions. Permissions are still required to access resources, even
if a trust relationship exists. When there's no trust relationship between domains, however, no
access across domains is possible. Because all domains in a forest have trust relationships with
one another automatically, trusts must be configured only when your Active Directory environ-
ment includes two or more forests or when you want to integrate with other OSs. Trusts are dis-
cussed in more detail later in “Understanding Trusts.”
The Role of Forests
The Active Directory forest is the broadest logical component of the Active Directory structure.
Forests contain domains that can be organized into one or more trees. All domains in a forest
share some common characteristics:
• A single schema —The schema defines Active Directory objects and their attributes and can
be changed by an administrator or an application to best suit the organization's needs. All
domains in a forest share the same schema, so a change to the schema affects objects in all
domains. This shared schema is one reason that large organizations or conglomerates with
diverse business units might want to operate as separate forests. With this structure,
domains in different forests can still share information through trust relationships, but
changes to the schema—perhaps from installing an Active Directory-integrated application,
such as Microsoft Exchange—don't affect the schema of domains in a different forest.
• Forestwide administrative accounts —Each forest has two groups defined with unique rights
to perform operations that can affect the entire forest: Schema Admins and Enterprise
Admins. Members of Schema Admins are the only users who can make changes to the
schema. Members of Enterprise Admins can add or remove domains from the forest and
have administrative access to every domain in the forest. By default, only the Administrator
account for the first domain created in the forest is a member of these two groups.
• Operations masters —As discussed, certain forestwide operations can be performed only by
a domain controller designated as the operations master. Both the schema master and the
domain naming master are forestwide operations masters, meaning only one domain con-
troller in the forest can perform these roles.
• Global catalog —There's only one global catalog per forest, but unlike operations masters,
multiple domain controllers can be designated as global catalog servers. Because the global
catalog contains information about all objects in the forest, it's used to speed searching for
objects across domains in the forest and to allow users to log on to any domain in the
forest.
• Trusts between domains —These trusts allow users to log on to their home domains (where
their accounts are created) and access resources in domains throughout the forest without
having to authenticate to each domain.