Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

A

domain is a container in Active Directory that
defines a logical boundary for objects that share common requirements
for
security, replication, and administration.

Security

A domain is a security

boundary
within which objects (users, groups, computers, printers, and so on)
can be managed. For example, all users in a domain can log on to the
domain using their usernames and passwords. Domains also have their
own security policy, called a domain security policy, that defines
account policies such as password and account lockout settings. See

Group Policy later in this chapter for more
information on domain security policies.

Replication

A new domain is

created
when you install the first domain controller for the domain. Domains
are also units of replication, for all domain controllers in a domain
automatically replicate their Active Directory updates to one
another. See

Domain Controller later in this
chapter for more information.

Administration

Domains share

common
administration, and members of the Domain Admins group have broad
rights and permissions for performing administrative tasks on objects
in the domain. These administrators can also delegate aspects of
domain administration to other trusted users using the Delegation of
Control Wizard. Administrators can add further structure to a domain
by creating a hierarchy of OUs within the domain. Administrators can
delegate authority over OUs to trusted users to allow them to perform
specific administrative tasks on the objects within the OUs. See

Delegation and

OU in this
chapter for more information.

Domains can exist by themselves, or they can be grouped into
multidomain hierarchical structures called trees. A tree consists of
a root domain and one or more child domains joined by trusts to the
root or to each other in hierarchical fashion. Elements of a tree
share a common namespace. A forest consists of one or more trees
joined at the roots by trusts. All domains in a tree or forest
implicitly trust each other using two-way transitive trusts, allowing
users to log on to a client computer anywhere in the enterprise and
access shared resources on any server. For more information, see

Forest and

Trusts later in
this chapter.

Domains aren't the same as sites. Domains are
logical groupings of users, computers, and other Active Directory
objects, while sites are physical divisions between networks
connected by slow WAN links. One domain can span several sites, and
one site can contain several domains. For more information, see

Site later in this chapter.

Domains are named

using DNSfor example,

mtit.com or

sales.mtit.com .
The forest root domain is the first domain you create when you
install Active Directory. When you promote your first domain
controller, the forest root domain is created and is the root of both
your first tree and the entire forest. Domains in a tree must form a
contiguous namespace in Active Directory. For example, if the root
domain of a tree is

mtit.com , then

vancouver.mtit.com and

seattle.mtit.com would be two examples of child
domains of

mtit.com , while

support.vancouver.mtit.com and

sales.vancouver.mtit.com would be two more child
domains whose parent domain is

vancouver.mtit.com .

In W2K, domains could not be renamedactually, there was a hack
in which you could create a new domain with the desired DNS name and
then use the

MoveTree utility from Support Tools
to move all the objects from your old domain to the new one, but this
was tedious and somewhat risky. In WS2003, however, you can rename
domains, reposition domains within a tree, and create new trees using
the

Rendom utility. This operation is still
tedious, but it's no longer risky and can be used to
restructure your forest after mergers and other major changes to your
company.

Domain Functional Level

In W2K, domains could run in one of
two domain modes:

Mixed mode

Allowed downlevel domain
controllers running NT to coexist with
domain controllers running W2K by using NTLM authentication instead
of Kerberos

Native mode

Supported only domain
controllers running W2K by requiring
Kerberos authentication

You could switch W2K domains from mixed mode to native mode but not
the reverse.

In WS2003 things are a little more complicated, for domains can now
run in one of four different domain functional levels:

Windows 2000 mixed (default for new domains)

Supports domain
controllers running WS2003, W2K, and NT.

Windows 2000 native

Supports domain
controllers running WS2003 and W2K.

Windows Server 2003 interim

Supports domain
controllers
running WS2003 and NT. This is a special domain functional level that
exists only when you upgrade an NT-based network directly to WS2003.

Windows Server 2003

Supports only domain
controllers running WS2003.

By default, when you create a new domain, its domain functional level
is Windows 2000 mixed, which gives it the greatest degree of
interoperability with NT/2000 domain controllers. You can raise the
domain functional level for your domain to Windows 2000 native if you
have no more NT domain controllers or to WS2003 if you have no more
W2K domain controllers, but you can't undo this
operation afterward. Each time you raise the domain functional level,
additional features that simplify the administration of your
Windows-based network are supported; these are shown in Table 4-12.

Different domains within a forest can be assigned different domain
functional levels, depending on how far your network migration has
gone. Another type of functional level, called forest functional
level, affects all domains in your forest. For more information, see

Forest later in this chapter.

Planning Domains

When you are planning
an
Active Directory implementation, start by assuming that a single
domain will suffice, create OUs within your domain to add additional
structure mirroring the organization of your company, and then
delegate authority over OUs to suitable users. Plan for additional
domains only if necessary to separate administrative functions more
sharply between business subsidiaries, locations, or departments. For
example, the following security features are domainwide in scope:

Password policy

Account lockout policy

Kerberos policy

EFS recovery policy

IPSec policy

Public key encryption policy

Certificate authorities

What this means is that if two departments in your company absolutely
must have different password policies, then these departments must be
different domains. Before you start creating additional domains, it
might be time to consider harmonizing security policies across your
company.

Here are some reasons to create multiple
domains
or trees in your forest:

• Your company is large enough to consider using the complexity of a
  multidomain implementation of WS2003 Active Directory. There is no
  hard and fast rule for how big a company should be, though; this is
  based essentially on your available IT resources and expertise, as
  well as on the other factors described later.

• Your company requires that IT administration be decentralized across
  multiple locations or divisions. Multiple domains are appropriate
  here because domains represent strong security boundaries for
  administration of users, groups, computers, and other resources.
  Domain Admins in one domain can't administer
  resources in other domains unless they are explicitly given
  permission to do so.

• Your company requires distinct Group Policy security settings (such
  as password and account lockout settings) for different locations or
  divisions. This might even be for legal reasonsfor example, if
  some of your subsidiaries are in foreign countries with different
  legal security requirements.

• Your WAN links are slow, and you want to keep replication traffic
  between different locations to a minimum and to control it more
  tightly. You could make each location both a separate domain in the
  tree and a separate site. This is because the only Active Directory
  information replicated between domains in a tree are the schema, the
  configuration information, and the global catalog. If you use a
  single domain with multiple sites instead, the site links between the
  sites require enough bandwidth to support the greater traffic that
  occurs during intradomain replication of Active Directory.

If you are migrating an existing NT-based enterprise to WS2003, the
migration strategy you use depends on which of the four NT domain
models your company currently employs:

Single-domain model

If you are currently
using the single-domain model in your NT
network, you simply upgrade the existing NT domain to create a root
domain of a new WS2003 forest.

Single-master-domain model

This model consists of
an account domain (the master domain)
that is trusted by one or more resource domains (slave domains). You
first upgrade the account domain to create the root domain of your
new forest, then you upgrade the resource domains to become child
domains of the root domain. This results in a single tree with one or
more first-level child domains. An alternative is to upgrade your
account domain to a root domain, create one top-level OU in the root
domain for each existing resource domain, and then join the member
servers and workstations to the OUs within the root domain,
discarding the domain controllers in the resource domains. This
leaves you with a single domain to manage.

Multiple-master-domain Model

This model consists of
two or more account domains (master
domains), which trust each other, and one or more resource domains
(slave domains), each of which trusts every account domain. A
recommended procedure is first to create a new WS2003 domain as the
root domain of your forest. This domain is left empty except for
administrators belonging to the Enterprise Admins group. Next, you
migrate the account domains to become child domains of the empty root
domain. Finally, you migrate the resource domains to each become a
child domain of the most appropriate, former account domain. The
result is a tree with three levels of domains. Alternatively, you can
create OUs in the former account domains and join servers and
workstations in the resource domains to these former account domains,
placing them in the appropriate OUs. The result is a tree with only
two levels instead of three (a process called flattening the
domains), which is easier to manage.

Complete-trust model

This model consists of
two or more NT domains that trust each
other. The recommended procedure here is first to create an empty
root domain in a new forest and then migrate every NT domain to
become a child domain of the root domain. For example, if MTIT
Enterprises has the DNS domain name

mtit.com and
consists of two relatively independent offices in Vancouver and
Seattle, you could create the forest root domain

mtit.com in one of the two locations and add a
few high-level Administrator accounts to the Enterprise Admins group
in this root domain. Do not create any OUs or any other Active
Directory objects such as users, groups, computers, or printers in
this domain. In other words, this root domain is empty except for a
few enterprise-level Administrator accounts. Then create the domains

vancouver.mtit.com and

seattle.mtit.com as child domains of the root
domain

mtit.com . Let the members of the Domain
Admins group in each of these two child domains create the users,
groups, computers, printers, OUs, and other directory objects for
their own domains.