The Internet Encyclopedia (Volume 3)

P1: GSB/FFX P2: GSB/FFX QC: IML/FFX T1: IML

WL040C-63 WL040/Bidgoli-Vol III-Ch-64 June 23, 2003 16:45 Char Count= 0

794 WINDOWS2000 SECURITY

has a Globally Unique ID (GUID), a 128-bit identifier

unique to the object within a particular namespace. X.500

properties and naming conventions are beyond the scope

of this chapter; in brief, they provide an orderly way to or-

ganize and refer to objects. The X.500 directory structure

is detailed and cumbersome; consequently, the Internet

Engineering Task Force (IETF) created the Lightweight

Directory Access Protocol (LDAP) to provide a kind of

scaled-down, simplified version of X.500. W2K Active

Directory is based on LDAP.

Active Directory objects are organized in various man-

ners. Each object has one or more attributes. “Con-

tainers” are higher-level objects that hold other objects.

Directories, for example, are containers that hold one type

of object called “files” and another called “directories.”

The types of objects that that each container holds and

the properties (e.g., names) of the objects are determined

by the “schema.”

Microsoft designed Active Directory with the goal of

reducing barriers to locating and accessing resources

throughout a tree or forest, regardless of whatever net-

work boundaries (e.g., separation of networks from each

other) exist. Each machine within a tree or forest contains

objects (resources). The Global Catalog service enables

users and programs that run on users’ behalf to discover

available resources within a tree or forest. When a trust

link between domains is established, Global Catalog ser-

vices extend across domain boundaries. When a request

to access a resource occurs, the Domain Name Service

(DNS) not only resolves hostnames into IP addresses and

vice versa, but also resolves objects—that is, when given

an object name, it identifies exactly which object it is. In

effect, therefore, DNS is also the locator service for Active

Directory. Service Resource Records (SRRs) are the basis

for locating services and objects and to keep DNS tables

up to date. Dynamic DNS (DDNS), a service available in

more recent releases of BIND, updates Service Resource

Records (SRRs) to ensure that Global Catalog and other

directory service-related services can perform their func-

tions properly. DDNS also registers systems with dynamic

addresses that connect to the network.

Replication of Active Directory changes involves sev-

eral steps. The update process (e.g., when a user changes

a password or when an Administrator adds a new user to a

group) begins when an update in the copy of Active Direc-

tory within the DC that receives a change occurs. Each DC

that receives updates becomes part of a “replication topol-

ogy” that specifies the particular connections within a tree

or forest formed to synchronize the contents of Active Di-

rectory within each DC. At the designed time interval, the

connections are established and updates are sent to each

DC within the tree or forest. The Update Sequence Num-

ber (USN), a 64-bit number associated with an object, and

Property Version Number (PVN), a version number for

each object and the object’s attributes, for the changed

object are both incremented by the DC that records the

update. Additionally, the DC captures the timestamp for

the change.

Each DC updates its copy of Active Directory if the USN

and PVN are higher than the values it has for the object in

question. In case of a “conflict,” that is, if there has been

more than one change to the same object, the change with

most recent timestamp will be recorded in any DC’s copy

of Active Directory. Each DC that initiates one or more up-

dates and each DC that receives these updates constitutes

a “replication partner.” Several mechanisms are in place

to protect against one or more rogue machines from repli-

cating bogus changes—replication partners authenticate

to each other, changes on every DC are tracked, and access

control mechanisms (“permissions”) determine who can

modify Active Directory objects.

Group Policy Objects (GPOs)

GPOs are a collection of configuration settings related to

computer configuration and user profiles. They provide a

powerful way to store and flexibly apply policy settings.

Several types of GPOs exist, including the following:

Local GPOs (LGPOs), intended mainly for computers

that are not part of any Active Directory domain


Active Directory group policies, designed to be linked to

various Active Directory containers, such as sites (which

are explained shortly), domains, or OUs


System Policies—System Policies are legacy groups of

settings from NT System Policies if NT domains have

been migrated to W2K systems.

Many different GPOs can be created and linked—some

at the OU level, others at the domain level, others at sites

(subnets or groups of subnets used in controlling repli-

cation of Active Directory changes as well as for network

administration), and still others at the local level. GPOs

are applied in a predictable order. For computers, any lo-

cal computer GPOs are applied first, then site-linked com-

puter GPOs, then computer GPOs linked to domains, and

then local-linked computer OUs. The last GPO applied

normally is the one with the settings that go into effect.

This means that if there is a domain policy governing, say,

account lockout parameters and a local policy governing

the same, the domain policy settings will be the effective

settings. The same basic principle applies to user GPOs—

local GPOs that apply to users are applied first, followed by

site-linked GPOs, and so forth. Another way of saying this

is that OU-linked GPOs normally have precedence over all

other levels, followed by domain-linked GPOs, followed by

site-linked GPOs, followed by local GPOs (see Figure 2).

There is one important exception to the principle, how-

ever. In terms of place within the object hierarchy, sites are

above domains, and domains are above OUs. Parent OUs

are always above child OUs, too. If someone with suffi-

cient privileges (e.g., a Domain Administrator) sets a “No

Override” for a GPO that is linked at a higher level within

this hierarchy, conflicting settings of GPOs set a lower

levels will not apply (as shown in Table 1). The “No Over-

ride” setting thus becomes the good way for Domain Ad-

ministrators to “gain the upper hand” by linking GPOs to

domains and OUs, then setting a “No Override” on

domain-linked GPOs. This, for the most part, ensures that

any OU administrators will not be able to negate domain

group policy.

If there are multiple GPOs within any single level of

precedence (e.g., OU level), the policy that has been most

recently linked to that level is by default the one that is