لطفا منتظر باشید ...
8.1 Active Directory Domains
One of the first issues you have
to consider when implementing an
Active Directory infrastructure is how many domains you need and what
to name them. Active Directory domain names are DNS domain names,
butand this is importantnot every DNS domain name is an
Active Directory domain name.[1] So while an organization's
Active Directory namespace resembles its DNS namespace, the two
don't have to be identical.
[1] And every square is a
rectangle, but not all rectangles are squares. All registered mail is
certified, but not all certified mail is registered. You get the
idea.
The number of domains you create in your forest is largely dependent
on your administrative and replication requirements. A domain is
mastered by one or more domain controllers, which are servers that
have writeable copies of the data (about users, groups, computers,
etc.) contained in the domain. Unfortunately, Active Directory is not
like DNS, where a single name server can be authoritative for
multiple zones. A domain controller can be authoritative only for a
single Active Directory domain. To create a new Active Directory
domain, you have to install a new domain controlleryour
existing domain controllers cannot be used. However, Active Directory
uses a multimaster replication system, unlike DNS, and consequently
any domain controller can process updates and replicate the changes
to the other domain controllers in the domain.
8.1.1 Domains, Domain Trees, and Forests
Domain trees and forests are
two
important
Active Directory concepts. A domain tree is
simply a collection of one or more domains that share a common
namespace. The fx.movie.edu and
movie.edu domains would be considered part of
the movie.edu domain tree; however, the
example.com domain, if created after
movie.edu, would be in a separate domain tree
called example.com. If the domain you create
does not contain the full name of the parent domain or forest root
domain, it is considered part of a separate domain tree.
A forest is a collection of one or more domain
trees. The domains in the movie.edu domain tree
and the example.com domain tree could be part of
the same forest. A domain tree is based on a common namespace, but a
forest is not.
A forest is named after the first domain created in the forest. If
movie.edu was the first domain we created, the
forest is automatically named movie.edu. We can
then create additional domains for fx.movie.edu
and example.com all belonging to the
movie.edu forest. Another option is to create
the example.com domain in its own forest, which
has certain implications for user access.
All domains within a forest, regardless of which domain tree they are
part of, are trusted by each other from an authentication and
authorization perspective. For this reason, the forest is considered
the primary security boundary in Active
Directory. By making the example.com domain part
of the movie.edu forest, users in
example.com, by default, have read access to
much of the information in the movie.edu
domains, and vice versa. Also, users in
example.com can have control delegated to them
over objects in the movie.edu domains and vice
versa. If example.com is created in a separate
forest, the users in that domain do not have access to the
movie.edu forest, and they cannot have access
delegated to it (unless a special cross-forest trust is created
between the two forests).[2]
[2] Windows Server 2003
supports a new trust type called forest trust, which allows you to
have a single transitive trust that spans two forests. If you want to
understand more about how trusts work, get Active
Directory (O'Reilly).
8.1.2 Domain Models
Two Active Directory domain
models are
commonly used. Your choice of domain model is important because it
dictates DNS requirements, as we discuss later. One model consists of
an empty root domain with geographic or organizational subdomains. We
recommend that you do not create organizational-based subdomains if
you can help it since they are very likely to change at some
point.[3]
[3] Fortunately, a new feature of Windows Server
2003 allows you to rename domains, but the process is arduous. For
more information on renaming domains, see http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx.
Some of the benefits of the multidomain model include the ability to
delegate administration for management of portions of a forest,
greater control over how data is replicated within the forest, and
decreased exposure to problems that can impact a single domain. For
example, if an application went out of control and mistakenly started
creating tons of objects in a domain, at some point the hard disk on
the domain controllers in that domain would fill up. The domain would
then enter an unstable and possibly unusable state. However, the
domain controllers in other domains would continue to function
without much impact. This example is admittedly contrived, but it
shows you the benefits of autonomy in the multidomain model.
The downsides of this model include the increased support costs of
setting up additional domain controllersremember that each
domain must have its own set of domain controllersand
additional domain configuration (configuring security, group policy
objects, organizational units, etc.). Also, finding data in a
multidomain forest is not always easy. Since data can be spread
across several domains, you have to query the global catalog to
perform forestwide searches. The global catalog contains a read-only
copy of the objects in all domains in the forest. The drawback to the
global catalog is that it contains only a subset of the attributes of
objects. If the global catalog doesn't contain the
attribute you want, you have to perform an additional query against
the domain the object resides in after you've
queried the global catalog.
The other common domain model is simply a single domain. Over time,
many organizations have come to recognize the increased support costs
associated with supporting additional domains and have found that
their initial reasons for needing multiple domains may no longer be
valid. With a single domain, you typically need fewer domain
controllers, which results in decreased costs. Also, the global
catalog does not play as big a role because you do not need to search
across multiple domains.
The downside to the single domain model is decreased flexibility in
replicating data. Since all of your objects are in a single domain,
wherever you need to deploy a domain controller, you have to
replicate all of the objects in the domain to it. This type of model
does not lend itself well to branch office deployments where you have
a lot of domain controllers, many of which may have slow WAN
connections.
There are variations to these models, but this should give you the
general idea. A good rule of thumb is the fewer domains the better.
And if you can get by with a single domain, that's
great.
8.1.3 Three Options for the Root Domain Name
Once you've decided on a domain model, you need to
choose a name for your
root domain, also known as the forest
root domain. The root domain name is very important because it
determines which name servers can be authoritative for the
corresponding DNS namespace. You have three basic options for naming
your root domain: use the same name as an existing DNS domain, create
a new subdomain from an existing domain, or use a name that
doesn't correspond to any of your DNS domains (i.e.,
a disjoint or private namespace). Each option has minor advantages
and disadvantages based on your environment, but, as with most naming
convention discussions, the decision is largely subjective.
8.1.3.1 Same name as an existing DNS domain
Consider Movie University. The apex (or top) of Movie
U.'s DNS namespace is
movie.edu, with subdomains named
fx.movie.edu,
classics.movie.edu, and
comedies.movie.edu. This namespace is
represented in Figure 8-1.
Figure 8-1. Movie University's namespace
We could root Active Directory's namespace at the
root of Movie U's DNS namespace. That would result
in movie.edu being the forest root domain. If we
decide that the special effects lab needs a dedicated Active
Directory domain, we can create the fx.movie.edu
domain as a child domain in the movie.edu
forest. Everyone else at Movie U. can be part of the
movie.edu Active Directory domain, even though
individual hosts may fall into different DNS domains. If we did
nothing more, the resource records needed by Active Directory would
be added to the movie.edu and
fx.movie.edu zones.
If your authoritative name servers are not domain controllers and you
want to use AD-integrated zones (more on this later), or you want
some other name servers to be authoritative for the zone that
contains the Active Directory resource records, you have to create
delegations. All of the required Active Directory-specific resource
records are stored in subdomains of the DNS domain whose name
corresponds to the AD domain. These subdomains are named
_msdcs (e.g.,
_msdcs.movie.edu), _tcp,
_udp, _sites, and
DomainDNSZones. The forest root domain will also
have a ForestDNSZones subdomain.[4] To delegate the Active
Directory DNS responsibilities when the Active Directory domains are
named after an existing DNS domain, you need to delegate those
subdomains. In turn, those subdomains become zones on the delegated
servers.
[4] The DomainDNSZones and
ForestDNSZones domains are new in Windows Server
2003. They are used to support application partitions, described
later in this chapter.
8.1.3.2 Subdomain of an existing DNS domain
Now let's say that Movie U. wanted to
completely
separate its AD namespace from its DNS namespace. Another common
approach is to create a subdomain of an existing domain, such as the
top-level domain for the organization. For example, we could name the
forest root domain ad.movie.edu or
corp.movie.edu. If we still needed to create a
subdomain for the special effects lab, it could be named
fx.ad.movie.edu.
This model is the easiest to implement if you want to delegate
responsibility for the Active Directory-critical zones to name
servers other than the main set of authoritative name servers for
your organization. Instead of delegating subdomains as in the
previous model, you need to delegate only the zone with the same name
as the forest root domain (e.g., ad.movie.edu)
from your main forward-mapping zone (e.g.,
movie.edu).
|
8.1.3.3 Disjoint or private name
The last major option for naming your forest root domain is not to
base it on any of your top-level domain names
and
use a disjoint or private name. The most common suffix that is used
in this scenario is .local (e.g.,
movie.local). This model is typically chosen by
organizations that do not want their Active Directory DNS namespace
to be public.
In nonproduction forests, we recommend following the guidelines in
RFC 2606 and using .test or
.example instead of .local,
which are suffixes reserved for testing purposes. If you need to
create a lab or test environment that your general community does not
need to access, this is a good model to use. In fact, you can create
a forest without requiring any delegations at all from your main
forward-mapping zone, assuming you have control over the resolver
configuration for the clients in the lab. To do this, you would need
to create the movie.test forest, enable the DNS
server on one or more domain controllers in the domain, and make the
movie.test zone AD-integrated.
In order for clients to resolve DNS names outside of the forest, you
would need to point the resolvers on the domain controllers to each
other, and configure forwarders to forward unresolved requests to
your organization's main authoritative name servers.
At that point, all you need to do is point the resolvers of the
clients that are going to use the movie.test
forest to one of the domain controllers that are running the
Microsoft DNS Server in movie.test. Now you have
a fully functional Active Directory forest that
didn't require any delegations from your main
forward-mapping zone.
|
