Domain
trusts across forests used to require individual, explicitly defined
trusts for each domain. This created an exponential trust relationship,
which was difficult, to say the least, to manage. Windows 2003 took the
trust relationship to a new level of functionality, with transitive
trusts supplying automatic paths “up and down the forest tree.” These
trusts are implicitly easier to understand and troubleshoot, and have
greatly improved the manageability of Windows networks.
Conceptualizing Transitive Trusts
Two-way
transitive trusts are automatically established upon the creation of a
subdomain or with the addition of a domain tree into an AD DS forest.
Transitive trusts are normally two-way, with each domain trusting the
other domain. In other words, users in each domain can access resources
such as printers or servers in the other domain if they are explicitly
given rights in those domains. Bear in mind that just because two
domains have a trust relationship does not mean that users from one
domain can automatically access all the resources in the other domain;
it is simply the first step in accessing those resources. The proper
permissions still need to be applied.
Understanding Explicit Trusts
Explicit trusts are those
that are set up manually, similar to the way that Windows NT trusts were
constructed. A trust can be set up to join two unrelated domain trees
into a shared security framework, for example. Explicit trusts are
one-way, but two explicit trusts can be established to create a two-way
trust. In Figure 1,
an explicit trust has been established between the companyabc domain
and the companyxyz domain to join them into the same structure. Explicit
trusts to down-level (pre-Windows 2003 Functional mode) forests are
required as cross-forest transitive trusts are not available until the
forest is in Windows Server 2003, Windows Server 2008, or Windows Server
2008 R2 Functional modes.
When an explicit trust is
set up to expedite the flow of trusts from one subdomain to another, it
is known as a shortcut trust. Shortcut trusts simply allow
authentication verifications to be processed faster, as opposed to
having to move up and down a domain tree. In Figure 2,
while a transitive trust exists between the asia.companyabc.com and the
europe.companyabc.com domains, a shortcut trust has been created to
minimize authentication time for access between the two subdomains of
this organization.
Another possible use
for explicit trusts is to allow connectivity between an AD DS forest and
an external domain. These types of explicitly defined trusts are known
as external trusts, and they allow different forests to share
information without actually merging schema information or global
catalogs.
Defining Organizational Units
As
defined in the RFC for the LDAP standard, organizational units (OUs)
are containers that logically store directory information and provide a
method of addressing AD DS through LDAP. In AD DS, OUs are the primary
method for organizing user, computer, and other object information into a
more easily understandable layout. As shown in Figure 3,
the organization has a root organizational unit where three nested
organizational units (marketing, IT, and research) have been placed.
This nesting enables the organization to distribute users across
multiple containers for easier viewing and administration of network
resources.
As you can see, OUs can be
further subdivided into resource OUs for easy organization and
delegation of administration. Far-flung offices could have their own OUs
for local administration as well. It is important to understand,
however, that an OU should be created typically when the organization
has a specific need to delegate administration to another set of
administrators. If the same person or group of people administer the
entire domain, there is no need to increase the complexity of the
environment by adding OUs. In fact, too many OUs can affect group
policies, logons, and other factors.
Determining Domain Usage Versus OU Usage
As previously mentioned, some
administrators tend to start applying the AD DS domain structure to
political boundaries within the organization. The dry-erase markers come
out and, very soon, well-meaning managers get involved, organizing the
AD DS structure based on political boundaries. Subdomains start to
become multiple layers deep, with each department taking its own
subdomain. The AD DS structure allows for this type of administrative granularity
without division into multiple domains. In fact, the rule of thumb when
designing domains is to start with a single domain and add additional
domains only when necessary. In a nutshell, the type of administrative
control required by many organizations can be realized by division of
groups into separate organizational units rather than into separate
domains.
OUs can, therefore, be
structured to allow for separate departments to have various levels of
administrative control over their own users. For example, a secretary in
the Engineering department can be delegated control of resetting
passwords for users within his own OU. Another advantage of OU use in
these situations is that users can be easily dragged and dropped from
one OU to another. For example, if users are moved from one department
to another, moving them into their new department’s OU is extremely
simple.
It is important to keep in mind
that OU structure can be modified on the fly any time an administrator
feels fit to make structural changes. This gives AD DS the added
advantage of being forgiving for OU design flaws because changes can be
made at any time.
