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

Active Directory is the
central repository of information on
a WS2003-based network. Active Directory stores information about
where different resources are located on the network. These resources
include user and group accounts, computers, printers, and shared
folders. Active Directory can be used to locate these resources
quickly so that administrators can create, delete, configure, and
maintain them as needed, and ordinary users can access them if they
have suitable permissions to do so. Active Directory gives
administrators a great deal of flexibility in how their network
resources should be administered. By managing resources from any
location in the enterprise, you can centralize IT administration in a
few users or a single location. On the other hand, Active Directory
allows you to create structure using domains and OUs and then to
delegate authority over these portions. This allows for decentralized
administration in which certain administrative tasks are devolved to
various trusted users throughout the enterprise. Active Directory is
managed primarily through the GUI but can also be programmatically
accessed through an API called the Active
Directory Service Interface (ADSI). By writing scripts that use ADSI,
administrators can automate most Active Directory administrative
procedures, but this requires a good understanding of VBScript or
JScript and is beyond the scope of this book.

Logical Structure of Active Directory

In its most abstract sense, Active Directory
represents a company's network resources using a
hierarchical structure of logical objects such as the following:

Forest

The most encompassing logical construct
in Active Directory. A forest is a collection of domain trees linked
together at their roots by transitive trusts.

Tree

Also called a domain tree, a hierarchical
grouping of domains beginning with a root domain and branching out to
child domains. Trees must form a contiguous DNS namespace, and a
forest can consist of one or more trees joined at their roots by
transitive trusts.

Domain

The primary administrative boundary for
WS2003 networks. Domains are named using DNS, and a tree consists of
one or more domains hierarchically joined by transitive trusts.

Organizational unit (OU)

Logical containers you can use to group objects
in a domain for security and administration purposes. You can create
hierarchical treelike structures of OUs to reflect your
company's geographical, organizational, or
administrative structure.

Object

A user, group, computer, printer, shared
folder, or anything else that can be
"contained" within a domain or OU.
For example, a user object represents an employee within your
company, a computer object represents a physical computer, and so on.

Trust

A secure communications channel between
domains, domain trees, or forests. Trusts enable users in one domain
to be authenticated by a domain controller in other domains and may
be transitive, one-way, or cross-linked in nature.

For more information on these topics, see

Domain ,

Domain Controller ,

Forest ,

OU , and

Trusts . For more information on specific types
of Active Directory objects, see

Group s,

Printing ,

Shared Folders ,
and

Users .

Planning Active Directory

A big part of planning for an Active
Directory deployment involves planning the logical structure that
best meets your company's administrative and
security needs. Figure 4-1 illustrates the logical structure of an
Active Directory with domains represented by black dots, trees by
shaded areas, and trusts by lines joining domains. The entire diagram
represents the forest. In addition, domains may also contain
organizational units. An OU is a logical container that can be
created to enclose other Active Directory objects, such as users,
computers, groups, printers, or even other OUs.

The typical approach to creating the logical structure for Active
Directory is to create your domains and trees in a way that mirrors
the geographical or administrative structure of your company. For
example, you might create separate domain trees for your American and
European offices with the root domain of each tree representing
headquarters and child domains representing branch offices. Then you
would create OUs within your domains to establish a more granular
level of logical structure. For example, you could create separate
OUs for your management, sales, human resources, and customer support
departments. Then within your sales OU you could create additional
OUs for different product groups. The key idea in planning the
logical structure of Active Directory is that the domains and
upper-level OUs you create should be relatively stable and unchanging
in order to simplify administration through delegation and use of
Group Policy.

The most important thing to remember when planning your Active
Directory structure is to keep it simpleif you can get by
using only one domain, then do so. On the other hand, there are
sometimes advantages to having multiple domains (or even multiple
trees) in your forest, the main one being that by partitioning Active
Directory into multiple domains you have better control over
replication traffic, an issue of particular importance in a company
spanning several locations connected by slow wide area network (WAN)
links. Planning an Active Directory implementation is a complex
subject, however, and is beyond the scope of this book; for a good
book on this subject, see

Active Directory
(O'Reilly).

Figure 4-1. Typical logical structure of Active Directory

DNS and Active Directory

Since Active Directory domains are named using DNS,
planning Active Directory also involves planning the DNS names of the
domains within your forest. The most important choice is your root
DNS name, the name of the first domain of your forest (called the
forest root domain). You should generally select a root DNS name that
reflects the largest scope of your entire organization, taking into
account all of its branch offices, subsidiaries, partners, and even
planned acquisitions and mergers. For more information on
implementing a DNS WS2003 namespace for Active Directory, see

Planning DNS under

DNSConcepts later in this chapter.

In Windows 2000 (W2K) it was important to plan your DNS naming scheme
and domain structure carefully since you couldn't
rename domains after you created them in Active Directory. W2K did
allow you to restructure your forest by creating new domains and
using the

MoveTree utility from Support Tools to
move objects from old to new domains, but this was not a trivial
procedure. WS2003 takes things a little further and now allows you to
rename your domains, including your forest root domain, and to
restructure your forest more easily by repositioning domains within a
tree or forest. To accomplish these tasks, Microsoft provides a
Domain
Rename tool that is available on its web site (use search.microsoft.com and search for
"domain rename tool" to find the
current URL for downloading it^[1]). Note that this tool works only if all your domain
controllers are running WS2003 and can't be used to
change which domain is the root domain of your forest, to add or
delete domains from your forest, or to change the name of a domain to
the same name that another domain gave up in a previous
restructuring. The main thing to remember is that the procedures
involved are still complex and aren't intended for
everyday administration; they should be used only for an exceptional
event such as your company being acquired through a merger or
changing its business identity.

^[1] At this writing it is
http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx.

Delegation and Group Policy

While a simple deployment of one domain
could be managed by a single administrator, enterprises that have
many domains and OUs can take advantage of two powerful features of
WS2003 that simplify administering and securing Active Directory:
delegation and Group Policy. Delegation lets an administrator assign
limited administrative rights over domains and OUs to trusted users
in order to distribute the burden of managing Active Directory. Group
Policy allows policy-based management of user and computer objects
within Active Directory. See

Delegation and

Group Policy later in this chapter for more
information.

New to WS2003 is the ability for administrators to set quotas
limiting the number of objects that can be created in Active
Directory by a user who has been delegated limited administrative
authority. This new feature can be managed only from the command
line; see dsadd, dsget,
dsmod, dsmove, and
dsquery in Chapter 5 for more
information.

Schema

One final aspect
of Active Directory's logical structure is the
schema, which defines the classes of objects the directory may
contain and the attributes these objects may have. Active Directory
comes with a default schema that may be suitable for most companies,
but the schema is also extensible for companies that need to create
new object types and attributes. Modifying the schema is beyond the
scope of this book.

Topological Structure of Active Directory

Besides logically representing your
company's network resources, Active Directory can
also topologically represent your company's IP
internetwork. Large computer networks based on IP generally have a
mesh-like structure in which smaller networks called subnets are
joined together with routers into a single large internetwork. These
subnets may be located at different geographical locations, in which
case WAN links are used to connect locations. To ensure that Active
Directory performs optimally over slower WAN connections, a
topological structure can be created within Active Directory to
reflect the WAN connections of your internetwork. The main elements
of such a topology are sites. A

site is a
grouping of subnets that have high-speed (local area
networkLAN) connections throughout. Sites are joined to other
sites using site links (the logical counterpart in Active Directory
to physical WAN links). Sites are important because domain
controllers replicate portions of Active Directory with one another,
and using sites allows replication traffic to be controlled so that
it doesn't swamp the available bandwidth of slow WAN
links. See

Site later in this chapter for more
information on these topics.

Physical Structure of Active Directory

From a physical
perspective, Active Directory resides on special servers called

domain controllers , which authenticate users and
enable them to locate and access resources across the forest. To
ensure scalability, Active Directory is partitioned into
naming
contexts (NCs), which are contiguous
subtrees of directory objects
and units of replication. Each domain controller has a replica of
three directory partitions:

Schema NC

Contains the classSchema and attributeSchema
objects, which define the kinds of objects that can exist in the
forest. Every domain controller in the forest contains a full replica
of the same schema NC.

Configuration NC

Contains objects that define the
replication topology and other forestwide information. Every domain
controller in the forest contains a full replica of the same
configuration NC.

Domain NC

Contains objects like users and computers that
belong to the local domain. Every domain controller in a domain
contains a full replica of the domain NC for that domain, but domain
controllers in one domain don't contain replicas of
domain NCs for other domains.

Synchronization between domain controllers
in a domain is maintained using multimaster
replication, a process in which all
domain controllers within a domain are peers and contain writable
copies of the Active Directory partition for the domain (this is
different from NT, in which only one domain controller, the PDC,
contained a writable copy of the domain database). To speed queries
across multiple domains in a forest, a subset of commonly used Active
Directory objects called the global catalog is maintained by each
domain.

Directories and Files

The Active Directory database and log files
are located by default in the directory
%SystemRoot%\NTDS and must be located on an NTFS
partition. The main directory database file, or datastore, is
NTDS.dit; it uses the
Extensible Storage Engine (ESE) database
engine in Microsoft's Exchange Server. The database
can grow to a maximum size of 16 terabytes and can contain more than
10 million objects, which means Active Directory can support even the
largest enterprise networks. The database defragments and repairs
itself automatically, but it can also be taken offline and manually
defragmented using the ntdsutil utility to
reclaim unused space in the directory database. For better
performance, Active Directory log
files can be placed on a separate physical disk (these log files
record transactions written to the datastore and can be used to help
restore a system if the datastore volume is lost). A typical
configuration might be:

• WS2003 operating system installed on a mirrored volume

• Datastore located on a RAID-5 volume with at least 4 GB to
  accommodate future datastore growth

• Log files located on a mirrored volume

Make sure you back up Active Directory regularly. You can do this using the WS2003 Backup utility, which allows Active Directory and other system state information to be backed up while running. See Backup later in this chapter for more.

SYSVOL

Installing
Active Directory creates and shares the directory
%SystemRoot%\sysvol\sysvol with the share name
SYSVOL. The SYSVOL share contains NETLOGON shares, Group Policies,
logon scripts, and other important files that are replicated by the
File Replication Service
(FRS) to all domain controllers in the domain. Other than placing
your logon scripts into the correct subdirectory of SYSVOL, you
shouldn't fool around with any of the files stored
there.