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 selected namespace can be as simple as microsoft.com, for example, or he can be more complex. Multiple factors must be considered, however, before this decision can be taken. 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 myriad other possibilities exist.Several advantages with a published namespace are that it is easily accessible from the Internet and there is less of confusion on behalf of the user for the site on the network and the Internet. For example,
a user named Eric Harlan working for the CompanyABC Corporation will be
represented in the network through the user principal name (UPN) as EricH@companyabc.com. This name can be set up to exactly match his 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 distinct, for example, a simple rule could be written to block any traffic with the structure of field internal. Another limitation emerges if an organization currently uses the multiple namespaces to be identified and all these namespaces must be joined in the same forest; in this case, a common design of namespace is not an option. The multiple fusions and acquisitions or even commercial units in the same relative of company 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 user 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 using
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, Windows Server 2008 R2, and finally
Windows Server 2012. Some of these functionality improvements have
changed some of the design concepts associated with Windows Server
2012. 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 Windows Server 2008 R2, but was greatly improved in this
latest version of AD DS included with Windows Server 2012. By adding
this critical functionality, there is less worry that accidental
deletion of user accounts, groups, or even entire organizational units
(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 available only when the
forest functional level is raised to Windows Server 2008 R2 or later
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 2012 (and is becoming much easier to use, as well). 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 available only in Windows
Server 2008, Windows Server 2008 R2, or Windows Server 2012 domain
functional levels.
• Domain rename function—The
capability to rename a domain in a Windows Server 2003/2008/2012 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 designer connectivity worries. In the past, some
administrators balked at the limitations of collaboration within
Windows 2000 Active Directory 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.
• Domain controller virtualization support—Microsoft
has added the capability to create domain controllers (DCs) from
virtual machine templates, greatly improving the time it takes to build
a new DC. At the same time, they have made it possible to have virtual
DCs recovered from snapshots without the worry of corruption or
lingering object issues. All of these virtualization features are new
for AD DS in Windows Server 2012 and change the design options, allowing for much more advanced virtualization design options.
• Server Core and PowerShell enhancements—Windows
Server 2012 is the first version that makes it preferable to deploy an
AD DS DC running on Windows Server Core, because all DC functionality
can now be performed using PowerShell, and Server Core greatly reduces
the security footprint of the DCs.
• Domain controller promotion from media—The
capability to promote remote servers to DCs 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/2012 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 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. With 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.
Figure 1. Domain diagram representation as a 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 simple. 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 2012 AD DS implementation.
Consequently, multiple design models are 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 model
• Peer-root model
• Placeholder domain model
• Special-purpose domain model
In reality, not all AD structures
fall within these categories; possibilities exist for numerous
variations and mutations of AD structure. However, most domain
structures either fit 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.
