3. Active Directory and DNS
There are some special DNS considerations that need
to be taken into account when planning for AD. You need to understand
these options when building your AD design.
Active Directory domain name
The AD domain name that you choose will also be a
DNS FQDN. This means that this domain name will have a zone on each of
the AD DNS servers. As best practice, if you want to use an Internet
compliant name such as Syngress.com, you will want to purchase this
domain name to ensure that it is not used by someone else. You may also
want to consider using a nonstandard domain name such as Syngress.local.
If you choose to use an Internet standard FQDN for
your domain name, you will need to consider whether you want to use the
same domain name for your internal and external namespace or use a
separate domain name for internal and external namespaces. Using the
same domain name means your Internet presence and your internal AD
domain will share the same FQDN from a DNS perspective. Important
things to note when using this option are:
Public and private DNS namespace is the same.
The
shared single domain name makes access less complicated for users. For
example, they can log on to their computers using their e-mail address
as their username.
Extra precaution must
be made to ensure that no internal resources are accidentally published
to the Internet. This is a major security concern when using this
method.
You will need to maintain both DNS zones (internal and external) separately.
If you choose to use separate domain names for internal and external namespaces, you will want to consider the following points:
The difference between external and internal resources is easy to understand for end users.
DNS is managed separately for each domain.
Users will need to understand that the internal domain is used for internal resources only.
This can provide a greater level of security by not allowing an overlap between your internal and external domain names.
|
Active Directory domain rename
At some point, due to organizational change or
internal business decisions, it may be necessary to change the name of
your AD domain. Microsoft provides a process and tools to rename your
AD domain in the postdeployment
phase. This process is somewhat complex and is not recommended unless
absolutely necessary. The more preferred method to undergo a domain
rename is to create a new AD domain and migrate to the new domain. In
some cases, it may not even be supported to migrate to a new domain,
for example, if Microsoft Exchange server has been deployed in the
domain.
|
4. Planning for domain controllers
As part of your AD deployment, you will need to plan
for DC placement. You will need to know how many DCs to deploy and in
what locations they need to be deployed. You should consider how many
DCs are needed to provide ample redundancy and which physical locations
need DCs installed locally. You may want to consider deploying multiple
DCs in larger offices to prevent authentication traffic over your Wide
Area Network (WAN) in the event that one DC fails.
|
Physical security of Domain Controllers
It is critical that you provide physical security to
DCs. It may be tempting to set up a DC in an empty cube or other
insecure location in remote office locations. This is a bad idea.
Remember, every DC stores the AD database that includes the keys to
your network, including administrator passwords. Make sure you always
keep DCs in secure locations behind a locked door. If there are
physical security concerns in a remote location, you should consider
deploying RODCs which do not store passwords for administrative
accounts locally.
|
5. Planning for Active Directory sites and replication
You will need to consider sites and replication
strategies as part of your AD deployment. AD is a multimaster database, meaning every DC has a local
copy of the database and the ability to make changes to it. To ensure
that all copies of the database remain consistent, AD uses replication
between all DCs. To help ensure reliable and efficient replication
between DCs separated by WAN links, AD uses sites and site links. Sites
also ensure that authentication traffic from computers is sent to a DC
on the local network before attempting to use a DC in a remote
location. In the simplest terms, a site is defined as a network where
servers are connected by a 10 MB or greater link. Sites can be further
defined as subnets assigned to a single physical location. For example,
the New York, Boston, and Nashville locations could be defined as AD
sites. When users authenticate with the network, the authentication
process attempts to use a DC in the same site as the computer the user
is logging into. This prevents authentication traffic from randomly
hitting various DCs across the network which could possibly saturate
your WAN links.
AD uses replication connections between DCs to
replicate changes to the AD database. The Knowledge Consistency Checker
(KCC) will automatically create replication connections between DCs
within a site. This ensures that reliable and efficient replication
takes place between DCs within a subnet. Replication between DCs in a
local site always occurs every 5 min. This is known as intrasite
replication as it occurs between DCs in the same site.
Replication between two separate sites is known as
intersite replication. Intersite replication is set up manually and is
accomplished by creating site links. Each site can have one or more
site links configured to replicate with other sites. When planning your
replication strategy, you should consider using multiple site links
between sites if possible. This allows AD to continue to replicate in
the event of one site failing. Each site link can be set up with an
associated cost. In scenarios where multiple site links are used
between sites, the lower cost-site link is used when available. If the
lower cost-site link fails, then the higher cost-site link will be
used. For example, a site link can be set up between the Boston and New
York offices. A second site link could then be set up between Boston
and Nashville at a higher cost. The Boston DC will use the site link to
the New York office for replication during normal conditions. However,
if the network link between Boston and New York fails, Boston will
replicate to the Nashville site to ensure that replication continues. Figure 4 depicts the aforementioned scenario of a hub-and-spoke replication strategy with a redundant hub site.
