Choosing a Domain Namespace
The first step in the actual
design of the AD DS structure is the decision on a common Domain Name
System (DNS) namespace that AD DS will occupy. AD DS revolves around,
and is inseparable from, DNS, and this decision is one of the most
important ones to make. The namespace chosen can be as straightforward
as microsoft.com, for example, or it can be more complex. Multiple
factors must be considered, however, before this decision can be made.
Is it better to register an AD namespace on the Internet and potentially
expose it to intruders, or is it better to choose an unregistered
internal namespace? Is it necessary to tie in multiple namespaces into
the same forest? These and other questions must be answered before the
design process can proceed.
Choosing an External (Published) Namespace
The simplest method of
implementing an AD DS structure is through the use of a single, common
DNS namespace that reflects the company’s name and is registered on the
Internet. Microsoft.com is an obvious example, and a myriad of other
possibilities exist as well. Several advantages to a published namespace
are that it is readily accessible from the Internet
and there is less confusion on the end user’s part in regard to the
location on the network and on the Internet. For example, a user named
Rosemary Nahrvar working for the CompanyABC Corporation will be
represented in the network through the user principal name (UPN) as Rosemary@companyabc.com. This name can be set up to exactly match her email address, limiting confusion for the end user.
The limitations to this type of
namespace strategy are primarily security based. Publishing your AD DS
namespace leaves potential hackers with the name of your domain system
and part of what is needed to compromise user accounts. Administering
your firewall to block internal DNS queries also becomes less intuitive
when the namespace is the same as the published Internet namespace for
the organization. If the namespaces were separate, for example, a simple
rule could be written to block any traffic to the internal domain
structure. Another limitation would arise if an organization currently
employs multiple namespaces to identify itself, and all those namespaces
need to be joined into the same forest; in this case, a common
namespace design is not an option. Mergers and acquisitions or even
multiple business units within the same corporate parent can present
these types of problems.
Choosing an Internal Namespace
If desired or required by your
organization, the namespace that the AD DS structure inhabits can be
internal, or not published to the Internet. Using internal namespaces
adds a layer of complexity to your network because users’ UPNs are
different from their email addresses. However, the increase in security
that is realized from this design is also a factor that leads
organizations to choose this route. Another factor that might influence
your decision to choose an Internet namespace is that you are no longer
limited to the InterNIC standard namespaces of .com, .net, .biz, .info,
and so on. For example, many organizations use the .internal namespace,
or some other namespace that is not used on the Internet.
Keep in mind that it is
important to secure an internal namespace from registration anywhere on
the Internet other than in your own network. In other words, if an
organization registers internalnetwork.net,
and another organization on the Internet registers the same domain name
for its network, there could be naming conflicts with applications and
other systems that perform DNS lookups against your forest. For example,
if an application on a laptop usually attempts to access an internal
namespace but then tries to access it remotely through an Internet
service provider (ISP), the ISP’s DNS will forward you to the registered
DNS name on the Internet. In a nutshell, if you are going to design
your domain with an unpublished namespace but use a standard such as
.net or .org that someone else could theoretically register, it is best
to register and reserve that domain but not point it anywhere. Another
common tactic is to name your domain something that will never be
published, such as a root with your company’s stock ticker symbol (for
example, network.msft), or by utilizing the .internal suffix, which has
been specifically reserved for internal use only.
Examining Domain Design Features
AD
DS has evolved over the years and has added additional functionality
with Windows Server 2003, Windows Server 2003 R2, Windows Server 2008,
and, finally, Windows Server 2008 R2. Some of these functionality
improvements have changed some of the design concepts associated with
Windows Server 2008 R2. These functionality changes are as follows:
Active Directory Recycle Bin—
The ability to do a full-fidelity recovery of deleted objects in AD DS
was introduced in this latest version of AD DS included with Windows
Server 2008 R2. By adding this critical functionality, there is less
worry that accidental deletion of user accounts, groups, or even entire
OUs will cause major havoc, and there is subsequently less reason to
create multiple domains in a forest simply to spread the risk of domain
object deletion. Note that this capability is only available when the
forest functional level is raised to Windows Server 2008 R2 functional
level and when it is subsequently turned on in a domain.
Fine-grained password policies—
The ability to have multiple password policies within a single domain
was originally released in Windows Server 2008 and is still supported
with Windows Server 2008 R2. The addition of this functionality means
that many organizations that previously implemented additional domains
because of the restriction of a single password policy per domain might
be able to collapse those domains. Note that this functionality is only
available in either Windows Server 2008 or Windows Server 2008 R2 domain
functional levels.
Domain rename function—
The capability to rename a domain in a Windows Server 2003/2008 forest
has opened up a new field of possibilities for the design and potential
redesign of AD DS domain structures. Previously, stern caveats were
issued about the inability to rename domains or change the overall
structure of an AD DS forest. With the domain rename functionality
present in AD DS implementation, these limitations are lifted, and
designers can take heart in the fact that design changes can be made
after implementation. Having this ability does not change the fact that
it is still wise to plan out your domain design thoroughly, however. Not
having to make changes to domain names or reposition domains in a
forest is much easier than having to go through the domain rename
process. Just knowing that such functionality exists, however, is a
breath of fresh air for designers.
Cross-forest transitive trusts—
Introduced in Windows Server 2003, the concept of cross-forest
transitive trusts lessens domain designers’ connectivity worries. In the
past, some administrators balked at the limitations of collaboration
within Windows 2000 AD DS structures. The cross-forest transitive trust
capability of AD DS negates those concerns because multiple AD DS
forests can now be joined via cross-forest trusts that are transitive,
rather than explicit, in nature. The combination of these forests is
known in the Microsoft world as federated forests. Note that both
forests must be at Windows Server 2003 or Windows Server 2008 R2 functional levels for this feature to work.
Domain controller promotion from media—
The capability to promote remote servers to domain controllers via a CD
image of the global catalog helps to limit replication traffic and the
time associated with establishing remote domain controllers. Windows
Server 2003/2008 solves the issue of replication over the wide area
network (WAN) by providing you with the ability to save the global
catalog to media (like a CD-ROM), ship it to a remote site, and,
finally, run domain controller promotion (dcpromo) and insert the data
disk with the directory on it for restoration. Only the deltas, or
changes made since media creation, are then replicated, saving time and
bandwidth. The effect of this on domain design creation is reflected in
reduced setup times, less network bandwidth consumption, and increased
flexibility of global catalog domain controller placement.
Choosing a Domain Structure
There is a basic tenet to
consider when designing the AD DS domain structure. Start simple, and
then expand only if expansion is necessary to address a specific need.
This concept is, by and large, the most important concept to remember
when you’re designing AD DS components. In regard to domain design, this
means you should always start the design process with a single domain
and then add on to your design if your organizational concerns dictate
that you do so. Following this basic philosophy during the design
process will reduce headaches down the road.
When you’re designing the AD DS,
you must contemplate a common framework for diagrams. In AD DS, for
example, domains are often pictorially represented by triangles, as
shown in Figure 1. So, when beginning your design, start with a single triangle.
In this example, the
fictional company named CompanyABC has begun the process of domain
design. Depending on its unique needs, CompanyABC might decide to expand
upon that model or keep it simplistic. These decisions should be made
with a detailed knowledge of the different domain design models and the
environments in which they work best.
Active Directory was
designed to be a flexible, forgiving directory services implementation.
This is even more true with Windows Server 2008 R2’s AD DS
implementation. Consequently, there are multiple design models available
to choose from, depending on the individual needs of organizations. The
major design models are as follows:
Single domain model
Multiple domain model
Multiple trees in a single forest model
Federated forests design model
Peer-root model
Placeholder domain model
Special-purpose domain model
In reality, not all AD
structures fall underneath these categories because the possibilities
exist for numerous variations and mutations of AD structure. However,
most domain structures either fall into these categories or are a hybrid
model, possessing traits of two different models. Out of all these
models, however, the single domain model is the most common design model
and also happens to be the easiest to deploy.
