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 the same
forest, 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 forest structure.
Figure 1. Explicit trust between two domain trees.
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, even though 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.
Figure 2. Shortcut trust between two subdomains in a forest.
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.
Determining Domain Usage Versus OU Usage
As previously mentioned, some administrators
try to apply 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 OUs 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 when an administrator feels fit to make
structural changes, within certain constraints (namely after mapping
out any group policies and administrative permissions that have been
applied to the OU structure). This gives AD DS the added advantage of
being forgiving for OU design flaws because changes can be made at any
time.
Choosing Between OUs and Groups
Whereas OUs are primarily used to segregate
administrative function, groups are useful for logical organization of
security functions. Translated, OUs are created if there is a need for
a department or physical location to have some certain type of
administrative control over its own environment. For example, an
organization with offices in Japan could organize its Japanese users
into a separate OU and give a local administrator password-change and
account-creation privileges for that OU. Groups, however, can be used
to organize users to more easily apply security permissions. For
example, you can create a group named Japanese Office Users that
contains all the users from the office in Japan. Security permissions
can then be established on objects in AD DS using that group. They
could, for example, be given privileges to folders in the main
corporate location, something that could not be done at the OU level.
To summarize, the basic differences
between OUs and groups is that groups can be used when applying
security to objects, whereas OUs exist when certain administrative
functionality needs to be delegated.
