Step by Step guide to setup Active Directory

on Windows Server 2008

This tutorial will explain how to install AD on server 2008. This will valid for windows 2008
R2 as well.
Requirement:
Minimum: Single processor with 1.4 GHz (x64 processor) or 1.3GHz (Dual Core)
Minimum: 512 MB RAM
Minimum: 32 GB or greater

The first step is to assign a ip to the server that you going to deploy the AD. Its
nessary to install it as DNS server too. So its better to have fixed ip it doesn't mean
you cannot install AD without fixed ip address but it will solve lot of issues if you
used fixed ip.

In here the server ip is 10.0.0.14. Since we going to make it as DNS server too you should
use the same ip as the preferred DNS server.

Next step is to install the Active directory roles. Unlikely the older version of
windows servers Microsoft highly recommend to use server manager option to install
roles before you run dcpromo.

Click on start menu and select the Server Manager

Select the roles from the right hand panel and click on add roles option.

From the roles list select the "Active Directory Domain Services" role and Click
"Next"

Review the confirmation and click on "Next"

Review the installation confirmation and click on "Next"

It will take few minutes to complete and when its done you will get this confirmation.
And then click on "Close"

After that you will need to do a reboot.

After reboot please open up the "server Manager" again. And then click on "Roles"
there you will see the "Active Directory Domain Services" is successfully installed in
there. click on it then you will get a window like below.

In their please pay attention to the message

So please click on that link and it will start the DCPROMO wizard.

So next step to go through the DC promo wizard.

To start the installation click on "Next"

Click on "Next"

Since we going to install New domain Controller in new forest please select the
option "Create a new domain in new forest" option and click on "Next"

Now we have to provide the name for our domain controller. It must be FQDN. In our
case I used rebeladmin.com as the domain. Please click "Next" after it.

In this window it will ask to select forest function level. If you going to add server
2003 domain controller to your forest later don't select the function level as server
2008. If you going to use full features of 2008 Ad you must select forest function
level as server 2008. In my case I used server 2008. Click on "Next" after the select.

In next window since it's the first DC we should make it as DNS server too. Leave the
default selection and click on "Next"

If the wizard cannot create a delegation for the DNS server, it displays a message to
indicate that you can create the delegation manually. To continue, click "Yes"

In next window it will show up the database location. It its going to be bigger AD its
good if you can keep NTDS database in different partition. Click on "Next" after
changes.

In next window its asking to define a restore mode password. Its more important if
you had to do a restore from backup in a server crash. Click on "Next" after filling it.

Next window is giving you a brief of the installation. Click on "Next"

Then it will start the installation of the AD. It will take some time to complete. After
complete of the installation perform a server reboot.

After the reboot now you can login to the domain. Please use the login as following
example

User name : your domain\administrator

Password : XXXXXXXX

Now its done and you can view the active directory options on administrative tools
menu

Hope this tutorial is clear for you guys. If any question please ask me on

Step-by-Step Guide to Managing the Active

Directory
98 out of 116 rated this helpful - Rate this topic

Abstract
This guide introduces you to administration of the Windows 2000 Active Directory
service. The procedures in this document demonstrate how to use the Active Directory Users
and Computers snap-in to add, move, delete, and alter the properties for objects such as users,
contacts, groups, servers, printers, and shared folders.
On This Page

Introduction
Using Active Directory Domains and Trusts Snap-in
Using the Active Directory Users and Computers Snap-in
Publishing a Shared Folder
Finding Specific Objects
Filtering a List of Objects
Introduction

This guide introduces you to administration of the Microsoft Windows 2000 Active
Directory service and the Active Directory Users and Computers snap-in. This snap-in
allows you to add, move, delete, and alter the properties for objects such as users, contacts,
groups, servers, printers, and shared folders.
Prerequisites

This Software Installation and Maintenance document is based on Step-by-Step Guide to the
Common Infrastructure for Windows 2000 Server Deployment,
http://www.microsoft.com/windows2000/techinfo/planning/server/serversteps.asp.
Before beginning this guide, please build the common infrastructure, which specifies a
particular hardware and software configuration. If you are not using the common
infrastructure, you need to make the appropriate changes to this instruction set.
You can run the Administrative Tools from the server, or you can run the tools from a
computer running Windows 2000 Professional. The Administrative Tools are installed by
default on all Windows 2000 domain controllers.
You must be logged on as a user with administrative privileges to run through the procedures
in this document.
If you are working on a domain controller, the Active Directory Schema snap-in might not be
installed. To install it:

1. Click Start, point to Settings, click Control Panel, and then click Change or
Remove Programs.
2. When prompted, reinstall all the Administrative Tools.
On Windows 2000-based stand-alone servers or workstations, Active Directory
Administrative Tools are optional. You can install them from Add/Remove Programs in
Control Panel, using the Windows Components wizard, or from the ADMINPAK on the
Windows 2000 Server or Professional CD.
In this Step-by-Step Guide:

Common Administrative
Tasks

Creating Organizational Units

Creating Users and Contacts
Creating Groups and adding members to Groups

Advanced Administrative
Tasks

Publishing shared network resources, such as shared folders

and printers.
Moving Users, Groups, and Organizational Units
Using Filters and Searches to retrieve objects

Top of page
Using Active Directory Domains and Trusts Snap-in

The Active Directory Domains and Trusts snap-in provides a graphical view of all domain
trees in the forest. Using this tool, an administrator can manage each of the domains in the
forest, manage trust relationships between domains, configure the mode of operation for each
domain (native or mixed mode), and configure the alternative User Principal Name (UPN)
suffixes for the forest.
Starting the Active Directory Domains and Trusts Snap-in

1. Click Start , point to Programs, point to Administrative Tools, and then click
Active Directory Domains and Trusts. The Active Directory Domains and Trusts
snap-in appears as in Figure 1 below.

Figure 1: Active Directory Domains and Trust snap-in

2. The User Principal Name (UPN) provides an easy-to-use naming style for users to log
on to Active Directory. The style of the UPN is based on Internet standard RFC 822,
which is sometimes referred to as a mailaddress. The default UPN suffix is the forest
DNS name, which is the DNS name of the first domain in the first tree of the forest. In
this and the other step-by-step guides on this site, the default UPN suffix is
reskit.com.
3. You can add alternate User Principal Name suffixes, which increase logon security.
And you can simplify user logon names by providing a single UPN suffix for all
users. The UPN suffix is only used within the Windows 2000 domain and is not
required to be a valid DNS domain name.
4. Select Active Directory Domains and Trusts in the upper left pane, right-click it,
and then click Properties.
5. Enter any preferred alternate UPN suffixes in the Alternate UPN Suffixes box and
click Add.
6. Click OK to close the window.
Changing the Domain Mode

Windows 2000 domains operate in one of two modes:

Mixed Mode. Allows domain controllers running both Windows 2000 and earlier
versions of Windows NT Server to co-exist in the domain. In mixed mode, the
domain features from previous versions of Windows NT Server are still enabled,
while some Windows 2000 features are disabled.

Native Mode. Requires all the domain controllers in a domain to run Windows 2000
Server. In native mode, you can take advantages of new features such as Universal
groups, nested group membership, and inter-domain user move. (A Universal group is
a collection of user accounts that can contain members from any Active Directory
domain in the forest, and permissions can be assigned to a universal group to
resources on any member computer in the forest. Universal groups are available only
in native mode.)

When a domain is first installed, it is in mixed mode. The mode of operation can be changed
from mixed mode to native, but this is not reversible. In native mode, Windows NT 4.0
Domain Controllers cannot participate in the domain.
You can change to native mode after making sure all domain controllers in your domain are
running Windows 2000 Server.
To switch to native mode
1. Right-click the domain object (in our example, reskit.com), and then click
Properties.
2. Click Change Mode.

3. You receive a message requiring confirmation. Click Yes to continue. Click OK to

proceed, or No to stop this action. If you plan to add Windows NT 4.0 domain
controllers to your configuration, do not proceed.
Top of page
Using the Active Directory Users and Computers Snap-in

1. To start the Active Directory Users and Computers snap-in, click Start, point to
Programs, point to Administrative Tools, and then click Active Directory Users
and Computers.
2. Expand Reskit.com by clicking +.
Figure 2 below displays the key components of the Active Directory Users and
Computers snap-in.

Figure 2: The Active Directory Users and Computers Snap-In

Recognizing Active Directory Objects

The objects described in the following table are created during the installation of Active
Directory.
Icon

Folder
Domain

Description
The root node of the snap-in represents the domain being administered.

Contains all Windows NT and Windows 2000-based computers that join a

domain. This includes computers running Windows NT versions 3.51 and
Computers 4.0, as well as those running Windows 2000. If you upgrade from a previous
version, Active Directory migrates the machine account to this folder. You
can move these objects.
System

Contains Active Directory systems and services information.

Users

Contains all the users in the domain. In an upgrade, all users from the
previous domain will be migrated. Like computers, the user objects can be
moved.

You can use Active Directory to create the following objects.

Icon

Object

Description

User

A user object is an object that is a security principal in the directory. A

user can log on to the network with these credentials and access
permissions can be granted to users.

Contact

A contact object is an account that does not have any security

permissions. You cannot log on to the network as a contact. Contacts
are typically used to represent external users for the purpose of e-mail.

Computer

An object that represents a computer on the network. For Windows

NT-based workstations and servers, this is the machine account.

Organizational units are used as containers to logically organize

Organizational
directory objects such as users, groups, and computers in much the
Unit
same way that folders are used to organize files on your hard disk.
Group

Groups can have users, computers, and other groups. Groups simplify
the management of large numbers of objects.

Shared Folder

A shared Folder is a network share that has been published in the

directory.

Shared printer

A shared printer is a network printer that has been published in the

directory

Adding an Organizational Unit

This procedure creates an organizational unit (OU) in the Reskit domain. Note that you can
create nested organizational units and there is no limit to the nesting levels.
These steps follow the Active Directory structure begun in the the "Step-by-Step Guide to a
Common Infrastructure for Windows 2000 Server Deployment"
http://www.microsoft.com/windows2000/techinfo/planning/server/serversteps.asp. If you did
not create that structure, add the OUs and users directly under Reskit.com; that is, where
Accounts is referred to below, substitute Reskit.com.
1. Click the + next to Accounts to expand it.

2. Right-click Accounts.
3. Point to New and click Organizational Unit. Type Construction as the name of your
new organizational unit. Click OK.
For the rest of the exercises in this guide, repeat steps 1 and 2 above to create additional
organizational units, as follows:

Organizational unit Engineering under Reskit.com.

Organizational unit Manufacturing under Reskit.com.

Organizational unit Consumer under the Manufacturing organizational unit. (To do

this, right-click Manufacturing, point to New, and then click Organizational Unit.)

Organizational units Corporate and Government under the Manufacturing

organizational unit. Click Manufacturing so that its contents will display in the right
pane.

When you are finished, you should have the following hierarchy as in Figure 3 below:

Figure 3: New OUs

Creating a User Account

The following procedure creates the user account James Smith in the Construction OU.
To create a new user account
1. Right-click the Construction organizational unit, point to New, and then click User,
or click New User on the snap-in toolbar.
2. Type user information as in Figure 4 below:

Figure 4: New User dialog

Note that the Full name is automatically filled in after you enter the First and Last
names. Click Next to proceed.
3. Type a password in both the Password and Confirm password boxes and click Next.
4. Accept the confirmation in the next dialog box by clicking Finish.
You have now created an account for James Smith in the Construction OU To add
additional information about this user:
5. Select Construction in the left pane, right-click James Smith in the right pane, and
then click Properties.
6. Add more information about the user in the Properties dialog box on the General tab
as shown in Figure 5 below, and click OK. You are provided with this selection of
optional entries. Click each tab you want to go to.

Figure 5: Additional User Information

Moving a User Account

Users can be moved from one organizational unit to another in the same domain or a different
domain. For example, in this procedure, James Smith moves from the Construction division
to the Engineering division.
1. Click the James Smith user account in the right pane, right-click it, and click Move.
2. Click the + next to Accounts to expand it as in Figure 6 below.

Figure 6: List of available OUs

3. Click the Engineering OU, and click OK.

If you upgrade from an earlier version of Windows NT Server, you might want to move
existing users from the Users folder to some of the OUs that you create.
Creating a Group

1. Right-click the Engineering OU, click New, and then click Group.
2. In the Name of New Group text box, type: Tools
Select the appropriate Group type and Group scope and then click OK.
o

The Group type indicates whether the group can be used to assign
permissions to other network resources, such as files and printers. Both
security and distribution groups can be used for e-mail distribution lists.
The Group scope determines the visibility of the group and what type of
objects can be contained within the group.
Scope

Visibility

May contain

Domain Local Domain Users, Domain Local, Global, or Universal Groups

Global

Forest

Users or Global groups

Universal

Forest

Users, Global, or Universal Groups

Adding a User to a Group

1. Click Engineering in the left pane.

2. Right-click the Tools group in the right pane, and click Properties.
3. Click the Members Tab and click Add.
4. Scroll to James Smith, select his name, click Add, then click OK as in Figure 7
below.

Figure 7: Add James Smith to the Tools Group

Note: You can select multiple users or groups in this dialog by pressing the CTRL key as you
click them. You can also type the name directly. If the name is ambiguous, a further list is
displayed to confirm your selection.
Alternatively, you can select the users from the results pane, right click then click Add
members to a Group. Or you can click Add the selected objects to a group you specify on
the snap-in toolbar. This may be more efficient for adding large numbers of members to a
group.
Top of page
Publishing a Shared Folder

Any shared network folder, including a Distributed File System (Dfs) folder, can be published
in Active Directory. Creating a Shared folder object in the directory does not automatically
share the folder. This is a two-step process: you must first share the folder, and then publish it
in Active Directory.
1. Use Windows Explorer to create a new folder called Engineering Specs on one of
your disk volumes.
2. In Windows Explorer, right-click the folder name, and then click Properties. Click
Sharing, and then click Share this folder.

3. In the New ObjectShared Folder dialog box, type ES in the Share name box and
click OK. By default, Everyone has permissions to this shared folder. If you want,
you can change the default by clicking the Permissions button.
4. Populate the folder with files, such as documents, spreadsheets, or presentations.
To publish the shared folder in the directory

1. In the Active Directory Users and Computers snap-in, right-click the Engineering OU,
point to New, and click Shared Folder.
2. In the Name box, type Engineering Specs.
3. In the Network Path name box, type \\hq-res-dc-01.reskit.com\ES and click OK.
The Engineering organizational unit appears as shown in Figure 8 below:

Figure 8: Engineering OU contents

Users can now see this volume while browsing in the directory.
To browse the directory
1. Double-click My Network Places on the desktop.
2. Double-click Entire Network, and then click Entire contents of the network.
3. Double-click the Directory.
4. Double-click the domain name, Reskit, and then double-click Engineering.
5. To view the files in the volume, either right-click the Engineering Specs volume, and
click Open, or double-click Engineering Specs.

Publishing a Printer

This section describes the processes for publishing printers in a Windows 2000 Active
Directory-based network.
Windows 2000 Printers
You can publish a printer shared by a computer running Windows 2000 by using the Sharing
tab of the printer Properties dialog box. By default, Listed in the directory is enabled. The
directory is the Active Directory data store. (This means that Windows 2000 Server publishes
the shared printer by default.) The print subsystem will automatically propagate changes
made to the printer attributes (location, description, loaded paper, and so forth) to the
directory.
Note: For this section of this guide, you must have a printer available and know its IP
address. If you do not have an IP printer, you can still run through these procedures,
substituting the correct port for Standard TCP/IP Port.
To add a new printer
1. Click Start, point to Settings, click Printers, and then double-click Add Printer.
The Add Printer Wizard appears. Click Next.
2. Click Local Printer, clear the Automatically detect and install my Plug and Play
printer checkbox, and click Next.
3. Click the Create a new port option, then scroll to Standard TCP/IP Port, and click
Next.
4. The Add Standard TCP/IP Printer Port Wizard appears. Click Next.
5. On the Add Port page, type the IP address of the printer in the Printer Name or IP
Address box, type the port name in the Port name box, and click Next. Click Finish.
6. Select your printer's manufacturer and model in the Printers list box, and then click
Next.
7. In the Printer name text box, type the name of your printer.
8. On the Printer Sharing page, type a name for the shared printer. Choose a name no
more than eight characters long so computers running earlier versions of the operating
system display it correctly.
9. Type in the Location and Comment in those text boxes.
10. Print a test page. Click Finish.
After you create the printer, the printer is automatically published in Active Directory and the
Listed in the Directory check box is selected.

You might also need to find the server from which a printer is shared out before adding it to
the machine you're working on.
To locate a printer
1. Click Start, point to Settings, and then click on Printers.
2. Double-click the Add Printer icon.
3. In the Add Printer Wizard dialog box, click the Next button.
4. Select the Network printer button, and then click Next.
5. Select the Find a printer in the Directory button, and then click Next.
6. The Find Printers dialog box displays. If you know which domain your printer
resides in, click the Browse button and choose that domain to narrow your search.
Then, on the Printer tab, add the printer Name, Location, or Model to those text
boxes, and click the Find Now button.
Note: If you don't know the name, location, or model of the printer, you can simply click the
Find Now button, and all the printers in the domain you selected will be listed in the list box.
Adding Non-Windows 2000 Printers
You can publish printers shared by operating systems other than Windows 2000 in the
directory. The simplest way to do this is to use the pubprn script. This script will publish all
the shared printers on a given server. It is located in the \winnt\system32 directory.
To publish a printer shared from a non-Windows 2000 server using the pubprn.vbs
script
1. Click Start, click Run, and type cmd in the text box. Click OK.
2. Type cd\ winnt/system32 and press Enter.
3. Type cscript pubprn.vbs printer server name where in this example
"LDAP://ou=marketing,dc=reskit,dc=com" and press Enter. This publishes the
printer to the specified OU.
This script copies only the following subset of the printer attributes:

Location
Model

Comment

UNCPath

You can add other attributes by using the Active Directory Users and Computers snap-in.
Note that you can rerun pubprn and it will update rather than overwrite existing printers.

Alternatively, you can use the Active Directory Users and Computers snap-in to publish
printers on non-Windows 2000 servers.
To use the Active Directory Users and Computers snap-in to publish printers
1. Right-click the Marketing organizational unit, click New, and click Printer.
2. The New Object-Printer dialog box pops up. In the text box, type the path to the
printer, such as \\ server \ share name . Click OK.
End users can realize the benefit of printers being published in the directory because they can
browse for printers, submit jobs to those printers, and install the printer drivers directly from
the server.
To browse and use printers in the directory
1. On the Desktop, click Start, click Search, and click For Printers.
2. In the Find Printers dialog, select the subdirectory in which you'd like to search for
printers. Then type information into the Name, Location, or Model text boxes. Click
the Find Now button to get a list of published printers.
Creating a Computer Object

A computer object is can be created automatically when a computer joins a domain. You can
also create the computer object before the computer joins a domain.
1. Right-click the Engineering organizational unit, point to New, and then click
Computer.
2. For the computer name, type Vancouver.
3. You can manage this computer In the Active Directory Users and Computers snapin, by right-clicking the computer object, and then clicking Manage.
Optionally, you can select which users are permitted to join a computer to the domain. This
allows the administrator to create the computer account and someone with lesser permissions
to install the computer and join it to the domain.
Renaming, Moving, and Deleting Objects

1. Every object in the directory can be renamed and deleted, and most objects can be
moved to different containers.
2. To move an object, right-click the object, and then click Move.
3. Click Browse. The Directory Browser will appear, enabling you to select the
destination container for the object that you are moving.

Creating Nested Groups

You can use nested groups providing that you are running the Active Directory in Native
Mode. Nested groups are easier to manage, and thus reduce administrative overhead.
1. Create a new group by right-clicking Engineering, pointing to New, and then clicking
Group. Type All Engineering and then click OK.
2. Right-click the All Engineering Group, and click Properties.
3. Click the Members tab and click Add.
4. In the list box, select Tools, click Add, and then click OK.
5. Click Apply, and then click OK. You've now created a nested group.
To check the nested groups
1. Right-click All Engineering, click Properties, and then click Membership. You will
see Press Liaison as a member of All Engineering.
2. Double-click Tools, and then click Membership. You will see Tools listed as a
member of the group All Engineering.
Top of page
Finding Specific Objects

Rather than browsing the list of objects in the results pane, it is often more efficient to find
specific objects that meet a certain criteria. In this example you will find all users who have a
surname of "Smith" and are in the Marketing organizational unit.
1. Select the Engineering OU. Right-click Engineering, and then click Find.
2. In the Name box, type Smith.
3. Click Find Now.
Top of page
Filtering a List of Objects

Filtering the list of returned objects from the directory can allow you to manage the directory
more efficiently. The filtering option allows you to restrict the types of objects returned to the
snap-infor example, you can choose to view only users and groups, or you may want to
create a more complex filter.
If an OU has more than a specified number of objects, the filter function allows you to restrict
the number of objects displayed in the results pane. You can use the Filter function to
configure this option.
In this example, you create a filter designed to retrieve users only.

1. In the Active Directory Users and Computers snap-in, click the View menu, click
Filter Options.
2. Click the radio button for Show only the following types of objects, and then select
Users and Groups.
3. Click OK.
After you click OK, whenever you view a container, it retrieves user and group objects only.
For example, if you now view the Engineering OU, the shared folder Engineering Specs will
no longer be displayed. The description bar above the contents of the right pane will show
that the list is filtered.
Important Notes

The example company, organization, products, people, and events depicted in this step-bystep guide is fictitious. No association with any real company, organization, product, person,
or event is intended or should be inferred.
This common infrastructure is designed for use on a private network. The fictitious company
name and DNS name used in the common infrastructure are not registered for use on the
Internet. Please do not use this name on a public network or Internet.
The Active Directory service structure for this common infrastructure is designed to show
how Windows 2000 features work and function with the Active Directory. It was not
designed as a model for configuring an Active Directory for any organizationfor such
information see the Active Directory documentation.

Step-by-Step Guide to Mapping Certificates

to User Accounts
5 out of 14 rated this helpful - Rate this topic
On This Page

Introduction
Types of Mapping
Where Mapping Occurs

Requesting the User Certificate

Installing CA Certificates
Preparing IIS for Mapping
One-to-One Mapping
Many-To-One Mapping
Testing the Mapping
Related Links
You can use certificate mapping in Active Directory to provide security for your network.
This is done with public-key technology, a safeguard that is much more resistant to attack
than password-based systems. This guide explains how to map public-key certificates to a
Windows 2000 user account so that it can be used with Internet Information Services (IIS).
Introduction

The Windows 2000 operating system provides a rich administrative model for managing
user accounts. In a corporate environment with relatively few threats, the user
account/password model works very well. However, the Internet is a potentially hostile
environment, more prone to user ID/password attacks. Certificate mapping provides an
elegant solution to this situation by using public-key technology, a safeguard that is much
more resistant to attack than password-based systems. In Windows 2000, it is possible to map
a certificate that has been issued to a user to the user's account. A server application can then
use public-key technology to authenticate the user through this certificate. If the user is
authenticated, the user's account is logged on. The result is the same as if the user had
provided a user ID and password; yet the process is much more secure.
Traditionally, computer systems have used a centralized accounts database to manage users,
their privileges, and their access controls. This technique has worked well, and is generally
well-understood. However, as systems become more distributedwith hundreds of thousands
to millions of usersthis form of centralized control often becomes difficult to manage. The
problems range from trying to verify an account against a database located across the
Internet, to administering a lengthy list of users.
Public key certificates have the potential to help simplify these problems. Certificates can be
widely distributed, issued by numerous parties, and verified by examining the certificate
without referring to a centralized database. However, existing operating systems and
administration tools can only deal with accounts, not certificates. The simple solution that
maintains the advantages of both certificates and user accounts is to create an associationor
mappingbetween a certificate and a user account. This allows the operating system to
continue using accounts while the larger system and the user use certificates.
In this model, a user presents a certificate, and the system looks at the mapping to determine
which user account should be logged on. This should not be confused with smart card logons.
Windows 2000 supports smart card logon, and that mapping is implicit. For more
information, see the Windows 2000 guide on smart card logon
http://www.microsoft.com/windows2000/techinfo/howitworks/security/sclogonwp.asp.
Mapping a certificate to a Windows 2000 user is done either through the Windows 2000
Active Directory service, or with rules defined in Internet Information Service (IIS). This
guide helps you map public key certificates to a specific Windows 2000-based user account.

The certificate can then be used to authenticate the user with a computer running Windows
2000 and IIS.
Requirements and Prerequisites

This step-by-step guide assumes that you have run the procedures in Step-by-Step Guide to a
Common Infrastructure for Windows 2000 Server Deployment, Part 1.
The common infrastructure documents specify a particular hardware and software
configuration. If you are not using the common infrastructure, you need to make the
appropriate changes to this document. The most current information about hardware
requirements and compatibility for servers, clients, and peripherals is available at the
Windows 2000 Product Compatibility Search page .
This guide assumes you have already completed:

Step by Step Guide to Managing the Active Directory

If you have not completed those step-by-step guides, you must still create the following
environment to be successful with the procedures described in this document:

You have installed Windows 2000 Professional operating system on a computer in a

Windows 2000 domain.
Windows 2000 Certification Authority (CA) is running in the domain.

Windows 2000 operating systems running in the domain.

A trusted certificate authority.

A user certificate service or certificates issued by a trusted CA.

Windows 2000 Active Directory service.

Internet Information Services (IIS).

Administrative permissions for the person mapping the CA to user accounts.

Top of page
Types of Mapping

In most cases, a certificate is mapped to a user account in one of two ways: a single
certificate is mapped to a single user account (one-to-one mapping), or multiple certificates
are mapped to one user account (many-to-one mapping).
User Principal Name Mapping

User principal name mapping is a special case of one-to-one mapping. User principal name
mapping is only available through the Active Directory. Enterprise certificate authorities
(CAs) place an entry, called a UPN, into each certificate. The UPN looks very much like an

e-mail name. The UPN is unique within a Windows 2000-based domain. The UPN is used to
find the user's account in the Active Directory, and that account is logged on. UPN mappings
are implicit in Windows 2000, and this is the method used by smart card logon. (See the next
section below "Active Directory Mapping" for more details.)
One-to-One Mapping

One-to-one mapping involves mapping a single user certificate to a single Windows 2000
user account. For example, assume you want to provide a Web page to your employees that
will allow them to view and modify their deductions, manage their health care, and other
benefits. You want this page to work over the Internet and remain secure. As a solution, you
decide to use Windows 2000, certificates, and certificate mapping. You can either issue
certificates to each of your employees from your own certificate service, or you can have
your employees obtain certificates from a CA approved by your company. You then take
these user certificates and map them to the employees' Windows 2000 user accounts. This
allows users to connect to the Web page, using the Secure Sockets Layer (SSL) from
anywhere by providing their client certificate. Users log on using their user account and
normal access controls can be applied.
Many-to-One Mapping

Many-to-one mapping involves mapping many certificates to a single user account. For
example, assume you have a partnership with an agency that provides temporary workers for
your job openings. You would like to allow the agency personnel to view Web pages
describing current job openings that are otherwise accessible only to company employees.
The agency has its own CA that it uses to issue a certificate to its employees. After installing
the agency CA's root certificate as a trusted root in your enterprise, you can set a rule that
maps all certificates issued by that CA to map to a single Windows 2000 account. You then
set access rights so that this account can access the Web page. Typically, you give the user
account the same name as the agency.
When temporary employees from the agency connect to the agency's Web server and provide
their certificates, they are mapped to the same account and can access the Web page.
However, they cannot view other pages since the account does not have permissions to
anything else. This saves administrative expense because the agency can now issue
certificates and manage its users without requiring further intervention on your part.
Top of page
Where Mapping Occurs

With IIS in Windows 2000, the certificate mapping can occur in one of two places: IIS or
Active Directory.
IIS

When IIS does the mapping, the certificate is compared to a list of rules that IIS maintains in
its metabase. IIS finds a rule that matches the indicated Windows 2000 account. IIS mapping
is configured for each Web server and is useful if you need very few mappings or a different

mapping on each Web server. Most people will prefer to use Active Directory mapping
because it requires less administration.
Active Directory

In Active Directory mapping, when the IIS server receives a certificate from the user, it
passes it on to Active Directory, which maps it to a Windows 2000 user account. The IIS
server then logs this account on.
Active directory mapping is most useful when the account mappings are the same on all IIS
servers. Administration is simplified because the mapping is done in only one place.
Mapping in Active Directory can happen in one of two ways. The administrator can explicitly
map a certificate to a user's account. This certificate can come from any source--as long as
the root CA for that certificate is trusted for client authentication.
UPN mapping can also be used. A UPN is automatically put into a certificate issued by an
enterprise CA. If a certificate is passed to Active Directory for mapping, it is first examined
for UPN mapping. If UPN mapping is not possible, the mapping set by the administrator is
used.
UPNs are in the form of userid@domain. If the certificate contains a UPN, the domain is
within the hierarchy of the directory, and the CA that issued the certificate is trusted to put
UPNs in the certificate, then the user's account is retrieved from the directory and logged on.
All these conditions must be true before the user's account is retrieved. If any of these
conditions is false, the directory is searched for a mapping set by the administrator.
Top of page
Requesting the User Certificate

For this guide you will need to request a user certificate. If you wish to use UPN mapping,
you should get a certificate from an enterprise CA in your domain. However, for all other
mapping methods, you should use a certificate from a CA that is not in your enterprise. This
ensures that UPN mapping is not occurring when you test the mapping at the end of this
guide. For more details, see the guides entitled Administering Certificate Services and
Certificate Services Web Pages. A brief description is provided below.
You can request a certificate in one of two ways:

Use Internet Explorer to connect to a Web enrollment page. An enrollment page is

provided with Windows 2000 Certificate Services and is installed on the same
computer as the Certificate Service. To use these to request a certificate, connect to
http://servername/CertSrv, and follow the directions. If you are using an enterprise
CA, these pages require authentication, and you must select a template type to request
a valid template. Typically, this will be a user template. You can also use Internet
Explorer to request a certificate form a third-party commercial CA. Trusted root
certificates are included in Windows 2000 for a number of these commercial CAs.

Use the Certificates management snap-in to request a certificate from Microsoft

Certification Authority. These procedures are described next.

To use the Certificates management console to request a certificate

1. To open the Microsoft Management Console (MMC), click Start, click Run, type
mmc in the Open box, and click OK.
2. On the Console menu, click Add/Remove Snap-in. In the dialog box, click the Add
button. In the next dialog box that pops up, click Certificates, and then click Add.
3. Select My user account and click Finish.
4. Click Close to close the Add/Remove Snap-in dialog box and then click OK.
5. In the Certificates console, expand the Certificates node.
6. Right-click the Personal folder, point to All Tasks, and click Request New
Certificate as in Figure 1 below.

Figure 1: MMC with Certificates snap-in

7. The Certificate Request Wizard launches. Click Next.

8. In the Certificate templates list, select User. Click Next.
9. Type a Friendly name and Description into the text boxes. Click Next.
10. Click Finish. A message box appears telling you the certificate request was
successful. Click Install Certificate, and then click OK.
11. To view the newly issued certificate, click the Certificates folder under Personal.
The new certificate is listed in the right pane. Double-click it to view certificate
details.

Exporting the Certificate

Once you have the certificate, you need to export it for use in later steps.
1. Right-click the certificate(s) you want to export.
2. Point to All Tasks on the context menu, and click Export to launch the Certificate
Export Wizard. Click Next.
3. If the certificate that you are exporting has a corresponding private key in the system,
you can choose to export the private key with the certificate.
Note: You will only be able to export to a Personal Information Exchange PKCS#12
file if you want to export the private key.
4. Select the export file format (for this exercise, you can simply accept the default).
Click Next.
5. If the file specified is a Personal Information ExchangePKCS #12 (*.pfx), you will
be prompted for the password. Enter your password. Click Next.
6. Enter the name of the file you want to export. Click Next.
7. Verify the choices you have made in the wizard. Click Finish to export to the file.
Top of page
Installing CA Certificates

If you are using an enterprise CA in your domain, you can skip this section because the root
certificate is trusted by your system.
Windows 2000 has a number of pre-installed CA certificates for various commercial
certification authorities. If you choose to use a commercial CA that is not pre-installed, you
must install the CA root certificate to enable trust of any certificates issued by that CA.
Installation of the CA root certificate may vary depending on the particular CA. This example
shows you how to install the root certificate for the enterprise root certification authority.
Root certificates for Windows 2000 Certification Authority services in the same domain as
the client are installed automatically.
To install a CA certificate obtained from a third party

1. First, create a Certificates management console to manage the certificates for the
computer on which you are working. To open the Microsoft Management Console
(MMC), click Start, click Run, type mmc in the Open box, and click OK.
2. On the Console menu, click Add/Remove Snap-in. In the dialog box, click Add. In
the next dialog box that appears, click Certificates, and then click Add.
3. Click Computer account, then click Next.

4. Click Local computer, then click Finish. Click Close, and then click OK. The
Certificates directory now displays in the left pane of the console.
5. On the Console menu, click Save As. In the File name text box, type Certificates,
and then click Save.
6. In the console, expand the Certificates node. Then expand Trusted Root
Certification Authority.
7. Right-click the Certificates folder, point to All Tasks, and then click Import as in
Figure 2 below.

Figure 2: Import Certificate

8. The Certificate Import Wizard launches. Click Next.

9. Click the Browse button to select the CA certificate you would like to import. After
you've selected the file, click Next.
10. Click the Place all certificates in the following store option. By default, Trusted
Root Certification Authority should show up in the text box as the store to which to
save the imported file. If this doesn't show up by default, click Browse to find the
store. Then, click Next.
11. Read the information in the Completing the Certificate Import Wizard window,
and then click Finish. The CA certificate is now installed. To verify this, scroll
through the list of certificates in the right pane to find the one you have just installed.
Top of page
Preparing IIS for Mapping
Active Directory Mapping

Note: Skip this section if you do not want to use Active Directory mapping.

To configure Active Directory mapping

1. Click Start, point to Programs, point to Administrative Tools, then click Internet
Services Manager. Right-click the server name in which IIS is running (in our
example, HQ-RES-DC-01), and click Properties.
2. On the Internet Information Service tab, click Edit in the Master Properties
section.
3. On the Directory Security tab, check the Enable the Windows directory service
mapper check box. This option tells IIS that when you set a Web site to do mapping,
it should really do Active Directory mapping. If this setting is unchecked, IIS does the
mapping. Click Apply, and then click OK.
Configuring SSL

The next step is to configure a site to use SSL. You must do this for both Active Directory
and IIS mapping.
1. Click Start, point to Programs, point to Administrative Tools, and then click
Internet Services Manager.
2. Expand the domain node. Select Default Web Site, and right-click on it. Click
Properties on the submenu as in Figure 3 below.

Figure 3: IIS Manager

3. The Default Web Site Properties dialog box starts. Click the Directory Security tab.
Notice that the Edit button under Secure communications is unavailable. This is the
case until you request a Web server certificate.
4. Click the Server Certificate button.
5. The Web Server Certificate Wizard starts. Click Next.

6. Select the Create a New certificate option,and click Next.You will see a different
dialog box if IIS already has a certificate.
7. Select the Send the request immediately to an online certification authority
option. (This assumes that you have an enterprise CA in your domain that is
configured to issue Web certificates. Click Next.
8. In the Name and Security Settings dialog box, accept the default options. Click
Next.
9. On the next page, enter your information, and click Next.
10. Type your server name in the Common name text box. It can be either the DNS
name, the NetBIOS name, or the word LOCALHOST. Enter your choice, and click
Next.
11. On the next page, enter your information, and click Next.
12. If you have an enterprise CA in your domain from which you are allowed to request
Web server certificates, you will see it listed here. (If there is no CA, if the CA is not
configured to issue Web server certificates, or if you do not have permission to
request a Web server certificate, this list will be empty. You must have a CA available
to complete this section.) Select the CA you want to use, and click Next.
13. The Certificate Request Submission page comes up. Click Next.
14. Click Finish. The server now has a server certificate.
15. You will notice Edit under Secure communication is now enabled (see Figure 4
below); click Edit.

Figure 4: Secure Communications Dialog

16. Use the Secure communications dialog box, as in Figure 5 below, to configure the
site to do SSL and account mapping. You must check the Enable client certificate
mapping for both IIS and Active Directory mapping. Select either Accept client
certificates or Ignore client certificates. The Accept client certificates setting
requires negotiation of client certificate authentication with the browser. If it fails, it
falls back to one of the standard authentication protocols. If you select Ignore client
certificates, you must also check the Require secure channel (SSL) check box. No
fallback is allowed to another authentication method. Requiring secure channel means
that the Web site will not be viewable through HTTP, only through HTTPS. You
should not check the Enable certificate trust list for this guide. Click OK. Click
Apply, and then click OK.

Figure 5: Configure Site.

Mapping User Accounts

If you want to do IIS mapping, first turn off Active Directory mapping. IIS is now ready to do
certificate mapping.
To turn off Active Directory mapping
1. On the Start menu, point to Programs, point to Administrative Tools, then click
Internet Services Manager. Right-click the server name in which IIS is running (in
our example, HQ-RES-DC-01), and click Properties.
2. On the Internet Information Service tab, click Edit in the Master Properties
section.
3. On the Directory Security tab, clear the Enable the Windows directory service
mapper check box. This option tells IIS to do the mapping. Click Apply and then
click OK.

Top of page
One-to-One Mapping

This section covers one-to-one mapping, first in the Active Directory and then with IIS.
Using the Active Directory for One-to-One Mapping

If you have set IIS to do directory mapping by following the instructions above, IIS
automatically does UPN mapping for certificates from a trusted enterprise CA. You can
proceed directly to the section, Testing the Mapping below to see UPN mapping. The default
administrator account does not have a UPN and does not map. You must create a new account
and use its certificate to see UPN mapping.
To configure Active Directory one-to-one mapping
1. Click Start, click Programs, click Administrative Tools, and click Active Directory
Users and Computers.
2. Expand the domain name node (HQ-RES-DC-01), and click the Users folder. In the
right pane, right-click the Administrator account and click Name Mappings.
3. On the X.509 Certificates tab, click the Add button. Select the user certificate from
the .cer file saved in the Exporting a certificate section.
4. The Use Issuer for alternate security identity will be selected and appear gray by
default because you need to use this for both one-to-one mapping and many-to-one
mapping. Select the Use Subject for alternate security identity option to do one-toone mapping. By unchecking this option, you will be doing many-to-one mapping.
Click OK.
5. Go to the section, Testing the Mapping, to verify that this works.
Using IIS for One-to-One Mapping

Instead of using Active Directory as in the previous section, you can use IIS to do all the
mappings. To configure IIS one-to-one mapping, first ensure that Active Directory mapping
is turned off (return to the master property page and unchecking Active Directory mapping).
To turn off Active Directory mapping
1. On the Start menu, point to Programs, point to Administrative Tools, then click
Internet Services Manager. Right-click the server name in which IIS is running (in
our example, HQ-RES-DC-01), and click Properties.
2. On the Internet Information Service tab, click the Edit button in the Master
Properties section.
3. On the Directory Security tab, clear the Enable the Windows directory service
mapper check box. This option tells IIS to do the mapping. Click Apply, and then
click OK.

To configure IIS one-to-one mapping

1. Click Start, click Programs, point to Administrative Tools, and then click Internet
Services Manager.
2. Expand the computer name node (in our example, HQ-RES-DC-01). Right-click the
Default Web Site folder, and click Properties on the submenu.
3. Click the Directory Security tab on the Default Web Site Properties dialog box.
4. Click Edit in the Secure communications section.
5. In the Secure Communications dialog box, verify that the Enable client certificate
mapping option is selected, and click Edit.
6. On the Account Mappings page, click the 1-to-1 tab, and click Add.
7. Select the user's certificate from the list, and click Open. For IIS, this certificate must
be base64-encoded and cannot be a binary certificate. Although Windows 2000 works
with both types, IIS can only process base64-encoded files,.

Figure 6: Map to Account dialog

8. The Map to Account dialog opens. Click Browse to select the Administrator
account (see Figure 6 above). Enter the password and click OK.
9. Click Apply and/or click OK, as appropriate, in the remaining dialog boxes to save
the information and to close them.
IIS one-to-one mapping is now configured. You can go to the section Testing the Mapping at
the end of this paper to see this mapping work.
Top of page
Many-To-One Mapping

In the previous two sections, you used one-to-one mapping. You will now configure many-toone mapping in which many users (certificates) are mapped to a single Windows 2000 user
account.

Using the Active Directory for Many-to-One Mapping

Remember to enable Active Directory mapping if you disabled it in the previous section:
1. Click Start, click Programs, click Administrative Tools, and click Active Directory
Users and Computers.
2. Expand the domain name node (in our example, HQ-RES-DC-01), and click the
Users folder. In the right pane, right-click the Administrator account, and click
Name Mappings on the submenu.
3. On the X.509 Certificates tab, click Add.
4. Click the certificate you'd like to add, and click Open.
5. Clear the Use Subject for alternate security identity check box, and click OK.
6. A message tells you that you won't be able to use the subject for alternate security
identity. Click Yes.
7. Your new mapping information now displays. Click Apply, and then click OK.
You have now configured Active Directory to map all certificates from the issuing CA to the
Administrator account.
Using IIS for Many-to-One Mapping

To configure IIS many-to-one mapping, you must first turn Active Directory mapping off.
To turn off directory mapping
1. Open the Active Directory Users and Computers snap-in.
2. Expand the domain node (in our example, HQ-RES-DC-01), and click Users. In the
right pane, right-click Administrators, and click Name Mappings on the submenu.
3. On the X.509 Certificates tab, click Remove. Click Apply, and then click OK.
4. Click Start, point to Programs, point to Administrative Tools, then click Internet
Services Manager. Right-click the server name in which IIS is running (in our
example, HQ-RES-DC-01) and click Properties.
5. On the Internet Information Service tab, click the Edit button in the Master
Properties section.
6. On the Directory Security tab, clear the Enable the Windows directory service
mapper check box. This tells IIS to do the mapping. Click Apply, and then click OK.
To configure IIS many-to-one mapping
1. In the Internet Services Manager snap-in, expand the computer name node. Then
right-click Default Web Site, and click Properties on the submenu.

2. Click the Directory Security tab, and in the Secure Communications section, click
Edit.
3. In the Secure Communications dialog box, select the Enable client certificate
mapping option, and then click the Edit button.
4. In the Account Mappings dialog box, click the Many-to-1 tab. Click Add.
5. Enter a description if you wish. Click Next.
6. In the Rules dialog box, click New.
7. You can enter as many fields as you wish to this rule. However, for this guide, use
only one. Specify that the organization (O) in the Issuer name is equal to Operations
as in Figure 7 below. This means that all certificates issued to this organization will be
mapped. Enter this information into your dialog box. Replace the Criteria with the
value in your certificate. Click OK.

Figure 7: Edit Rule

8. Click Next.
9. Click the Browse button to select the administrator's account. Click Finish and close
all dialog boxes.
IIS is now configured to do many-to-one mapping. You can go to the Testing the Mapping
section to see this in action.
Top of page
Testing the Mapping

This section allows you to test the mappings that you have made.
Setting Up a Web Page

Typically, all the default Web pages installed with Windows 2000 are set for any user to
access the pages. To see certificate mapping in action, you must create a page that can be
accessed only if mapping is occurring. The following procedure creates a file and configures

the access rights so that only a mapped user can access it. This file is used to verify that
mapping is occurring.
Creating a Restricted File
First, create a file that can only be accessed by the Administrator account. This can by any
type of file: .htm, .asp, .gif, .jpeg, .doc, and so on. For this test, use a .gif file.
1. Click Start, click Programs, click Accessories, and click Windows Explorer.
2. Navigate to the Inetpub\Wwwroot directory.
3. Copy the file win2000.gif and rename it Admin.gif.
4. Right-click the Admin.gif file, and select Properties.
5. Click the Security tab.
6. Uncheck the Allow inheritable permissions from parent to propogate to this
object option at the bottom of the dialog box.
7. Remove all users and groups from the list by selecting each group and clicking
Remove.
8. Addthe Administrator account back by clicking Add and selecting Administrators.
Select Full control.
9. Click Apply, and click OK.
This file can now be accessed by the Administrator account only.
Turning Off Authentication
When IIS accesses a file, it impersonates a user so that the system uses the authenticated
user's access rights. You need to ensure that the authentication happened using certificate
mapping, rather than some other method.
To configure IIS so that no other form of authentication is possible for this file
1. Click Start, click Programs, point to Administrative Tools, and then click Internet
Services Manager.
2. Click the Default Web Site folder.
3. In the right pane, right-click on the file Admin.gif.
4. Click Properties.
5. Click the File Security tab.
6. Click Edit under Anonymous access and authentication control.

7. Uncheck all options). (You can leave Anonymous access selected if you want.)
Return to Internet Explorer, and try to access the page. If you succeed, the user has been
authenticated using the mapping.
Connecting a Web Page

The next step is to connect to this file and verify that the mapping is working.
To connect to the file
1. Log on as a user whose account has been mapped to a certificate.
2. From the Start menu, select Run and type https:// servername /admin.gif where
servername is the name of the Web server. If you are testing this on the Web server,
use LOCALHOST instead of the server name. Click OK.
Internet Explorer may display a warning that you are about to use SSL. Click OK.
3. You will receive a Security Alert if you used LOCALHOST to connect. Internet
Explorer is warning you that the server certificate does not match the name that you
typed. Click Yes to continue.
4. You should next see a selection of certificates. Select the certificate that you used in
the mapping, and click OK. You should be doing this test from the computer on which
you installed the certificate originally. Each certificate has a corresponding private
key that is stored only on the computer on which you made the original user
certificate request.
If the mapping worked you should see the .gif file.
If you see an error, there are a number of possible reasons:

An access denied message indicates that you are successfully authenticating but that
you do not have permissions to access the file. Check the permission on the file to see
which account your certificate maps to.
A certificate-revoked message usually indicates that the certificate has been revoked
or that IIS was unable to retrieve a certificate revocation list (CRL). You may need to
install the CRL.
A message that the certificate is not trusted or is invalid usually means you have not
installed the roots into the computer's trusted root store on the Web server. A common
mistake is to install the roots into the user's trusted

Optimizing Active Directory Topology for

Group Policy
3 out of 4 rated this helpful - Rate this topic
By Roger Jennings

This is Chapter 2 of Admin 911: Windows 2000 Group Policy, published by

Osborne/McGraw-Hill. For more information about this book and to order, please go to
http://www.osborne.com .
The design of your organization's AD domain structure is your most important task as a
Windows 2000 system admin. A substantial part of Microsoft's Windows 2000 Server
documentation on Microsoft's Web site, the online help, and the Windows 2000 Server
Resource Kit is devoted to optimizing your AD topology. Microsoft's design methodology
takes into account geographical, organizational, political, networking, and Internet namespace
constraints but devotes relatively little attention to the influence of AD topology on the
effectiveness of Group Policy implementation.
On This Page

Adapting Group Policy Implementation to Migration Strategy

Implementing the Internal Domain Structure
Adapting Group Policy Implementation to Migration Strategy

Your Group Policy implementation strategy and, to a lesser degree, your final AD topology
depends on your Windows 2000 migration strategy. The majorityprobably 90 percent or
moreof current Windows 2000 Server installations are upgrades to existing Windows NT
networks. Microsoft's success in marketing Windows NT as application, file, and print
servers means that upgrades probably will predominate over new Windows 2000 network
installations through 2002 or later. A few courageous organizations began deploying
Windows 2000 Server on an enterprisewide basis with release candidates. Most firms aren't
willing to play the pilgrim role, so they delay migration to dramatically altered networking
operating systems for a year or two after the initial release. The relatively slow initial
acceptance of Windows NT Server 3.x followed by a very rapid increase of version 4.0 sales
(and a corresponding decline in NetWare's market share) is indicative of the conservatism of
IT departments of large organizations.
Note Microsoft's release in July 2000 of Service Pack 1 for Windows 2000 is indicative of
the power of the "wait for the first service pack" dictum of respected industry analysts, such
as GartnerGroup. It remains to be seen if fast-tracking SPs overcome IT departments' "if it
ain't broke, don't fix it" policy for their existing Windows NT networks.
In the unlikely event that you're creating a Windows 2000 domain structure from scratch, for
instance, for a new firm with no existing network (other than workgroup file and printer

sharing), skip to the "Designing the Internal Domain Structure" section. If you've moved or
intend to move NetWare users, groups, OUs, and other containers from a NetWare domain,
start at the "Domain Restructure or Consolidation" section. For more information on
migration strategies for NetWare, download Microsoft's NetWare to Windows 2000 Server
Migration Planning Guide from
http://www.microsoft.com/windows2000/techinfo/planning/incremental/netmigrate.asp .
Planning Client Migration to CCM

In contrast to the slow initial uptake of Windows 2000 Server licenses for production
networks, Windows 2000 Professional is gaining corporate converts at a fairly rapid rate.
Early adopters of Windows 2000 Professional fall into the following three migration
categories:

Installation on newly purchased PCs only The average three-year useful life span
for existing desktop and laptop workstations results in a relatively long transition to a
fully managed Windows 2000 environment. Up to two-thirds of the new clients might
connect to Windows NT networks when adoption of Windows 2000 Server is delayed.
Clean installs on new and some existing PCs Most business PCs purchased since
early 1999 have the hardware horsepower to run Professional. This approach provides
considerably faster migration to CCM-enabled clients, but doesn't solve the interim
Windows NT networking problem. Microsoft recommends de novo installation where
feasible and so does this book. If you've convinced your users to maintain all their
local files under My Documents and, better yet, have desktop users storing My
Documents in their home folder on a file server, clean installs on existing PCs are
straightforward. Otherwise, backing up and wiping users' local disks, followed by a
partial restore of user files, is a costly and chancy process.
Clean installs on new PCs and upgrades to existing PCs This process usually
results in a heterogeneous mix of CCM-enabled clients and unmanageable PCs beset
with application and local file system anarchy. If you can avoid upgrading Windows
NT and 9x clients, do so. The move to Windows 2000 Professional is the ideal time to
convince users accustomed to desktop and laptop autonomy (or anarchy) that
centrally administered CCM will make their lives easier and more productive. It's
virtually impossible to fully CCM-enable upgraded PCs that haven't been subject to a
tightly controlled application configuration by system policies, such as Run Only
Allowed Windows Applications.
Tip Use of the term personal computer within a corporate environment leads users to
the mistaken belief that the computers they use and the files they store are their
personal property. It's not uncommon to find local disk drives or file servers filled
with MP3 files downloaded from the Internet. Placing new restrictions on client PCs
leads to user bickering and, in some cases, revolts reminiscent of those that occur
when replacing Macintoshes with Wintel machines. Before you begin your Windows
2000 migration, make sure that executive management understands that CCM is
necessary to achieve any return on the upgrade investment. You also need topmanagement backing to alter users' understanding of who owns and is responsible for
the configuration of and content stored on the firm's computers. Implementing CCM
offers a once-in-a-decade opportunity to minimize potential legal liability for
unauthorized or improper use of client computers.

A typical Windows NT network has between 25 and 100 clients per server, so the decisions
you make for migrating clients to Windows 2000 have a more profound effect on total
network management costs than decisions about server upgrades. Synchronizing the timing of
client and server upgrades, however, also is an important factor in gaining the maximum
return from your investment in deploying Group Policy.
Note The term users in this chapter applies to ordinary and power users, not admins, help
desk technicians, and software developers.
Choosing the Server Migration Approach

There are two approaches to migrating from a Windows NT to 2000 network: in-place
upgrade and domain restructure, which also is called domain consolidation. The choice you
make between these two approaches, or how you combine them, has a major influence on the
effectiveness of Group Policy deployment.
The first rule of AD topology is "simpler is better." A single domain for internal network
users and computers in one tree of a forest is the optimal design, if your DNS namespace
requirements permit. If not, consider changing your internal DNS namespace. Windows
2000's hierarchical OUs, and the ability to delegate administrative responsibility for OUs,
takes the place of separate Windows NT domains created to distribute managerial tasks.
If your Web servers run under one or more ICANN-assigned (public) domain names, put
them into separate domain trees that don't include the domain used for internal user and
computer accounts. The "simpler is better" rule applies primarily to internal, not external,
networks, where DNS namespaces and IP addresses are under your control, not that of
ICANN or your ISP.
Note An exception to the single-domain rule might be justified if you have a geographically
disperse organization with several thousand clients and a large number of Security Groups
whose membership changes frequently. In this case, intersite AD replication traffic over slow
(128 kbps or less) WAN links can consume a significant part of available bandwidth.
In-Place Windows NT Server Upgrade

Microsoft calls in-place upgrade the "easiest, least-risky route" to Windows 2000 networking,
because you retain the existing domain structure, its user and computer accounts, and all
security groups. Home folders, logon scripts, and other files (hopefully) aren't affected by the
upgrade. Least-risk endeavors, however, traditionally return low dividends, and in-place
upgrades are no exception. Your Windows 2000 domain structure mirrors that of the
upgraded Windows NT domains, including any resource domains you've established. If your
clients have fixed IP addresses, which was common in early Windows NT networks, your
new Windows 2000 network inherits them. You're also stuck, at least temporarily, with the
Windows NT DNS namespaces you've implemented, if any.
It's a common practice to conduct incremental in-place upgrades in the following stages:
1. Upgrade the account domain PDC to a DC. The first PDC you upgrade becomes the
initial root domain DC, a Global Catalog (GC) server, and the PDC emulator for
downlevel clients. As with a PDC, all additions and changes to user accounts (and

computer accounts not in a resource domain) occur on the PDC emulator and replicate
to Windows NT BDCs. Trusts with other Windows NT domains remain nontransitive.
2. Designate subnets connected by WAN links to the PDC emulator's subnet as Windows
2000 sites in preparation for upgrading remote account BDCs and resource domains.
3. Upgrade account domain BDCs to Windows 2000 DCs and place them in the
appropriate site. Each site needs at least one DC for each domain the site contains;
two DCs per domain per site are necessary for redundancy. Each site must have at
least one DC designated as a GC server.
Tip It's a good practice to designate all DCs as GCs, except the DC that handles the
Infrastructure Flexible Single Master Operations (FSMO) role. Doing this improves
logon redundancy for Windows 2000 clients at each site where you install multiple
DCs, and it doesn't have a significant effect on intersite replication traffic.
4. Upgrade each resource domain PDC to a DC and assign the DC to its site; then
upgrade resource domain BDCs.
5. When all PDCs and BDCs are upgraded to Windows 2000, convert the mixed-mode
domains to native mode, which lets you nest Global groups and take advantage of
Universal groups, plus a few other native-mode-only features.
Tip In each of the preceding steps, a full, known-good current backup is critical, and
two backups are better than one. In-place upgrades are a one-way process. Although
upgrade failures are rare, they usually are fatal, especially if the failure occurs during
promotion of the server to a DC. Protect against extended domain downtime by
adding a temporary BDC, synchronizing it with the PDC just before the upgrade, and
removing it from the network. If the PDC upgrade fails, you can promote the BDC to
a PDC and reconnect it to the network.
In-place upgrades of account and resource domains dump all user accounts and security
groups in the Users container and computer accounts in the Computers container. Security Ids
(SIDs) of groups and users don't change during the upgrade. Neither User nor Computers are
OUs, so it's up to you to move the individual user and computer accounts into the OU
hierarchy you create for classification and delegation of management. If computer accounts
are in an upgraded resource domain, users and their computers remain in different domains.
This isn't a problem for system policy, which depends only on the user account, but it does
complicate application of Group Policy, because Computer Configuration comes from the
upgraded resource domain and User Configuration from the account domain. You can create
in the resource domain a cross-domain link to the Default Domain Policy GPO in the user
domain, but doing so causes a significant slowdown of user logons.
Note What does cause a problem with system policy is changing the group membership of a
user subject to group-based system policy, which includes Windows 2000 clients whose user
accounts are in Windows NT domains. If the user moves to a group with a different system
policy (or no policy), the Registry of the user's computer is tattooed with the previous group's
settings. Removing the spurious settings requires manual editing of the client's Registry.
Once you've converted the domains to native mode, you can consolidate the resource
domains with the account domain by using Microsoft's Active Directory Migration Tool
(ADMT) or a third-party Windows 2000 migration utility. Moving the computer accounts

from resource domains into account domain OUs eliminates the need for individual domain
GPOs or cross-domain GPO links. After the move, you decommission the upgraded resource
domain by demoting the DCs to member servers and placing them in the account domain.
Note Microsoft describes the Computers container as the "Default container for upgraded
computer accounts." In fact, it's the default container for all computer accounts, upgraded or
not, unless you use RIS, RIPrep, or SysPrep to install Windows 2000 Professional on client
PCs. Only automated installation lets you create Windows 2000 computer accounts in
specified OUs. For reasons unknown, Microsoft didn't include a text box for a computer
account OU in the installation dialogs. Unless you pre-create user accounts in OU(s), either
individually or by scripts, manually added users fall into the Users container.
Domain Restructure or Consolidation

The alternative to in-place upgrade is to design your own domain and OU structure and use
ADMT to import user and computer accounts into the structure. Domain restructure by
cloning Windows NT directory objects in AD, called interforest migration, has the following
advantages over in-place upgrade:

You don't inherit the convoluted domain structure forced upon you by Windows NT's
flat domain namespace.
You can create and test your Group Policy and IntelliMirror implementations before
you migrate users and computers to the new domain. This is an especially important
feature of domain restructure. Altering desktop configuration and lockdown policies
and adding or changing other features after new Windows 2000 users have joined the
domain results in user dissatisfaction and a dramatic increase in help desk support
cost.

You can import user accounts directly into OUs by their group membership. This
ability is contingent on your having a set of Windows NT security groups that
correspond to your OUs for user accounts.

You also can import computer accounts into OUs to selectively apply Computer
Configuration policy, including security policies. Windows NT doesn't support
security groups for computer accounts, but AD does. The Computer object is a
subclass of the User object in Windows 2000, so you can treat Computer objects
similarly to User objects.
Note "Underclass of the User object" is a more apt description of the Computer
object. Although you can assign individually named computer accounts to a Security
Group from the Member Of page of the ComputerNameProperties dialog, you can't
select sorted or filtered computer accounts in Active Directory Users and Computers'
pane for the Computers container and use the Adds the Selected Objects to the Group
You Specify button to establish group membership. The button is disabled, and there's
no Add Members to a Group context menu choice when you select the Computers
container. If you try to add all computer accounts to a group by selecting the
Computers container in the tree-view pane, the operation fails. Chapter 3 deals with
this issue.

You can import user, computer, and service accounts, plus security groups from
multiple Windows NT domains, to perform domain consolidation, which also is called
domain coalescence or collapse. For instance, you can move computer accounts from
resource domains into OUs of the account domain.
The final selling point of domain restructure is that cloning user and computer
accounts and security groups creates duplicates in the Windows 2000 domain that
retain their Windows NT identities. If users have difficulty logging on or have other
problems with the Windows 2000 domain, they can simply log on to their old
Windows NT domain. Moving the computer account back to the original domain
requires opening the computer's System Properties dialog and clicking properties to
change domain membership in the Identification Changes dialog. In this case,
however, the user gets a new local profile that doesn't contain settings for Internet
Explorer, Outlook, or other messaging clients. Loss of long-established configuration
settings is a serious inconvenience for most users.
Tip The ability to move users and computers to and from the new domain is
especially important when pilot-testing Group Policy with a small group of typical
users of a particular category, such as Knowledge Worker or Mobile Worker. If your
policies are too restrictive or cause users problems, you can return the user, computer,
or both accounts to the original Windows NT domain until you fix the problems.

When you create a new User or Group object in AD (or in the Windows NT directory), it gets
a new SID. The cloned user accounts, however, retain access to all resources in the Windows
NT domain, and you can assign users and groups additional permissions for resources in new
Windows 2000 domains. The attribute responsible for this magic is SIDHistory, which holds
a copy of the SID of the user and groups from the Windows NT (source) domain. When users
log on to a native-mode domain, the access token contains both the Windows 2000 SIDs and
those in the SIDHistory attribute of the user's account.
The Windows 2000 domain must run in native mode to support SIDHistory.
Code Blue To clone accounts from a trusted Windows NT domain to a native-mode Windows
2000 domain that was upgraded from a Windows NT PDC, you must re-create the DCs' trusts
with other Windows NT source domains before using ADMT to migrate user accounts.
Windows 2000 upgraded DCs have downlevel trusts with other Windows NT domains;
downlevel trusts don't support SIDHistory. Use the DC's Active Directory Domains and
Trusts tool to delete and re-create the trusts with other Windows NT domains before running
ADMT. For more information on this issue, refer to Microsoft Knowledge Base article
256250, "ClonePrincipal and ADMT Require Uplevel Trust to Migrate Objects Between
Windows 2000 Domains."
Note Appendix C describes how to use ADMT for interforest domain migration. Microsoft
offers an 11-chapter "Domain Migration Cookbook" that you can download from
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/cookbook/cookintr.
mspx . The "Cookbook" uses ADMT for domain migration and restructuring.
Interforest domain migration isn't limited to cloning Windows NT directory objects. You also
can move AD objects between trees in two AD forests, but the move is subject to incomplete
object migration if the schemas of the forests differ. Intraforest migration permits you to
move objects between domains in the same forest of domain trees. It's the latter capability

that lets you restructure multiple Windows NT domains you upgrade in place, assuming you
adopted the standard practice of upgrading all domains into a single forest.
Domain Restructure Issues

Following are the primary problems you're likely to encounter when consolidating multiple
domains with a large number of clients:

Duplicate user logon IDs It's possible to duplicate account names in different
domains, because the DOMAINNAME\LogonID combination identifies the specific
account. User logon IDs within a domain, however, must be unique. ADMT offers an
option to rename duplicate accounts by adding a prefix or suffix (see Figure C-15 of
Appendix C). You can apply an LDAP filter in Active Directory Users and Computers
to search for the prefix or suffix to find which logon IDs are duplicates.
Identification of user accounts for classification by OU If security groups don't
mirror OU membership, you need a method of identifying which users belong in a
particular OU. Few admins take advantage of Windows NT's Description property of
user accounts, and those who do aren't likely to have had OU membership in mind
when adding the Description value. Consider adding a Description value with the OU
name at the beginning or end of the field. LDAP filters have Begins With (*string)
and Ends With (string*) conditions, but not an "Includes" (*string*) condition. This
omission is the subject of many complaints that have gone unanswered by Microsoft.
Identification of computer accounts for OU classification The situation here is
worse than for user accounts. Windows NT has a Description property for Computer
objects, but AD doesn't. Even if you've added a description that can be used to classify
computers, it doesn't propagate to the AD Computer object's Description attribute.
This is another unsolved mystery of object migration from Windows NT to 2000.
Create a worksheet with columns for NetBIOS names and the names of their target
OUs.
Note Duplicate computer account names should never occur, because computer
NetBIOS names must be unique within the entire network.

The Windows 2000 Resource Kit includes a Deployment Scenarios foldout map that
illustrates implementation of a child or grandchild domain at each site and use of a sitedomain-function-number code (SEA-RK-DC-01, for example) for naming servers. This
naming convention is quite satisfactory for servers, but isn't suitable for clients. A better
approach for naming new clients is to use a prefix to uniquely identify the OU to which the
computer belongs, followed by a serial number and, optionally, a suffix to identify the site,
type of computer (such as desktop or laptop), or both. The examples in this book use three
prefixes, FAC, NFS, and STU, to identify faculty member, nonfaculty staff, and student
computers, respectively. A nine-digit ID number (the Employee ID of the user to which the
computer is assigned) follows the prefix. When you run the Admin911: GroupPol application
under Windows 2000, the program associates computer accounts with user accounts. The
only location in which the association appears as ComputerName (UserPrincipalName) is in
Active Directory Users and Computers' Select Users, Contacts, or Computers dialog (see
Figure 2-1).

Figure 2-1 Creating Windows 2000 computer accounts with the

GroupPol application associates computer accounts with the User
Principal Name (UPN). The disabled computer accounts (having a
superimposed "X") represent Windows 9x computers that will be
upgraded to Windows 2000 Professional.
Application of Group or System Policy to Windows 2000 Clients

If you install Windows 2000 Professional on clients in a Windows NT domain that

implements system policies, the system policies are applied to Registry keys other than the
protected keys that hold values set by Group Policy. The Registry tattooing occurs the first
time the user logs on. Registry settings applied to Windows NT and 9x clients that you
upgrade to Windows 2000 Professional remain in place. In either case, you're likely to find it
difficult or impossible to reset the system policies by explicitly disabling them with the
System Policy Editor. If you can't perform a full system policy reset from Poledit.exe, you
must manually correct the errant Registry settings.
Tip You can avoid tattooing the Registry of new Windows 2000 clients by installing the
computers and their user accounts in a new Windows 2000 domain, rather than the
production Windows NT domain. To accomplish this, you use ADMT to clone Windows NT
groups in the new domain, but don't add existing Windows NT and 9 x user or Windows NT
computer accounts. Users gain access to resources in the Windows NT domain through the
SIDHistory of the migrated security groups to which you add the user accounts. Be sure to
establish Group Policy settings that emulate the existing system policy before you add
production user accounts.
If you can't avoid having Windows 2000 user, computer, or both accounts managed by a
Windows NT domain that implements system policy, or the clients already have their
Registries tattooed, here's what you can expect:

If both computer and user accounts are managed by a Windows NT domain, Local
Security Policy is followed by computer and user system policy when the user logs
on.
If only the computer account is managed by the Windows NT domain, Local Security
Policy is followed by computer system policy and the User Configuration class of
Group Policy when the user logs on.
If only the user account is managed by the Windows NT domain, Local Security
Policy is followed by the Computer Configuration class of Group Policy and User
System Policy when the user logs on.

The upshot of the preceding list is that Group Policy prevails over system policy when the
Registry.pol file for computers or users is accessible to a Windows 2000 client.
Top of page
Implementing the Internal Domain Structure

Using a single domain to hold all internal user and computer accounts, as mentioned earlier in
the chapter, simplifies life for system and network admins. It's far easier to alter users' and
computers' OU membership with the Move menu choice than to move these objects between
domains with ADMT or another migration tool. The ability to apply specific policies to OUs
is critical to client management in a single domain. The option to delegate management of
client computer and user accounts to individuals who aren't members of the all-powerful
Domain Admins group relieves the workload of network admins.
Tip In several documents, Microsoft suggests using multiple domains if domains require
different security policies. A domain can have only one set of Account Policies, but other
security policies can differ. Placing computer accounts in OUs lets you easily apply more
stringent security settings or other Computer Management policies to particular sets of
computers. The default Domain Controllers OU, into which Dcpromo.exe automatically
places the computer accounts, is an example of applying security policies (in the Default
Domain Controllers Policy) to computer accounts in an OU. You also can apply less stringent
policies by blocking inheritance from the Default Domain Policy and applying a new set of
security-related policies. Blocking Group Policy inheritance, however, isn't a recommended
practice.
The pragmatic approach to AD domain design is to start with a single domain for internal
users and computers and then determinepreferably in productionwhether it meets the
functional requirements and performance standards of your organization. If you're worried
about DC replication traffic between sites, you can determine the extent of potential WAN
bandwidth problems only after you've achieved a steady-state production environment. The
compression of intersite traffic is very efficient and, after you've added the bulk of your users
and computers to the domain, quickly tapers off. You can use Network Monitor or a network
sniffer to determine the percentage of intersite bandwidth consumed by AD and Group Policy
change replication.
Don't let the number of physical sites interconnected by WANs influence your domain design.
Windows 2000's Knowledge Consistency Checker (KCC) uses a very sophisticated least-cost
algorithm to optimize the routing of intersite traffic between sites, but the KCC bogs down

with a large number of sites and DCs. If you're considering a multiple-domain model, bear in
mind that each site requires a minimum of one DCpreferably two or moreper domain to
enable local logon to each domain. Increasing the number of domains can lead to a dramatic
increase in the total number of servers in the network. If you have a very complex
configuration with many DCs, you might find it necessary to configure your replication
topology manually.
An Example of Single-Domain Topology

The ability to classify users and computers within a hierarchy of OUs is the primary feature
that distinguishes Windows 2000 domains from those of Windows NT. OUs make singledomain structures feasible, even for very large organizations. In most cases, you base the
upper levels of the OU hierarchy on the organizational chart for the enterprise, rather than
geographic location. Classification of user accounts by region is better accommodated at the
lowest OU level, but grouping computer accounts by physical location lets you delegate
computer management and help desk assignments on a per-site basis. The complexity and
size of your organization is the primary determinant of the depth of the OU hierarchy. One of
your OU design goals should be to limit OU membership to a manageable set of user or
computer accounts; a few hundred accounts per OU is a good target.
Tip Active Directory Users and Computers sets a default 2,000-object limit for the right
pane's list. To increase the number of viewable objects, you can choose View | Filter Options
to open the Filter Options dialog. Type the maximum number of objects in the OU with the
largest membership in the Maximum Number of Items Displayed per Folder text box.
Browsing a large number of AD objects, however, consumes a substantial amount of server
resources and, when conducted from a client, generates a large amount of network traffic.
Use filters to generate LDAP queries that reduce the number of objects returned to a
manageable value, such as 50 or fewer, to avoid swamping DCs with browse operations.
Most of the examples in this book use domains populated with AD objects by running the
GroupPol application under Windows 2000. By default, GroupPol generates a single-domain
(oakmont.edu) structure for Oakmont University, a fictional four-year institution in the
Southwest. Oakmont U has 2,275 employees, of whom 1,448 are faculty members, and
25,344 full- and part-time students. If you don't have an existing test domain with numbers of
user and computer accounts sufficient to emulate your anticipated production environment,
you can use GroupPol to quickly create more than 27,500 user accounts and, optionally, the
same number of computer accounts. Working with a large number of AD objects
demonstrates the capabilities and pitfalls of Windows 2000's initial coterie of AD
management tools.
Oakmont U classifies employees first as faculty members and nonfaculty staff and then by
department, such as Anthropology and Information Technology. Students have their own toplevel OU and are further classified by academic yearfreshmen, sophomores, juniors, and
seniors. Thus, employees and students both require a two-level OU structure. GroupPol adds
optional computer accounts for employees and students in a Computers OU under each firstlevel OU. The program also installs 50 Computer Science laboratory computer accounts
under the Lab Computers OU. Lab computers fall in the Public Computing Environment
(PCE) category of the Microsoft Group Policy Scenarios discussed in Chapter 1. Figure 2-2
illustrates the structure of oakleaf.edu's three first-level OUs and their second-level OU
members. Figure 2-3 shows Active Directory Users and Computers displaying the Non-

Faculty Staff OUs and 10 of the 13 Security Groups in the top-level OU. Putting Security
Groups in related OUs simplifies group management.
Note Leicester University ( http://www.leicester.ac.uk/ ) is an example of a very large
organization (8,500 full-time students) that has implemented Windows 2000 with a single
domain having multiple-level, nested OUs for organizing accounts. You can read an interview
with Alistair Loew-Norris that describes Leicester University's Windows 2000 deployment at
http://www.microsoft.com/windows2000/professional/evaluation/casestudies/ . The
resemblance between the oakleaf.edu and le.ac.uk domain architecture is purely coincidental.
Loew-Norris spearheaded Leicester's early Windows 2000 migration, which began during the
beta-testing stage.

Figure 2-2 The oakleaf.edu domain example has a two-level OU

hierarchy for classifying employees by department and students by
academic year.

Figure 2-3 The Non-Faculty Staff OU contains second-level departmental

OUs and Security Groups for staff members.

You use Security Group, not OU, membership to filter application of specific GPOs, as well
as to control access to domain resources, including file shares, printers, scanners, CD burners,
and the like. For example, faculty membership in five Security Groups (Deans, Chairpersons,
Professors, Lecturers, and Teaching Assistants) is based on academic pecking order. Figure 24 illustrates group membership of a teaching assistant in the Anthropology department. If you
were to use third-level OUs to classify faculty members by title, you'd end up with four subOUs for each of 14 academic departments, or a total of 71 OUs to manage. Of these OUs, 56
would require links to GPOs having policies suited to academic rank. Simplifying OU and
GPO structures by applying Security Group filtering is the primary subject of Chapter 3.

Figure 2-4 Oakmonts U's faculty users are members of four Global
groups, two of which reflect OU membership. The rank-based group
(Teaching Assistants in this example) enables precise filtering of OUs by
the users' authority levels.
Delegating Management of OUs

By default only Enterprise and Domain Admins and the System account have Full Control
privileges for OUs. Local Administrators of DCs have Read, Write, and Create Child Objects
permissions, but can't delete sub-OUs. Authenticated Users have only Read permission. After
you've added user accounts, you can delegate management of the OU to an individual user or
group with the Delegation of Control Wizard. To give the Wizard a test run, using
oakleaf.edu's Anthropology OU as an example, do this:
1. Right-click the OU in the tree-view pane and choose Delegate Control to open the
Wizard. Click Next to bypass the Welcome dialog.
2. In the Users or Groups dialog, click Add to open the Select Users, Computers, or
Groups dialog.
Note One incentive for the creation of multiple domains is the inane behavior of the
Select Users, Computers, or Groups dialog. The dialog's Name list includes all
security groups, and every member of the Domain Users andDomain Computers
groups. Including computer accounts in the list more than doubles the number of
objects loaded. In a domain with a very large number of users, populating the list
takes forever. What's worse is that the list has no easily discernable order. Why one
would even consider delegating control of an OU to a computer account is another
Windows 2000 unsolved mystery. One explanation is an attempt by Microsoft to

discourage browsing and encourage admins to type names in the text box and then
click Check Names to run an LDAP query to find the desired object. Browsing a long
list of AD object names is a very resource-intensive process for DCs and generates
heavy network traffic.
3. Scroll to select or type the name of the user or group to whom you want to delegate
control. You can add more than one user or group if you want. If you type the user
names, separate multiple names with semicolons and click Check Names to verify
your entries. Click OK to close the dialog and add the names to the Wizard's Users
and Groups dialog (see Figure 2-5).

Figure 2-5 Add the user or group accounts to assume

management of the OU in the Delegation of Control Wizard's
second dialog. In this example, Gary Almgren is the chairperson
and Greg Allen is the dean of the Anthropology department.

Tip You can type a first name in the Select Users, Computers, or Groups dialog and
then click Check Names to display the Select Matching Items dialog, which lists
accounts containing the name. Typing last names doesn't work, because the search is
left to right against the users' display names. Select the user from the list and click
OK.
4. In the Tasks to Delegate dialog, mark the check boxes of the permitted tasks for the
delegates. Ordinarily, the Create, Delete, and Manage Groups and Manage Group
Policy Links tasks should be reserved for Domain Admins (see Figure 2-6).
5. Click Next to display a summary of your selections in the Completing the Delegation
of Control Wizard dialog; click Finish to dismiss the wizard.
6. To confirm the preceding wizardry, right-click the selected OU, choose Properties to
open the OUName Properties dialog, and click the Security tab. Surprisingly, selecting
a delegated OU administrator, listed here by the full display name (including the

prefix), doesn't display the task permissions you set in step 4 (see Figure 2-7).
Permissions don't appear on this page, because they apply to objects contained in the
OU, not to the OU itself.

Figure 2-6 The Delegate the Following Common Tasks option lets
you choose the tasks to delegate. Selecting Create a Custom Task
to Delegate and clicking Next leads to a dialog with a laundry list
of more than one hundred AD objects that you can delegate.

Figure 2-7 The Security page of the OUName Properties dialog

adds the delegate names to the list, but doesn't display expected
permissions for specific tasks.

Note OUs inherit permissions from upper members of the hierarchy. The Allow
Inheritable Permissions from Parent to Propagate to This Object check box, which is
enabled by default, in this example inherits permissions from the Faculty Members
OU and the oakleaf.edu domain.
7. Click the Advanced Button to open the Access Control Settings for OUName dialog,
which displays the task permissions assigned to each delegate you selected in step 4
(see Figure 2-8).

Figure 2-8 The Access Control Settings for OUName dialog gives
you an overview of administrative permissions delegated for
objects contained in the OU, in this case Group and User objects.
The truncated Create/Delete permission applies to User objects
only.

8. Double-click the permission entry or click View/Edit to open the Permission Entry for
OUName dialog, which displays a list of additional tasks that you can delegate to the
selected user or group (see Figure 2-9). Entries you make in this dialog apply directly
to the Discretionary Access Control List (DACL) for the object(s), in this case group
membership. The msExch... objects appear in the list only if you've installed
Exchange 2000 or installed the Active Directory Connector (ADC) for Exchange
5.5+.

Figure 2-9 You can apply or deny permissions for additional tasks
in the Permission Entry for OUName dialog. Opening the Apply
Onto list displays a long list of AD objects to which you can assign
permissions.

Tip Even if the Apply These Permissions to Objects and/or Containers within This
Container Only check box is marked, delegated OU administrators can't alter users'
Security Group membership if the group isn't contained in the OU. The check box
affects only sub-OUs. In this example, attempting to add a new user account to the
Faculty Members or any rank-based group fails because these groups are in the
Faculty Members container, not the Anthropology container. You must explicitly
delegate prerequisite task permissions in other OUs. For this example, select the
Faculty Members OU and use the Wizard to assign Greg Allen and Gary Almgren
Modify the Membership of a Group permission only. You can save considerable time
and effort by assigning the permission to the Deans and Department Chairpersons
groups, which also prevents cluttering the Security page's list with a large number of
individual users.
9. Click OK or Cancel three times to return to Active Directory Users and Computers.
You can verify the task permissions you delegated by logging on as the delegate and
attempting each task. If you verify task permissions at a DC, you must give the Authenticated
Users group Log On Locally permission under the \Windows Settings\Security Settings\Local
Policies\User Rights Assignment node of the Domain Controller Security snap-in. Confirm
that task permissions are limited to the selected OU by attempting the same operations in a
different OU. Remove the Log On Locally permission for Authenticated Users after
completing the tests on a DC.

Setting the Managed By Attribute and Finding OUs by Attribute Value

Delegating management of an OU doesn't set the Managed By attribute of the OU, because
you can delegate management to groups or multiple users, and Managed By is a singlevalued attribute. If you delegate management of a significant number of OUs, set the
Managed By property to the user account of the person directly in charge of the OU. Doing
so enables you to use Active Directory's Find feature to list, for instance, all OUs that have
been assigned (or not assigned) managers.
To set the Managed By attribute, try the following:
1. Open the OUName Properties dialog and click the Managed By tab.
2. Click Change to open the Select User or Contact dialog.
3. Scroll the list, which has a totally random sort order, select the manager entry, and
click OK to add the attribute values.
To find all managed OUs in the domain, do this:
1. Select the DomainName node to specify the starting point for the search.
2. Click the Find Objects in Active Directory toolbar button to open the Find Users,
Contacts, and Groups dialog; click the Advanced tab.
3. Select Organizational Units in the Find list, which changes the dialog name to Find
Organizational Units.
4. Click the Field button and select Managed By from the list.
5. Open the Condition list, select Present, and click Add to add the condition to the list
box. If you want to find undelegated OUs, select Not Present as the condition.
6. Click Find Now to display the OUs that meet your search criteria (see Figure 2-10).

Figure2-10 Active Directory Users and Computers' Find feature

lets you use an LDAP query to search for OUs or other objects that
have (as shown here) or are missing attribute values.

Note The GroupPol application has an option to add the Managed By, Manager, and
Direct Reports values to objects contained in the Faculty Members OU, plus those in
the Computers OU of the Non-Faculty Staff OU. The option adds the dean of the
department as the OU manager; members of the Information Technology OU's
Helpdesk Technicians group become managers of individual computers. You must add
all 2,275 employees before the message box for this option appears in GroupPol's
main window.
Relocating an Object to an OU with the Move Command

As mentioned earlier, relocating objects from one OU to another is much easier than moving
them between domains. For instance, you might want to move the Lab Computers OU from
the domain root to the Computer Science OU, because members of the Computer Science
department are responsible for managing these computers.
To move a single object between OUs, run this drill in Active Directory Users and
Computers:
1. Right-click the objectLab Computers for this exampleand choose Move to open
the Move dialog.
2. Expand the tree to display the destination OU: \Faculty Members\Computer Science
in this case.

1. Click OK to move the object to its new location.

Filtering Objects to Move Objects by LDAP Attribute Value Strings

You can use custom LDAP filters to specify a subset of objects in a container to move to an
existing or newly created OU. For example, the Faculty Members, Computers OU contains
1,635 computer accounts, which exceeds the recommended "few hundred" objects. The
GroupPol application adds a Description attribute value to Computer objects, which
conveniently includes a (DepartmentName) suffix that you can use as a filter criterion.
Note Online help for Active Directory Users and Computers has only a single topic ("To
select view filter options") on filtering objects, but the topic doesn't explain how to apply
custom filters.
If you had the foresight to prefix or append a filterable criterion value to the objects you want
to filter for movement to a new OU, you can do the following in Active Directory Users and
Computers:
1. Create the new OU to contain the objects: in this case Anthro Computers under the
Anthropology OU.
2. Select the source containerFaculty Members\Computers for this exampleand
click the toolbar's Set Filtering Options button (with the funnel icon) to open the Filter
Options dialog.
3. Select the Create Custom Filter option and click Customize to open the strangely
named Find Custom Search dialog. Select any existing criteria in the list and click
Remove to delete them.
4. Click Field and choose Computer | Description to specify Description as the filtering
attribute for computers.
5. For this example, select the Ends With condition, type (Anthropology) in the Value
text box, and click Add (see Figure 2-11).

6. Click OK twice to close the two boxes and apply the filter to all objects except
containers displayed in Active Directory Users and Computers.

Figure 2-11 Custom filters let you select objects to move by

attribute text values, but the Value string must be located at the
beginning or end of the attribute value string.

7. Select the source container, which now displays only the objects meeting the filter
criterion you specified in step 5 (see Figure 2-12).
8. Multiselect all objects in the list (click the first entry and then SHIFT-click the last
entry), right-click the selection, and choose Move to open the Move dialog.
9. Expand the OU node to which you added the new OU in step 1, select the new OU,
and click OK to move the selected objects. The Moving message box displays a
progress bar during the move operation.
10. Click the Set Filtering Options button, select the Show All Types of Objects option,
and click OK to remove the filter.
11. Verify the move by selecting the destination OU and checking its membership.

Figure 2-12 When you apply a standard or custom filter to objects

in Active Directory Users and Computers, the header of the right
pane includes a [Filter Activated] message. Microsoft's developers
should have made [Filter Activated]'s color red and applied the
flashing attribute.

Tip Always remove the filter immediately after you move the selected objects. One of
the primary sources of administrative confusion after filtering operations is
accidentally leaving the filter in place when its job is done.
Filtering Objects to Move by Security Group Membership

Security Group membership is the most common criterion for selecting user accounts to
move into a new OU. Group membership is ADMT's only criterion for assigning users to
OUs during domain restructuring. It's reasonable to assume that the process of filtering by
group membership be essentially the same as that for filtering by attribute value stringsso
you select User, Group Membership, use Is Exactly as the condition, and type the group name
in the Value text box. Unfortunately, this approach fails. It's ironic that Microsoft provides no
online help topic or, when this book was written, no Knowledge Base article on this issue.
Note Help topics for Advanced (LDAP) searches also are missing from online help and the
Knowledge Base. Advanced searches use an obscure LDAP query dialect that's defined by
RFC2254, "The String Representation of LDAP Search Filters," which you can read at
http://www.cis.ohio-state.edu/htbin/rfc/rfc2254.html . If you're interested in learning more
about LDAP queries, which the GroupPol application uses to set the Managed By attribute of
OUs and Computer objects, download the Active Directory Service Interfaces (ADSI) 2.5
help file from
http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/adsilinks.asp .

Filtering by group membership, which searches Member Of attribute values, requires you to
supply the Distinguished Name (DN) of the group as the filter value. The DN specifies the
LDAP path to an object in AD. You can use the ADSI Edit support tool to display the DN of
each AD object in the default domain (see Figure 2-13) or any other accessible Windows
2000 domain. Choose Programs | Windows 2000 Support Tools | Tools | ADSI Edit to open
the application, and expand the container that holds the Security Group by which to filter. CN
is the LDAP abbreviation for Common Name, in this case the name of the group, followed by
the OU in which the group is located and the two Domain Components (DCs) of the
oakmont.edu domain.
Note The GroupPol application displays the DNs of objects in the domain you specify in the
startup dialog (see Figure B-6 in Appendix B). The LDAP:// prefix is a part of the full LDAP
path to an AD object but is not a component of the DN.

Figure 2-13 ADSI Edit displays the DN of each object in the AD hierarchy
in the Distinguished Name column. The Professors group
(CN=Professors,OU=Faculty Members,DC=oakmont,DC=edu) is used as
the example for filtering by group membership.

Do the following to move accounts filtered by group membership:

1. Create the new OU to contain the objects: in this case Anthro Profs under the
Anthropology OU.
2. Click the toolbar's Set Filtering Options button to open the Filter Options dialog,
select the Create Custom Filter option, and click Customize to open the Find Custom
Search dialog. Delete existing criteria from the list.
3. Click Field and choose User, Group Membership from the context menus.

4. For this example, select the Is Exactly condition, type the DN in the Value text box,
and click Add. For this example, the DN is CN=Professors,OU=Faculty Members,
DC=oakmont,DC=edu, because the Faculty Members OU contains all faculty-specific
groups.
5. Click OK twice to close the two boxes and apply the filter.
6. Select the source container, which now displays only the objects meeting the filter
criterion you specified in step 4 (see Figure 2-14). If you've provided values for an
attribute that corresponds to the group, horizontally scroll to the attribute's column to
verify that the selection met your objectives. For this example, "Professor" in the Job
Title column confirms membership in the Professors group.
Tip If the attribute you need to use to confirm the filtered list isn't present in the
Name pane, choose View | Choose Columns to open the Modify Columns dialog.
Double-click the column name in the Hidden Columns list to add it to the Displayed
Columns list and then click OK. You can change the new column's location by
selecting its title bar and dragging it to the left or right.

Figure 2-14 In the oakleaf.edu sample domain, successful filtering

by Group Membership displays only users with membership in the
Professors Security Group.

7. Multiselect all filtered objects in the list (excluding groups or OUs), right-click the
selection, choose Move to open the Move dialog, select the new OU, and click OK to
move the selected objects.
8. Click the Set Filtering Options button, select the Show All Types of Objects option,
and click OK to remove the filter.

Tip You can narrow membership in a filtered set by adding multiple filter criteria. For
example, you can limit the filtered set to users who are members of two or more
specified Security Groups (that is, members of Group1 andGroup2). Unfortunately,
Microsoft developers didn't implement a logical or feature (members of Group1 or
Group2).
Multidomain Topology

Circumstances might dictate a multiple-domain design, either at the start of the design
process or during development and testing. For instance, you might not want to mix special
external and internal user accounts in a single domain because of security issues. You might
have become frustrated with the Users, Computers, and Groups dialog's slowly generating a
list of 2,000 AD objects each time you open it. You can add new domains as children of the
first (parent) domain you created or as the first member of a new tree in the initial forest.
Administrative costs are the primary factor in the decision between adding child domains or
new trees in the forest.
If you decide to split a domain after adding user and computer accounts, you usually perform
an intraforest migration of selected user and computer accounts into the added domain. For
example, Oakleaf U's system admin might decide that students should have their own
domain, students.oakleaf.edu, for security purposes or to apply a significantly different set of
policies to students. Following are the basic steps for adding a new child domain and then
using ADMT to move or copy selected user groups and accounts to the new domain:
1. Add the new domain by running Dcpromo.exe on a Windows 2000 member server.
2. Create a set of Global groups containing the members of each user account OU you
intend to migrate, if such groups don't exist.
3. Create a corresponding set of OUs in the new domain to hold the user accounts.
4. Use ADMT to migrate (copy) Global groups to which users belong, but don't
determine user membership in OUs. This step is required for users to maintain their
group memberships during migration.
5. Migrate the Global groups created in step 2 and their user accounts to the OUs you
added in step 3.
6. Migrate computer accounts.
Note You can use the Movetree.exe command-line program, a member of the
Windows 2000 Support Tools, to move objects between domains in a forest, but using
ADMT is much easier.
Adding a New Child Domain

The process of creating a child domain is quite similar to that which you used when
promoting your first Windows 2000 member server to the initial root domain for your
network. To add a child domain, do this:

1. If you have an OU in the parent domain with the same name as the child domain you
intend to create, change the OU's name.
Note You receive a misleading "Directory service is busy" error message during the
server promotion process if a parent domain OU has the same name as the child
domain. A similar error message appears if you attempt to create a new OU in the
parent domain with the same name as that of a child domain. The problem is a
duplication of Relative Distinguished Names (RDNs), which Knowledge Base article
240147, "Cannot Create an Organizational Unit in the Parent Domain with the Same
Name as a Child Domain in Windows 2000," explains. For this example, you can
rename the Students OU in the oakmont.edu domain to Student. Changing the
Students OU name prevents adding more student accounts with GroupPol.
Alternatively, specify Student as the child domain name in step 7.
2. Verify in the DNS page of the Internet Protocol (TCP/IP) Properties dialog of your
network connection that the Preferred DNS Server text box contains the IP address of
the parent domain's DNS server.
3. Run Dcpromo.exe to start the Active Directory Installation Wizard and click Next to
bypass the Welcome dialog.
4. In the Domain Controller Type dialog, select the Domain Controller for a New
Domain option and click Next.
5. In the Create Tree or Child Domain dialog, select the Create a New Child Domain in
an Existing Domain Tree option and click Next.
6. In the Network Credentials dialog, type your user name and password for your
Domain Admins account in the parent domain and change the Domain entry, if
necessary. Click Next.
7. In the Child Domain Installation Dialog, accept or change the Parent Domain value
and type the Child Domain name. As you type, the Complete DNS Name of New
Domain text box displays the full childdomain.parentdomain.ext value:
students.oakmont.edu for this example. Click Next.
8. In the NetBIOS Domain Name dialog, accept the default or change the NetBIOS
name (STUDENTS) used by downlevel clients; then click Next.
9. In the Database and Log Locations dialog, accept the default folders, unless you have
a reason to change them, and click Next.
10. In the Shared System Volume dialog, again accept the default unless you want to put
Sysvol on another drive. Click Next.
11. If you don't need to support Windows NT Remote Access Service (RAS) on servers or
assignment of Windows 2000 users to Windows NT resource server groups in a
mixed-mode domain, select the Permissions Compatible Only with Windows 2000
Servers option. Otherwise, accept the default Permissions Compatible with PreWindows 2000 Servers option, which grants the Everyone group permissions for

specific folders and other objects that ordinarily restrict access to members of the
Authenticated Users group. Click Next.
Tip Don't select the Permissions Compatible Only with Windows 2000 Servers option
until you've upgraded all Windows NT resource servers to Windows 2000.
Knowledge Base articles 257988, "Description of Dcpromo Permissions Choices,"
and 257942, "Error Message: Unable to Browse the Selected Domain Because the
Following Error Occurred...," describe the consequences of selecting this option. You
can't change the option you select in this dialog without demoting the DC and starting
over.
12. In the Directory Services Restore Mode Administrator Password dialog, type and
confirm the password to use to remove the domain or administer it with the
Ntdsutil.exe command-line utility; click Next.
13. In the Summary dialog, review your settings and then click Next to start the AD
installation and child domain creation process, which takes more than the advertised
"several" minutes on moderate-speed servers.
14. Reboot the new DC for the child domain and log on with Enterprise Admins
credentials.
15. Launch Active Directory Domains and Trusts, click to expand the parent domain
node, right-click the child domain node, and choose Properties to open the
childdomain.parentdomain.ext Properties dialog. The target (child) domain must run
in native mode, so click Change Mode to make the domain ready for the move with
ADMT.
16. Install ADMT on the DC for the child (target) domain. Download instructions are in
the "Easing Restructure and Migration with ADMT" section of Appendix C.
17. On the child DC, launch the Domain Security Settings snap-in from Administrative
Tools and navigate to and select the Windows Settings\Security Settings\Local
Policies\Audit Policy node.
18. Double-click the Audit account management policy to open the Security Policy
Settings dialog. Mark the Define These Policy Settings, Success, and Failure check
boxes and click OK to apply the policy.
19. Repeat steps 17 and 18 on the parent domain DC. Account management auditing is
required for ADMT operations on user accounts in both domains.
Adding a child domain automatically adds a Dynamic DNS (Active Directory-integrated,
DDNS) primary forward lookup zone for the child domain to the parent domain's DNS
server. When users move to the child domain, DHCP doesn't need to assign their Primary
DNS Server to the child domain server's IP address.
Preparing the Domains for the Intraforest Move

Before you begin the migration process, in the parent domain add a Security Group
containing all members of each OU you want to move, if such groups aren't present. Then

add OUs in the child domain to contain the migrated Global groups and their users. For this
example, the five sub-OUs of the Students OU (Freshmen, Sophomores, Juniors, Seniors, and
Computers) don't have associated security groups, but you need only the four academic-year
groups to define OU membership. ADMT requires Security Groups to place user accounts in
designated OUs. You use the temporary groups discussed in the later section "Moving Groups
and Their Users to Designated OUs" to regenerate OU membership by adding the user
accounts based on group membership. After you complete group and user migration, you
move all computers from the Students, Computers OU to the default Computers container of
the child domain.
To add selected users to a temporary Security Group in the parent domain, do this:
1. Right-click the domainname node or any OU that doesn't have objects that duplicate
the group names you create and then choose New, Group to open the New Object
Group dialog.
2. Type the name of the group in the text box, accept the default Global and Security
options, and click OK to add the new group.
3. Select the OU to display its members and then multiselect all user objects only; don't
include OU's or groups.
4. Right-click the selection, choose Add Members to a Group to open the Select Group
dialog, type or scroll to and select the temporary group name, and click OK to
perform the addition.
Tip If the OU doesn't include objects other than users, right-click the OU node in the
tree-view pane and choose Add Members to a Group. After you specify the group
name, a message box opens to request confirmation that you want to add all users.
Click Yes to All and wait for "The Add to Group operation was successfully
completed" message to appear; then click OK. There is no user feedback during the
Add to Group process.
5. Repeat steps 1 through 4 for each temporary group you created.
6. Add the OU to hold the other security groups for the user accounts being moved
(Major Subject Groups).
To verify temporary group membership, right-click the GroupName node, choose Properties
to open the GroupName Properties dialog, and click the Members tab.
Note If you use student accounts created by GroupPol in these procedures, delete the
Students Domain Local group before the migration. This group is applicable only to a single
domain.
Adding Target OUs in the Child Domain

After you've added the necessary temporary groups, do the following to create required Ous
in the child domain:
1. Log on to any DC or workstation that has ADMT installed with your Enterprise
Admins account.

2. Launch Active Directory Users and Computers, right-click the domain name node,
select Connect to Domain to open the dialog of the same name, type or browse to the
child domain, and click OK.
3. Right-click the domain name node again, choose New | Organizational unit to open
the New Object-Organizational Unit dialog, type the name of a first-level OU in the
text box, and click OK. Repeat this step for each first-level OU for the first domain.
Note For this example, the second-level OUs of the parent domain's Student(s) OU
(Freshmen, Sophomores, Juniors, Seniors) become first-level OUs in the child
domain, because only student accounts exist in the child domain. There's no need to
have a Student OU in a domain named Students.
4. If you have second-level OUs, add them to the first-level OUs you created in the
preceding step.
5. Also add an OU for migrating the first set of groups without user accounts. For this
example, a Major Subject Groups OU will hold copies of the 14 Global groups, which
contain student accounts by major subject.
Copying the First Set of Groups

When you migrate groups without their user accounts, ADMT copies the groups from the
source to the target domain. Copying prevents users being denied access to these groups'
resources while the migration is in process. Do the following to copy groups without their
user accounts:
1. Launch ADMT, right-click the Active Directory Migration Tool node, and choose
Group Migration Wizard. Click Next to bypass the Welcome dialog.
Tip Appendix C has detailed instructions for using the Group Migration Wizard,
including figures showing the wizard boxes. There are differences between the
interforest migration from a Windows NT domain to a Windows 2000 domain and an
interforest move between Windows 2000 domains, but most of the steps are similar.
2. In the Test or Make Changes dialog, select the Migrate Now? option if you want to
perform the move without testing. If you select the Test the Migration Settings and
Migrate Later option, you must repeat all migration steps to effect the migration.
Click Next.
3. In the Domain Selection dialog, select the NetBIOS names of the source and target
(child) domains (OAKMONTU and STUDENTS for this example) and click Next.
4. In the Group Selection dialog, click add to open the Group Selection dialog and
double-click each Global group to which the users you're migrating belong, but not
the groups that correspond to OU memberships. For instance, don't add the temporary
security groups you added in the preceding set of steps. You add these groups later
along with their users. For this example, you add the 14 DepartmentName Majors
groups, but not the temporary Freshmen, Sophomores, Juniors, and Seniors groups
(see Figure 2-15). Click OK to add the groups to the Group Selection dialog's list and
then click Next.

Figure 2-15 You migrate all Global groups to which the migrated
users belong except those groups that you use to move user
accounts from source OUs to target OUs.

5. In the Organizational Units dialog, click Browse to open the Browse for Container
dialog, select the special OU you created for groups or the domain container, and
click OK to add the full LDAP path to the group in the Target OU text box. For this
example, the path is LDAP://STUDENTS/OU=Major Subject Groups,DC=students,
DC=oakmont,DC=edu. Click Next.
6. In the Group Options dialog, accept the defaults and click Next.
7. In the User Account dialog, type your Enterprise or Domain Admins credentials for
the child domain, change the downlevel domain name for your account, if necessary,
and click Next.
8. In the Naming Conflicts dialog, accept the defaults and click Next.
9. In the Completing the Group Account Wizard dialog, click Finish to open the
Migration Progress dialog and begin the group migration process.
10. When the Status value in the Migration Progress dialog changes to Completed, click
View Log to open the Migration log for the groups (see Figure 2-16).
11. Close the Migration log and click Close in the Migration Progress dialog to return to
ADMT's snap-in.

Moving Groups and Their Users to Designated OUs

The process of migrating groups with users to the child domain OUs you created previously
is quite similar to that for copying groups without users. To migrate groups and users by
copying accounts, do this:
1. Repeat steps 2 and 3 of the preceding section. In step 3, the Wizard adds the fully
qualified DNS names of the source and destination domains you originally specified
with NetBIOS names.
2. In the Group Selection dialog, click Add and type or select the group to move in the
Select Group dialog (the temporary Freshmen group for this example). Click OK to
return to the Wizard; then click Next.
3. In the Organizational Unit dialog, click Browse to open the Browse for Container
dialog, select the OU in the source (parent) domain that contains the users you want to
migrate, and click OK to add the full LDAP path of the OU to the Target OU text box
(LDAP://STUDENTS/OU=Freshmen,DC=students,DC=oakmont,DC=edu for this
example). Click OK.

Figure 2-16 The Migration log for the first set of groups detects
that user accounts haven't been migrated and copies (instead of
moves) the groups. StuAnthro, StuBio, and other Stu... entries are
the downlevel names of the groups assigned by GroupPol.

4. In the Group Options dialog, mark the Update User Rights and Copy Group Members
check boxes and accept the default Do Not Rename Accounts option. Click Next. A

message warns you that if Global groups weren't migrated previously, users lose their
membership in the unmigrated groups. Click OK.
5. Repeat steps 7 through 11 of the preceding section.
6. Launch Active Directory Users and Computers on the child domain DC and verify
migration of the groups and user accounts (see Figure 2-17). Also check the Members
page of the Properties dialog for each Security Group you migrated to verify that the
group contains the appropriate user accounts.

Figure 2-17 Active Directory Users and Computers running in the

child domain verifies that user accounts you move based on their
group membership migrate to the designated OU.

Tip If the child domain's Active Directory Users and Computers snap-in was open
during the migration process, choose View | Refresh to update its contents. If you
don't see migrated objects, close and reopen the snap-in.
Migrating Computer Accounts

ADMT's Computer Migration Wizard lets you move Windows 2000 and NT computer
accounts between domains. During the migration process, ADMT dispatches "agents" to
automatically change the domain affiliation of the computer accounts and reboot the
computer after a specified interval. One potential hitch in the process when migrating nonowned computer accounts is that the account you use to generate the computer migration
agents must be a member of the local Administrators group of the client machines.
The Domain Admins group of the source domain is a member of the local Administrators
group of Windows 2000 clients, but using an Enterprise Admins account is the safer option.
The "Migrating Computer Accounts" section of Appendix C shows you how to move
computer accounts to a new domain.

The above article is courtesy of Osborne/McGraw-Hill .

We at Microsoft Corporation hope that the information in this work is valuable to you. Your
use of the information contained in this work, however, is at your sole risk. All information in
this work is provided "as -is", without any warranty, whether express or implied, of its
accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none
of the third-party products or information mentioned in the work are authored, recommended,
supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable
for any damages you may sustain by using this information, whether direct, indirect, special,
incidental or consequential, even if it has been advised of the possibility of such damages.

Active Directory Users, Computers, and

Groups
234 out of 313 rated this helpful - Rate this topic

Operating System
Abstract
In the Microsoft Windows 2000 operating system, the Active Directory service
provides user and computer accounts and distribution and security groups. The operating
system integrates user, computer, and group security with the Windows 2000 security
subsystem as a whole. This paper introduces administrators unfamiliar with Windows 2000 to
the way users, computers, and groups are organized and how user authentication and
authorization are used to provide security.
On This Page

Introduction
Active Directory User and Computer Accounts
Active Directory Groups
User Authentication
User Authorization
Summary
Appendix A: Built-in, Predefined, and Special Groups
Appendix B: User Rights
Introduction

A great part of network administration involves management of users, computers, and groups.
A successful operating system must ensure that only properly authenticated users and
computers can logon to the network and that each network resource is available only to
authorized users. In the Microsoft Windows 2000 operating system, the Active
Directory service plays several major roles in providing security. Among these roles are the
efficient and effective management of user logon authentication and user authorization. Both
are central features of the Windows 2000 security subsystem and both are fully integrated
with Active Directory.
Active Directory user authentication confirms the identity of any user trying to log on to a
domain and lets users access resources (such as data, applications, or printers) located

anywhere on the network. A key feature of Windows 2000 user authentication is its single
sign-on capability, which makes multiple applications and services available to the user over
the network without the user having to provide credentials more than once.
Active Directory user authorization secures resources from unauthorized access. After a user
account has received authentication and can potentially access an object, the type of access
actually granted is determined by what user rights are assigned to the user and which access
control permissions are attached to the objects the user wishes to access. An object is a
distinct, named set of attributes, and includes shared resources such as servers, shared
volumes, and printers; network user and computer accounts; as well as domains, applications,
services, and security policies.
This paper describes Windows 2000 users, computers, and groups from the perspective of
security, with an emphasis on the security issues of authentication and authorization. The
following sections cover these topics:

Active Directory User and Computer Accounts

Active Directory Groups

User Authentication

User Authorization

For security topics not covered in this paper and for information about the structure of Active
Directory (including Active Directory objects, domains, trees, forests, trusts, organizational
units, and sites), see the section "For More Information" at the end of this document.
Concepts

The following definitions will help you understand the basic concepts that are used
throughout the paper:

User rights are assigned to groups (or users). User rights include both privileges
(such as Back Up Files and Directories) and logon rights (such as Access this
Computer from Network).
Access control permissions (such as Read, Write, Full Control, or No Access) are
attached to Windows 2000 objects. In the case of Active Directory objects, access
control can be defined not only for each object in the directory but also for each
property of each object. (For a list of all object types, see the section "Object Types,
Managers, and Tools.")
Access token. Each time a user logs on, Windows 2000 creates an access token. The
access token is a representation of the user account and contains the following
elements:
o

Individual SID. Security identifier (SID) representing the logged-on user

Group SIDs. SIDs representing the logged-on user's group memberships

User Rights. Privileges (associated with each SID) granted to the user or to
groups to which the user belongs

When the user tries to access an object, Windows 2000 compares each SID in the
user's access token to entries in an object's discretionary access control list (DACL) to
determine whether the user has permission to access the object and, if access is
allowed, what type of access it is. In some cases, user rights in the user's token may
override the permissions listed in the DACL and access may be granted that way.

An access token is not updated until the next logon, which means that if you add a
user to a group, the user must log off and log on before the access token is updated.

Security identifier (SID). A SID is a code that uniquely identifies a specific user,
group, or computer to the Windows 2000 security system. A user's own SID is always
attached to the user's access token. When a user is made a member of a group, the SID
for that group is also attached to the user's access token.

Access Control List (ACL). Each Active Directory object (as well as each file,
registry key, and so on) has two associated ACLs:

DACL. The discretionary access control list (DACL) is a list of user accounts,
groups, and computers that are allowed (or denied) access to the object.

SACL. The System Access Control List (SACL) defines which events (such
as file access) are audited for a user or group.

Access Control Entry (ACE). A DACL or SACL consists of a list of Access Control
Entries (ACEs), where each ACE lists the permissions granted or denied to the users,
groups, or computers listed in the DACL or SACL. An ACE contains a SID with a
permission, such as Read access or Write access. Windows 2000 combines access
permissionsif you have Read access to an object because you are a member of
Group A and if you have Write access because you are a member of Group B, you
have both Read and Write access to the object. However, if you have No Access as a
member of Group C, you will not have access to the object.
Figure 1 shows how a user's access token and an object's DACL let the user (in this
case) access the object. When the user, Adam, requests access to the payroll file
object, Windows 2000 compares each SID in Adam's access token to each ACE in the
DACL to see if access is explicitly denied to Adam or to any group to which Adam
belongs. It then checks to see if the requested access is specifically permitted.
Windows repeats these steps until it encounters a No Access or until it has collected
all the necessary permissions to grant the requested access. If the DACL does not
specifically allow permission for each requested access, access is denied.

Figure 1: User authentication creates an access token for the user. The
access token contains the user's primary SID, together with the SIDs of
any groups to which the user belongs. This user is authorized to access
this domain resource, a payroll file.
Top of page
Active Directory User and Computer Accounts

The Windows 2000 operating system uses a user or computer account to authenticate the
identity of the user or computer and to authorize or deny access to domain resources. For
example, users who are members of the Enterprise Administrators group are, by default,
granted permission to log on at any domain controller in the Active Directory forest.
Administrators can audit actions performed by user or computer accounts.
You add, disable, reset, or delete user and computer accounts using the Active Directory
Users and Computers tool.
This section covers the following topics:

User Accounts
Computer Accounts

Security Principals

Group Policy Applied to User and Computer Accounts

User Accounts

A user requires an Active Directory user account to log on to a computer or to a domain. The
account establishes an identity for the user; the operating system then uses this identity to
authenticate the user and to grant him or her authorization to access specific domain
resources.
User accounts can also be used as service accounts for some applications. That is, a service
can be configured to log on (authenticate) as a user account, and it is then granted access to
specific network resources through that user account.

Predefined User Accounts

Windows 2000 provides the following two predefined user accounts1:

Administrator account

Guest account

You can use these accounts to log on locally to a computer running Windows 2000 and to
access resources on the local computer. These accounts are designed primarily for initial
logon and configuration of a local computer. The Guest account is disabled and you must
enable it explicitly if you want to allow unrestricted access to the computer. The
Administrator account is the most powerful account because it is a member of the
Administrators group by default. This account must be protected with a strong password to
avoid the potential for security breach to the computer.
To enable the Windows 2000 user authentication and authorization features, you create an
individual user account for each user who will participate on your network. Then add each
user accountincluding the Administrator and Guest accountsto Window 2000 groups,
and assign appropriate rights and permissions to each group.
Computer Accounts

Like user accounts, Windows 2000 computer accounts provide a means for authenticating
and auditing the computer's access to the network2 and its access to domain resources. Each
Windows 2000 computer to which you want to grant access to resources must have a unique
computer account.
Computers running Windows 98 and Windows 95 do not have the advanced security features
of those running Windows 2000 and Windows NT, and they cannot be assigned computer
accounts in Windows 2000 domains. However, you can log on to a network and use Windows
98 and Windows 95 computers in Active Directory domains.
Security Principals

Active Directory user and computer accounts (as well as groups, covered later) are referred to
as security principals, a term that emphasizes the security that the operating system
implements for these entities. Security principals are directory objects that are automatically
assigned SIDs when they are created. Objects with SIDs can log on to the network and can
then access domain resources.
If you establish a trust relationship between a domain in your Windows 2000 forest and a
Windows 2000 domain external to your forest, you can grant security principals from the
external domain access to resources in your forest. To do so, add external security principals
to a Windows 2000 group, which causes Active Directory to create a "foreign security
principal" object for those security principals3. You can make foreign security principals
members of domain local groups (covered later). You cannot manually modify foreign
security principals, but you can see them in the Active Directory Users and Computers
interface by enabling Advanced Features.

Group Policy Applied to User and Computer Accounts

In the Windows 2000 operating system environment, you can associate Group Policy
configuration settings with three Active Directory containersorganizational units (OUs),
domains, or sites. Group Policy settings associated with a given container either affect all
users or computers in that container, or they affect specified sets of objects within that
container. You can use Group Policy to configure security options, manage applications,
manage desktop appearance, assign scripts, and redirect folders from local computers to
network locations. The system applies group policy to computers at boot time or to users
when they log on. (You can also set the group policy refresh interval policy for users or
computers; the default refresh interval for both users and computers is 90 minutes.)
Here are three examples of using group policy settings:

Set the minimum password length and the maximum length of time that a password
remains valid for an entire domain.
Assign logon and logoff scripts to the user accounts in each organizational unit.

Specify which applications are available to users when they log on.

For detailed information about Group Policy, see "For More Information."
Top of page
Active Directory Groups

Groups are Active Directory (or local computer) objects that can contain users, contacts,
computers, and other groups. In Windows 2000, groups are created in domains, using the
Active Directory Users and Computers tool. You can create groups in the root domain, in any
other domain in the forest, in any organizational unit, or in any Container class object (such
as the default Users container). Like user and computer accounts, groups are Windows 2000
security principals; they are directory objects to which SIDs are assigned at creation.
You can nest groups; that is, you can add a group as a member of another group (according to
specified rulessee the section "Mode Governs Nesting Options"). Nesting groups makes it
easier to manage users and can reduce network traffic caused by replication of group
membership changes.
Planning group strategies is an essential part of deploying Active Directory. Before you create
groups, determine the number of domains you will have on your network and which of those
domains (if any) are mixed-mode and which are native-mode:

Mixed-mode domain. The Windows 2000 operating system installs, by default, in a

mixed-mode network configuration. A mixed-mode domain is a networked set of
computers running both Windows NT 4.0 and Windows 2000 domain controllers.
(You can also have a mixed-mode domain running only Windows 2000 domain
controllers.)
Native-mode domain. You can convert a domain to native mode when it contains
only Windows 2000 Server domain controllers.

Important: Do not change from mixed to native mode if you have, or will have, any
Windows NT 4.0 backup domain controllers (BDCs) in the domain. Changing a domain from
mixed mode to native mode is an irreversible operation.
Both mixed-mode and native-mode domains can contain Windows NT 4.0 member servers
and Windows NT and Windows 9.x clients.
The following sections discuss the structure of groups and how you can use the various
groups to help organize your network:

Group Type: Security or Distribution

Group Scope: Local, Domain Local, Global, or Universal

How Domain Mode Affects Groups

Windows 2000 Built-in, Predefined, and Special Groups

Groups on Standalone Servers and Windows 2000 Professional

Group Type: Security or Distribution

Windows 2000 Server has two kinds of groups:

Distribution groups

Security groups

Although this section is primarily about the role groups play in security, distribution groups
are also briefly described to clarify the difference between the two group types. The next two
subsections describe the characteristics of security and distribution groups.
Distribution Groups
Distribution groups have only one functionto create e-mail distribution lists. You use
distribution groups with e-mail applications (such as Microsoft Exchange) to send e-mail to
the members of the group. As with a security group, you can add a contact to a distribution
group so that the contact receives e-mail sent to the group.
Distribution groups play no role in security (you do not assign permissions to distribution
groups), and you cannot use them to filter Group Policy settings.
Security Groups
In the Windows 2000 operating system, security groups are an essential component of the
relationship between users and security. Security groups have two functions:

To manage user and computer access to shared resources

To filter Group Policy settings

You collect users, computers, and other groups into a security group and then assign
appropriate permissions to specific resources (such as file shares and printers) to the security
group. This simplifies administration by letting you assign permissions once to the group
instead of multiple times to each individual user. When you add a user to an existing group,
the user automatically gains the rights and permissions already assigned to that group.
Integral to understanding security groups is the concept of an access token. As explained in
the Introduction, an access token is an object containing the security information for a logon
session. Windows 2000 creates an access token when a user logs on, and every process
executed on behalf of the user has a copy of the token. (A process is software that is currently
running.) The token identifies the user, the security groups to which the user belongs, and the
privileges granted to the user and to the user's security groups. The system uses the token to
control access to securable objects and to control the ability of the user to perform various
system-related operations on the local computer.
If you use an e-mail client that can use Active Directory for address book lookup, or an email system that uses Active Directory as its directory (such as Exchange 2000), you can also
use security groups to send e-mail to all members of the group. You can add a contact to a
security group, and that contact is sent e-mail along with the other members of the group.
However, you cannot assign rights and permissions to a contact.
When implementing an administration strategy for security groups, keep the following
general guidelines in mind:

Small organizations. Some small organizations with a Windows 2000 native-mode

forest will choose to use security groups with Universal scope to manage all their
group needs. For organizations that expect to grow, two alternative strategies are
available:
o Use Universal groups initially and then convert to the Global/Local pattern
(described next) recommended for medium to large organizations.
o

Some growing small organizations will choose to implement the Global/Local

pattern used by larger organizations from the start. Because groups with
universal scope (and their members) are listed in the global catalog database4,
a large number of universal groupsespecially where membership changes
frequentlycan cause a lot of replication traffic. If this is the situation, use the
guidelines for medium to large organizations.

Medium to large organizations. Experience shows that using the approach described
below will help you achieve maximum flexibility, scalability, and ease of
administration when managing security groups. Using Account (global) groups and
Resource (local) groups in the way described here lets you use groups to mirror your
organization's functional structure.
o

Put users into security groups with global scope. A global group can usually be
thought of as an Accounts group, that is, a group that contains user accounts.

Put resources into security groups with domain local (or machine local) scope.
A local group can usually be thought of as a Resource group, that is, a group to
which you assign permissions to access a resource.

Put a global group into any domain local (or machine local) group in the forest
(this is especially efficient when more than one domain is involved).

Assign permissions for accessing resources to the domain local (or machine
local) groups that contain them.

Delegate administration of groups to the appropriate manager or group leader.

Understanding what these guidelines mean requires understanding the different kinds of
group scope, explained in the next section.
Group Scope: Local, Domain Local, Global, or Universal

Both types of groupsecurity and distributioncan have one of three scopes (four when you
include local groups, which exist in Windows 2000 to provide backward compatibility with
Windows NT groups). A group's scope determines the extent to which the group can be
nested in other groups or referenced in DACLs on resources in the Active Directory domain
or forest.
Important: In the following discussion of group scope, remember that you assign
permissions only to security groups (not to distribution groups).
By default, when you create a new group, it is configured as a security group with global
scope (in both mixed-mode and native-mode domains).
If you have multiple forests, you can place groups (or usersbut, typically, you should put
users only into global groups) from any trusted domain into a local or domain local group.
You can establish trust between any two domains in any two forests.
The four possible Windows 2000 group scopes are:

Groups with local scope (also called local groups)

Groups with domain local scope (also called domain local groups)

Groups with global scope (also called global groups)

Groups with universal scope (also called universal groups)

With some minor differences, domain local and global groups exist in the Windows NT
operating system (where they are called local groups and global groups). Universal groups
are new in Windows 2000. The following subsections describe each type of group scope.
Groups with Local Scope
The local groups used in both Windows NT and Windows 2000 are precursors of and are in
some ways similar to the domain local groups (described next) introduced in Windows 2000.
Local groups are sometimes referred to as machine local groups to contrast them with
domain local groups. Local groups have the following features:

Mode. Local groups are the only type of local group available in a Windows 2000
mixed-mode domain. In the case of Windows 2000 native-mode domains, only Builtin groups have local scope.
Membership. Local groups can have members from anywhere in the forest, from
trusted domains in other forests, and from trusted down-level domains.
Permissions. A local group has only machine-wide scope; that is, it can be used to
grant resource permissions only on the machine on which it exists. (Note, however,
that local groups created on a domain controller are available on every domain
controller in that domain and can be used to grant resource permissions on any
domain controller in that domain.)

Groups with Domain Local Scope

Domain local groups, a new feature of the Windows 2000 operating system, have the
following features:

Mode. Domain local groups are available only in native-mode (but not mixed-mode)
domains.
Membership. Like local groups, domain local groups can have members from
anywhere in the forest, from trusted domains in other forests, and from trusted downlevel domains.
Permissions. A domain local group has domain-wide scope; that is, it can be used to
grant resource permissions on any Windows 2000 machine within the domain in
which it exists (but not beyond its domain).

Using Domain Local Groups

Groups with domain local scope are designed to be used in DACLs on a domain's resources.
That is, domain local groups help you define and manage access to resources within a single
domain.
For example, to give five users access to a particular printer, you could add all five user
accounts, one at a time, to the printer permissions list. Later, if you wanted to give the same
five users access to a new printer, you would again have to specify all five accounts in the
permissions list for the new printer. Or, you could take advantage of groups with domain
local scope. To do so, perform the following steps:
1. Create a group with domain local scope, and assign it permission to access the printer
(this is the Resource group).
2. Put the five user accounts into a group with global scope (this is the Accounts group),
and add this global group to the group having domain local scope. (Global groups are
described in the next subsection.)
Now, when you want to give another five users access to this printer, you can simply add
them to the global group that is a member of the domain local group which has permission to
access the printer, and you are done. Doing so gives all five new members of the group access

to the printer in one step. Using domain local groups in this way provides the following
benefits:

Membership of the domain local group is controlled by the administrator(s) where the
resource (the printer) is located, not where the users arewhich makes it in line with
how administration is typically done.
Because a domain local group is associated with an access token built when a member
of that group authenticates to a resource in that domain, unnecessary network traffic
(carrying of membership information) is avoided. (If, instead, you assigned a global
group permission to access the printer, the global group can end up in a user's token
anywhere in the forest, causing unnecessary network traffic.)

Groups with Global Scope

Global groups, effectively the same as Windows NT global groups, have the following
features:

Mode. Global groups exist in both mixed-mode and native-mode domains.

Membership. Global groups can have members from within their own domain (only).

Permissions. Although a global group is limited to domain-wide scope as far as

membership goes, it can be made a member of machine or domain local groups or
granted permissions in any domain (including trusting domains in other forests and
down-level domains with which a trust relationship exists). That is, groups with
global scope can be put into other groups in any trusting domain.

Using Global Groups

Groups with global scope help you manage directory objects that require daily maintenance,
such as user and computer accounts.
Use global groups to collect users or computers that are in the same domain and share the
same job, organizational role, or function. For example, "Full-time employees," "Managers,"
"RAS Servers" are all possible global groups. Because group members typically need to
access the same resources, make these global groups members of domain local or machine
local groups, which, in turn, are listed on the DACL of needed resources. Membership of
these groups can be efficiently managed by administrators of user domains, because these
administrators are familiar with the functions and roles played by users and computers in
their domain.
Groups with Universal Scope
Universal groups, a new feature of the Windows 2000 operating system, have the following
features:

Mode. Universal groups are available only in native-mode domains.

Membership. Universal groups can have members from any Windows 2000 domain
in the forest. (Universal groups can contain members from mixed-mode domains in
the same forest, but this is not recommended. Members from such domains cannot
have the universal group's SID added to their access token because universal groups

are not available in mixed-mode domains. Therefore, troubleshooting access problems

would be difficult.)

Permissions. Universal groups can be granted permissions in any domain, including

in domains in other forests with which a trust relationship exists.

Using Universal Groups

A small organization can use universal groups to implement a relatively simple group
structure. If you choose to use groups with universal scope in a multi-domain environment,
these groups can help you represent and consolidate groups that span domains. For example,
you might use universal groups to build groups that perform a common function across an
enterprise.
Although few organizations will choose to implement this level of complexity, you can add
user accounts to groups with global scope, nest these groups within groups having universal
scope, and then make the universal group a member of a domain local (or machine local)
group that has access permissions to resources. Using this strategy, any membership changes
in the groups having global scope do not affect the groups with universal scope.
A useful guideline is to designate widely used groups that seldom change as universal groups.
The reasons for this approach are explained next.
Group Scope and Replication Traffic
Groups having universal scopeand all of their membersare listed in the global catalog.
Whenever one member of a group with universal scope changes, the entire group
membership must be replicated to all global catalogs in the domain tree or forest. Therefore,
if you use groups with universal scope, use them in situations where the membership of the
group does not change frequently.
Groups having global or domain local scope are also listed in the global catalog, but their
individual members are not listed. Using these groups thus reduces the size of the global
catalog and reduces the replication traffic needed to keep the global catalog up-to-date.
Therefore, use groups with global or domain local scope if the group membership changes
frequently.
How Domain Mode Affects Groups

As explained above, a mixed-mode domain typically has one or more Windows NT Server
4.0 domain controllers in addition to Windows 2000 domain controllers, although it can have
only Windows 2000 domain controllers. A native-mode domain can have only Windows 2000
Server domain controllers. Both mixed-mode and native-mode domains can include Windows
NT 4.0 member servers and Windows NT and Windows 9.x clients.
Important: Do not change from mixed to native mode if you have, or will have, any
Windows NT 4.0 backup domain controllers (BDCs) in the domain. Changing a domain from
mixed mode to native mode is an irreversible operation.
Mode Determines Whether You Can Convert Group Types

In a native-mode domain, you can convert a security group to a distribution group and vice
versa. You cannot convert either group to the other in a mixed-mode domain. A Windows NT
domain controller cannot handle group type conversion because it sees only security-enabled
groups.
Mode Affects Security and Distribution Groups Differently
Distribution groups are not affected by mode because distribution group membership is not
enumerated at logon. If a process needs to know the composition of the group, it has to ask an
Active Directory server, which, by definition, is a Windows 2000 domain controller.
Whether a domain is native or mixed mode does affect the behavior of security groups. When
a user logs on to a domain account, the user's security group membership is resolved on the
domain controller that handles the logon. In mixed mode, if a Windows NT 4.0 domain
controller handles the logon, then it must be able to enumerate the members of the security
groups to which the user belongs. Thus, the behavior of security groups in a Windows 2000
domain running in mixed mode must match the behavior of security groups in Windows NT
4.0.
Mode Governs Nesting Options
Updates to the Active Directory store must be made in a single transaction. One consequence
of this is that you should not create groups with more than 5,000 members. Because group
memberships are stored in a single multi-valued attribute, a change to the membership
requires that the whole attributethat is, the whole membership listbe updated in a single
transaction. Microsoft has tested and supports group memberships of up to 5,000 members.
Windows 2000 lets you get around this limitation by nesting groups to increase the effective
number of members. Nesting also lessens the amount of network traffic caused by replication
of group membership changes.
Available nesting options depend on whether the domain is in native mode or mixed mode.
The following list describes what can be contained in a group that exists in a native mode
domain:

Groups with universal scope can contain user accounts, computer accounts, other
universal groups, and global groups from any trusted domain.
Groups with global scope can contain user accounts from the same domain and other
global groups from the same domain.
Groups with domain local scope can contain user accounts, universal groups, and
global groups from any trusted domain. They can also contain other domain local
groups from within the same domain. (Typically, put user accounts into global groups,
not into domain local groups, then put the global groups into domain local groups, and
then assign access permissions to resources to the local groups.)

Security groups in a mixed-mode domain can contain only the following:

Local groups can contain global groups and user accounts from trusted domains. (It is
not recommended to put users directly into local groups; instead, put users into global

groups, put global groups into local groups, and then assign permissions to the local
groups).

Global groups can contain only user accounts.

Changing to Native Mode Impacts Groups

When a Windows NT primary domain controller (PDC) is upgraded to Windows 2000 Active
Directory, Windows NT local groups become Windows 2000 local groups and Windows NT
global groups become Windows 2000 global groups. When a domain is converted to native
mode, local groups become domain local groups.
When a user is authenticated, an access token is created for the user containing his or her
primary SID, together with the SIDs of any groups he or she belongs to. At the time the
domain is switched to native mode, because domain local groups have domain-wide scope,
the SIDs of any domain local groups of which the user is a member are now added to the
user's access token.
Windows 2000 Built-in, Predefined, and Special Groups

Windows 2000 provides three sets of default groups: Built-in, Predefined, and Special
groups. These default groups are summarized in "Appendix A: Built-in, Predefined, and
Special Groups".
Groups on Standalone Servers and Windows 2000 Professional

Universal groups, group nesting, and the distinction between security and distribution groups
are available only on Active Directory domain controllers and Windows 2000 member
servers. Group accounts on Windows 2000 Server stand-alone servers and on Windows 2000
Professional function as in Windows NT 4.0:

The only groups you can create locally on a stand-alone server or Professional
workstation are local groups.

A local group created on a stand-alone server or Professional workstation can be

assigned permissions only on that computer.

However, if you join a Windows 2000 Professional computer to a Windows 2000 domain, the
workstation can display global groups and universal groups both from that domain and from
all domains in the forest. You can assign permissions for the local computer to these groups
or place them in the local computer groups.
Top of page
User Authentication

User authentication confirms the identity of any user trying to log on to a domain or access
network resources. Windows 2000 authentication enables single sign-on to all network
resources. A user can log on to the domain once, using a single password or smart card, and
can then access resources on any computer in the domain. For users, single sign-on provides

quick and efficient access to resources. For administrators, single sign-on reduces the amount
of support required for users because the administrator needs to manage only one account per
user.
Windows 2000 user authentication, including single sign-on, is implemented as a single, twopart process: interactive logon and network authentication. Successful user authentication
depends on both parts of this process. The first two subsections briefly describe these two
aspects of authentication. The third subsection describes authenticating external users:

Interactive logon
Network authentication

Using certificates to authenticate external users

For detailed technical descriptions of Windows 2000 user authentication, see the Windows
2000 Resource Kit "Authentication" chapter listed in "For More Information."
Interactive Logon

Interactive logon (the first part of the single sign-on process) confirms the user's identity to
the user's Active Directory domain account or local computer. When a user walks up to the
computer to start work, the user logs on, that is, presents credentials (domain or local) to the
computer to gain access to its resources (monitor, keyboard, mouse, local disk, network
access, and so on). This process differs depending on the type of user account:

Domain account. With a domain account, a user logs on to the network (with a
password or smart card) using single sign-on credentials stored in Active Directory.
After logging on with a domain account, an authorized user can access resources in
the domain and any trusting domains.
o If a password is used to log on to a Windows 2000 computer using a domain
account in a Windows 2000 domain, Windows 2000 uses Kerberos version 5
(V5) for authentication. If a smart card is used instead of a password,
Windows 2000 uses Kerberos V5 authentication with certificates.
o

If the authenticating domain controller is a Windows NT 4.0 domain controller

or if the user's computer is a Windows NT 4.0 computer, then the
authentication used is Windows NT LAN Manager (NTLM). (See next section
for more about Kerberos and NTLM.)

Local account. With a local computer account, a user logs on to a local computer
using credentials stored in that computer's Security Accounts Manager5(SAM), which
is the Windows 2000 local security account database. Any Windows 2000 computer
that is not a domain controller can store local user accounts, but those accounts can be
used for access only to that local computer.

Network authentication (described next) is transparent to users using a domain account.

When using the domain account, the user's credentials are used for a single sign-on. Users
using a local computer account, however, must provide credentials (such as a user name and
password) each time they access a network resource.

Network Authentication

Network authentication (the second part of the single sign-on process) confirms the user's
identity to any network service the user attempts to access. For network authentication,
Windows 2000 uses one of the following industry-standard types of authentication:

Kerberos V5 authentication. Kerberos V5, the default method of network

authentication for services for computers running Windows 2000 server or client
software, is the primary security protocol for authentication within Windows 2000
domains. Based on Internet standard security, Kerberos V5 authentication is used with
either a password or a smart card for interactive logon. Kerberos provides fast, single
logon to Windows 2000 Server-based resources, as well as to other environments that
support this protocol.
The Kerberos V5 protocol verifies both the identity of users and of network services.
This dual verification, called mutual authentication, takes place between a client and
serverthe server verifies the client identity, and the client verifies the server's
identity. Kerberos replaces NTLM (see next subsection) as the primary security
protocol for access to resources within or across Windows 2000 Server domains. If
any computer involved in a transaction does not support Kerberos V5, the system uses
the NTLM protocol.
The Kerberos V5 authentication mechanism issues tickets for accessing network
services. A ticket, issued by a domain controller, is a set of identification data for
authenticating a security principle. Tickets contain encrypted data (including an
encrypted password) that confirms the user's identity to the requested service. Except
for entering a password or smart card credentials, the Kerberos authentication process
is invisible to the user. For a detailed technical description of Windows 2000 and
Kerberos (and for some information about NTLM), see the link to the "Windows 2000
Kerberos Authentication" white paper listed in "For More Information."

Windows NT LAN Manager (NTLM) authentication. NTLM authentication also

provides network authentication within Windows 2000 domains. In Windows 2000,
NTLM is used as the authentication protocol for transactions between two computers
in a domain, where one or both computers is running Windows NT 4.0 or earlier.
(Recall that by default, Windows 2000 is installed in a mixed-mode network
configurationthat is, a configuration that uses any combination of Windows NT 4.0
and Windows 2000.) NTLM is used when either the client or server uses an earlier
version of Windows. That is, computers with Windows 3.x, Windows 95/98, as well
as Windows NT Workstation 4.0 use the NTLM protocol for authentication in
Windows 2000 domains. NTLM is also the authentication protocol for computers not
participating in a domain, such as standalone servers and workgroups.
Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication.
SSL/TLS provides authentication when a user attempts to access a secure Web server.
SSL/TLS consists of four operations:
o

Handshake and cipher suite negotiations. Client and server contact each
other and choose a common cipher suite. The suite includes a method for
exchanging the shared secret key; a method for encrypting data; and a

Message Authentication Code (MAC) specifying how application data will be

hashed and signed to prove integrity.
o

User identity authentication. The server always authenticates its identity to

the client. However, whether the client needs to authenticate with the server
depends on the application. The exact authentication method (primarily, which
digital certificate format will be used) depends on the negotiated cipher suite.

Key exchange. After choosing a cipher suite, the client and server exchange a
key, or the precursors with which to create a key, that they will use for data
encrypting (again, depending on the negotiated cipher suite's requirements).

Application data exchange. The client application and the server application
communicate with each other. All data is encrypted using the negotiated bulk
encryption method.

Using Certificates to Authenticate External Users

Organizations must often support authentication of external users, individuals who do not
have an account in Active Directory. Examples of when you may want to provide external
users with secure access to specific data within the enterprise include corporate partners who
need extranet access, a department that needs access to another department's intranet pages,
or part of the public to whom you may want to provide selective access.
Active Directory supports external user authentication. To authenticate external users, you
must do the following:

Use a certificate. The external user must have a certificate. A certificate is a file used
for authentication and secure exchange of data on nonsecured networks, such as the
Internet. A certificate securely binds a public key to the entity that holds the
corresponding private key held by the individual. Certificates are digitally signed by
the issuing certification authority (CA) and can be managed for a user, a computer, or
a service.
The external user's certificate must be issued by a CA that is listed in the certificate
trust list for (or trusted by) the Active Directory site, domain, or organizational unit in
which you have created the user account.

Create a user account. You must establish a user account (for use by one or more
external users).

Map the certificate to the account. You must create a name mapping between the
external user certificate and the Active Directory account you have created for
authenticated access.

Any external user whose client program presents a mapped certificate can then access the
permitted locations published on the appropriate Web site for your organization. The
authentication process is transparent to the external user.
Top of page

User Authorization

Besides confirming the identity of anyone attempting to access the network (user
authentication, described in the preceding section), a good security system also protects
specific resourcessuch as payroll datafrom access by inappropriate users.
Active Directory secures resources from unauthorized access. From the standpoint of the
user, controlling access to resources, or objects, on the network is called user authorization.
From the standpoint of the object being protected, it is called object-based access control.
Once a user account has received authentication and can potentially access an object, the type
of access granted is determined by either the user rights that are assigned to the group (or
user) or the access control permissions that are attached to the object.
This section covers these topics in the following subsections:

User rights: Assigned to groups

Access control permissions: Attached to objects

User Rights: Assigned to Groups

As an administrator, you can assign specific user rights to group accounts or to individual
user accounts. You can think of them as user or group rights, rather than as simply user
rights, because typically you assign rights to a group rather than to an individual user. There
are two types of user rights:

Privileges. For example, the right to back up files and directories.

Logon rights. For example, the right to logon locally.

Note: Strictly speaking, logon rights, which refer to the local computer, do not belong in a
discussion of Active Directory. They are included here briefly for clarity, because they are
one type of user right. The other type of user right (privileges) can override permissions
assigned to Active Directory objects and are thus integral to this discussion.
User rights are different from permissions (described next) because user rights apply to user
accounts, whereas permissions are attached to objects.
Although user rights can apply to individual user accounts, to simplify the task of account
administration user rights are best administered on a group account basis. It is easier to assign
the set of user rights once to the group, rather than repeatedly assigning the same set of user
rights to each individual user account. To remove rights from a user, you remove the user
from the group.
Certain privileges can override permissions set on an object. For example, a user logged on to
a domain account as a member of the Backup Operators group has the right to perform
backup operations for all domain servers. However, this requires the ability to read all files on
those servers, even files on which their owners have set permissions that explicitly deny
access to all users, including members of the Backup Operators group. A user right, in this
case, the right to perform a backup, takes precedence over all file and directory permissions.

For a complete list of user rights (both privileges and logon rights), see "Appendix B: User
Rights."
Access Control Permissions: Attached to Objects

Access control is the process of assigning permissions to access Active Directory objects.
You can assign permissions for objects to the following:

Groups, users, and special identities in the domain

Groups and users in that domain and any trusted domains

Local groups and users on the computer where the object resides

Understanding access control permissions requires understanding the following interrelated

concepts:

Security descriptors
Object ownership

Object auditing

Object permissions and inheritance

Each of these topics is covered in the next subsections.

Security Descriptors
Windows 2000 implements access control by allowing administrators or owners of objects to
assign security descriptors to objects stored in Active Directory (or to other types of objects).
A security descriptor is a set of information attached to an object (such as a file, printer, or
service) that specifies the permissions granted to different groups (or users), as well as the
security events to be audited. For example, for the file temp.dat, you might grant Read, Write,
and Delete permissions to the Administrators group, but assign only Read and Write
permissions to the Operators group.
For Active Directory objects, in addition to controlling access to a specific object, you can
also control access to a specific attribute of that object. For example, you can grant a user
access to a subset of information, such as employees' names and phone numbers, but not
grant access to the employees' home addresses.
Each security descriptor for an object in Windows 2000 contains four security components:

Owner. By default, the owner is the creator of the object, except for objects created
by an administrator, in which case "Administrators" is the owner.
Discretionary Access Control List (DACL). As explained in the Introduction, the
DACL (often referred to as ACL) is a list of specific groups, user accounts, and
computers that are allowed or denied access to an object. To change a DACL, a
permission called WRITE_DAC is required.

System Access Control List (SACL). As explained in the introduction, the SACL
specifies which events are to be audited for which user or group. Examples of events
you can audit are file access, logon attempts, and system shutdowns. To read or
change the SACL, the SeSecurityPrivilege is required.

Group (for POSIX). The Group component is for POSIX compliance and is
associated with the "primary group" set in individual user objects in User Manager.
(POSIX is based on the UNIX operating system, but it can be implemented by other
operating systems.)

Each assignment of permissions to a group (or user) is known as a permission entry or access
control entry (ACE). An ACE is an entry in an access control list (DACL or SACL). The
entry contains a SID and a set of access rights. A process (running on behalf of a user) with
the user's access token that has a matching security ID is either allowed access rights, denied
rights, or allowed rights with auditing. The entire set of permission entries in a security
descriptor is known as a permission set. Thus, for the file temp.dat in the example above, the
permission set includes two permission entries: one for the Administrators group and one for
the Operators group.
Because the Active Directory security model associates a DACL and SACL with each of its
containers, objects, and object attributes, administrators can protect their network from
intentional hostile acts by attackers and inadvertent mistakes by users.
Permissions can be applied to any object in Active Directory or on a local computer, but, for
simplicity of administration, it is important to understand that the majority of permissions
should be applied to groups, rather than to individual users.
Object Ownership
Every Active Directory object has an owner. Windows 2000 assigns an owner to an object
when the object is created. By default, the owner is the creator of the object. The owner
controls how permissions are set for that object and to whom permissions are granted; that is,
the object's owner implicitly has the WRITE_DAC permission.
Administrators create and own most objects in Active Directory and on network servers
(when installing programs on the server). Users create and own data files in their home
directories, and some data files on network servers. Users may also own objects that they
have been allowed to create by way of delegation of administration; for example, users may
own computer objects that they join to the domain.
Object ownership can be transferred in the following ways:

The current owner can grant the Take Ownership permission to other users, allowing
those users to take ownership at any time.
An administrator can take ownership of any object under his or her administrative
control by using the Take Ownership privilege that administrators possess on
computers they control. For example, if an employee leaves the company, the
administrator can take control of the employee's files.

Object Auditing

Windows 2000 lets you audit users' attempts to access specific objects in Active Directory.
You can then view these security-related events in the security log with the Event Viewer.
Object Permissions and Inheritance
Object permissions, also called access rights, define the type of access granted to a group (or
user) for an object or object property. The permissions you can attach to an object vary with
the type of object. The following permissions, however, are common to all types of objects:

Read permissions
Modify permissions

Change owner

Delete

Two types of permissions exist:

Explicit permissions. Explicit permissions are attached directly to an object, either

when the object is created, or by user action. For example, if you create a folder called
Programs, the permissions attached to this folder are explicit permissions.

Inherited permissions. Inherited permissions are propagated to an object from a

parent object. Inherited permissions ensure consistency of permissions among all
objects within a given container, which eases the task of managing permissions. By
default, objects within a container inherit the permissions from that container when
the objects are created. For example, after you create the Programs folder, all
subfolders and files subsequently created within the Programs folder automatically
inherit the permissions from that folder. Thus, the Programs folder has explicit
permissions, while all subfolders and files within it have inherited permissions.

In addition, to provide more precise access control, two types of granularity exist:

Object-type permissions. Object-type permissions define the types of objects (for

example, an Active Directory object or a printer object) that a user or group is allowed
to create or delete.
Per-property permissions. For Active Directory objects, Windows 2000 also
supports per-property permissions. You can control not only who can see an Active
Directory object, but also who has, for example, Read or Write access to specific
object properties. Permissions for a single property are the finest level of granularity
you can set.

Object Types, Managers, and Tools

Each type of object is controlled by an object manager and is managed using a specific tool.
For example, to change the permissions on an Active Directory object, you use the Active
Directory Users and Computers tool. The following table shows each type of object, its object
manager, and its management tool:

Object Type

Object Manager

Management Tool

Active Directory
objects

Active Directory Active Directory Users and Computers

Files and folders

NTFS

Windows Explorer

Shares

Server service

Windows Explorer

Printers

Print spooler

Start menu, then select Settings, then Printers

Services

Service
controllers

Security Templates, Security Configuration and

Analysis

Registry keys

The registry

regedit32 command

A non-Active Directory object can also be represented by an Active Directory object by

publishing it in the Active Directory. For example, you can publish a print queue in Active
Directory and give only a certain group of users permission to find the queue in the directory.
However, the DACL on the print queue object in Active Directory controls only who can
read/write the print queue object in the directory; it does not imply anything about access to
the actual print queue resource on the print server.
(For more about object publishing, see the link to "Active Directory Architecture" in "For
More Information".)
Top of page
Summary

Active Directory works with the Windows 2000 security subsystem to ensure that only
authenticated users and computers can log on to the network and that each network resource
is available only to authorized users or groups.
The Windows 2000 operating system automatically assigns SIDs to Active Directory security
principalsuser and computer accounts as well as groupswhen they are created. Objects
with SIDs can log on to the network and can be given or denied access to domain resources.
Active Directory groups can contain users, contacts, computers, and other groups. Before you
create groups, you must first determine the number of domains you will have on your
network and which of those domains are native-mode and which (if any) are mixed-mode.
Windows 2000 has two group types. You use security groups to manage user, group, and
computer access to shared resources and to filter Group Policy settings. You use distribution
groups to create e-mail distribution lists.
Both security and distribution groups can have either local, domain local, global, or universal
scope. Each kind of scope differs in mode, membership, and permissions. You can make use

of this flexibility to build a group structure that fits the size and organizational requirements
of your business.
Windows 2000 user authentication is implemented as a two-part process: interactive logon,
which confirms the user's identity to the domain or to the local computer, and network
authentication, which confirms the user's identity to a network service when the user attempts
to access it. Windows 2000 interactive logon provides the user access to multiple applications
and services with a single sign-on, and its network authentication supports multiple
authentication protocols.
After a user account is authenticated, the type of access granted to the user to specific
network objects is determined by user rights, which are assigned to group (or user) accounts,
and access control permissions, which are attached to objects. Together, user authentication
and user authorization provide a strong, easy to administer security system for your network.
For More Information

For the latest information on Windows 2000 Server and Active Directory, check out the web
site at http://www.microsoft.com/windows2000/technologies/directory/ad/default.asp.
In addition, you can look at the following links for more information:
Active Directory Architecture white paper Active Directory structure, including objects,
domains, trees, forests, trusts, organizational units, and sites.
Secure Networking Using Windows 2000 Distributed Security Services white paper
Integration of Active Directory and Windows 2000 distributed security.
Microsoft Security Advisor WebsiteSecurity information.
Windows 2000 Group Policy white paperDetails of Windows 2000 group policy.
Windows 2000 Kerberos Authentication white paperInformation about Kerberos (and some
about NTLM).
See also the "Authentication," "Access Control," and "User Rights" chapters in Windows
2000 Resource Kit. The Windows 2000 Resource Kit is scheduled to be published by
Microsoft Press in the first half of the year 2000. The Resource Kit is also located on the
Windows 2000 Server and Advanced Server CDs as part of Support Tools.
Top of page
Appendix A: Built-in, Predefined, and Special Groups

Windows 2000 provides the following types of default groups:

Name
Built-in groups:

Scope

Located In

Domain Active

Purpose
You use built-in groups to assign

Account Operators
Administrators
Backup Operators
Guests
Print Operators
Replicator
Server Operators
Users
Predefined groups:
Group name
Cert Publishers
Domain Admins
Domain Computers
Domain Controllers
Domain Guests
Domain users
Enterprise Admins
Group Policy Admins
Schema Admins

local

Directory
Users &
Computers
tool's Built-in
folder

Active
Directory
Users &
Global
Computers
tool's Users
folder

Special identity groups:

n/a
Everyone (all current network
users).
Network users (users currently
accessing a given network
resource; a user becomes a
member of this group when the
user does a network logon to a
machine).
Interactive users (users currently
accessing a resource on the local
computer; a user becomes a
member of this group when the
user does an interactive logon to
a machine).
Authenticated users (users who
authenticate to one of the trusted
domains).
Service (service accounts used
by the service controller to start
services under specific accounts
become a member of this group).
Principal Self (special identity
that is replaced by the SID of the
security principal object (user,
group, or computer) during

default sets of permissions to users

who you want to have all or partial
administrative control in that
domain. For example, Backup
Operations can back up and restore
files & folders.
You use predefined groups to collect
users in this domain into Global
groups, and then you place the
Global group into Domain local
groups in this and other domains.
For example, because all users are
automatically added to the Domain
Users group, you can either assign
permissions to a printer to the
Domain users group or you can put
the Domain Users group into a
Domain local group that has
permissions for the printer.

(Not viewable Windows 2000 uses special

when you
identities to represent different users
administer
at different times, depending on
groups.)
circumstances. Although you do not
see special identities when
administering groups and cannot
place special identities into groups,
you can assign rights and
permissions to resources to special
identities.

Access Check; this wildcard SID

lets users and computers have
access to their own objects, and
lets members of a group have
permissions to the group).
Creator/Owner (special identity
that is replaced by the Owner
SID in the object's security
descriptor; this wildcard SID lets
the owner of the object
automatically have specific
access to the object.)
Top of page
Appendix B: User Rights

User rights are privileges and logon rights. You manage both types with the User Rights
policy. For a detailed description of each of the privileges and logon rights listed below, see
the "User Rights" chapter in the Windows 2000 Resource Kit.
The following list shows the privileges that can be assigned to a user or group:

Act as Part of the Operating System

Add Workstations to a Domain

Back Up Files and Directories

Bypass Traverse Checking

Change the System Time

Create a Token Object

Create Permanent Shared Objects

Create a Pagefile

Debug Programs

Enable Trusted for Delegation on User and Computer Accounts

Force Shutdown from a Remote System

Generate Security Audits

Increase Quotas

Increase Scheduling Priority

Load and Unload Device Drivers

Lock Pages in Memory

Manage Auditing and Security Log

Modify Firmware Environment Values

Profile a Single Process

Profile System Performance

Replace a Process-Level Token

Restore Files and Directories

Shut Down the System

Take Ownership of Files or Other Objects

Unlock a Laptop

The following list shows the logon rights that can be assigned to a user or group:

Access This Computer from Network

Log On Locally

Log On as a Batch Job

Log On as a Service

Deny Access to This Computer from the Network

Deny Logon as a Batch Job

Deny Logon as a Service

Deny Local Logon

The special user account LocalSystem has almost all privileges and logon rights assigned to
it, because all processes that are running as part of the operating system are associated with
this account, and these processes require a complete set of user rights.
02/00
Top of page
1 Some special purpose user accounts used by specific system services also exist
(such as IUSR_Servername, which is a built-in account for anonymous access to

IIS), but these special user accounts are not under consideration in this paper.
When a computer accesses the network, this means that system services
2 running on the computer in the LocalSystem context are accessing the network
resources.
If you place an external group (or user) directly into a Discretionary Access
Control Lists (DACLs), the security identifier (SID) of the user is added to the
3
DACL and, in this case, no foreign security principal object is created. Note that
putting individual users onto DACLs is not recommended.
The Windows 2000 operating system's global catalog is a database kept on one
4 or more domain controllers. The global catalog plays major roles in logging on
users (in a native-mode domain only) and in querying.
SAM is a protected subsystem of Windows NT and Windows 2000 that maintains
the security accounts management database and provides an API for accessing
the database. In Windows NT 4.0, both local and domain security principals are
5
stored by SAM in the registry. In Windows 2000, workstation security accounts
are stored by SAM in the local computer registry, and domain controller security
accounts are stored in Active Directory.

Best Practice Guide for Securing Active

Directory Installations and Day-to-Day
Operations: Part I
12 out of 15 rated this helpful - Rate this topic
Updated: February 28, 2004
By Kathleen Cole, Dave Kreitler, Doug Steen, Markus Vilcinskas

On This Page

Introduction
Chapter 1: Planning Active Directory Security
Chapter 2: Establishing Secure Active Directory Boundaries
Chapter 3: Deploying Secure Domain Controllers
Chapter 4: Establishing Secure Domain and Domain Controller Policy Settings
Chapter 5: Establishing Secure Administrative Practices
Chapter 6: Securing DNS
Appendix: Procedures
Introduction

Organizations require a network operating system (NOS) that provides secure network access
to network data by authorized users and that rejects access by unauthorized users. For a
Microsoft Windows 2000 NOS, the Active Directory directory service provides many
key components that are needed for authenticating users and for generating authorization data
for controlling access to network resources.
A breach in Active Directory security can result in the loss of network resource access by
legitimate clients or in the disclosure of potentially sensitive information. Such information
disclosure can occur for data that is stored on network resources or from the Active Directory
database itself. To avoid these situations, organizations need more extensive information and
support to ensure enhanced security for their NOS environments. This guide addresses this
need for organizations that have new, as well as existing, Active Directory deployments.
A comprehensive plan for Active Directory security requires action in five areas:

Protection of domain controllers against known threats

Administrative policies and practices to maintain security

Detection of attacks that have not been identified or mitigated previously

Defense against Active Directory attacks

Recovery from Active Directory attacks

The Best Practice Guide for Securing Active Directory Installations and Day-to-Day
Operations comprises two parts. Part I of the guide, which is presented here, contains
recommendations for protecting domain controllers from potential attacks of known origin
and recommendations for establishing secure administrative policies and practices. Part I
addresses Active Directory security issues by providing guidelines for maintaining Active
Directory security boundaries, enhancing domain controller security, and securing Active
Directory administration.
This guide also includes scripts, procedures and templates needed to enact these
recommendations.
Note:
Recommendations and procedures in this guide have been tested in a lab to demonstrate that
domain controllers that are built, configured, and administered in accordance with these
recommendations can be deployed and operated in an efficient manner that enhances security.
Part II of the guide, which will be issued shortly after Part I, contains recommendations for
detecting attacks, defending against known and unknown threats, and recovering from
attacks.
Scope of This Guide

Although NOS security relies on secure design principles and operating practices for all
components in the operating system, the scope of this guide is limited to recommendations
and explanations for deploying and operating Active Directory domain controllers. Other
security topics, such as secure network connectivity and secure clients, are not addressed in
this guide.
Part I of this guide provides guidelines for Active Directory deployment and administrative
practices that are designed to maintain a secure operating environment. These guidelines,
which can be applied to both new and existing Active Directory infrastructures, are organized
into the following chapters:

Planning Active Directory Security

Establishing Secure Active Directory Boundaries

Deploying Secure Domain Controllers

Establishing Secure Domain and Domain Controller Policy Settings

Establishing Secure Administrative Practices

Securing DNS

The recommendations in this guide take into consideration how an organization's domain
controllers are deployed. Domain controllers can be deployed in datacenters for enterprise
intranets, in branch offices, and in datacenters for extranets. In some cases, the guidelines
vary in accordance with special circumstances that are encountered in each environment.
Audience

This guide is intended primarily for IT planners, architects, and managers who are
responsible for establishing Active Directory deployment and operations practices. As a
result, this guide emphasizes the decision-making process, rather than procedures.
How to Use This Guide

The information in this guide is presented as if the reader's organization is planning its Active
Directory deployment and operations. However, this information can be equally beneficial to
an organization that is reviewing its current Active Directory security practices.
You can proceed through the Active Directory security planning process in the order
presented in this guide. Each phase of the Active Directory security planning process, such as
deploying secure domain controllers, is contained in its own chapter. Each chapter begins
with a discussion of how the security recommendations enhance security, and it also
discusses their cost in terms of complexity and performance. If a recommendation is
impractical for a specific deployment strategy, that is indicated, and specific alternatives are
recommended, if they exist. Finally, the recommendations in each chapter are summarized in
a checklist at the end of the chapter.
You can proceed to the next chapter after completing the checklist of recommendations at the
end of the previous chapter. Before proceeding with security planning, make sure that you:

Set your business goals and practices and understand how they affect Active Directory
security.

Gain executive-level sponsorship to implement a secure, Active Directory-managed

Windows network.

Active Directory infrastructure and practices can span both technology and business areas.
Therefore, to make progress in security planning, you must articulate the value of security to
IT and business decision makers.
The Role of Active Directory in Secure Access

Windows requires verification of every user's identity before it allows access to network
resources. The process of verifying the identity of users, also known as authentication, is part
of the logon process. The process of granting or denying access to a resource is called
authorization. During authentication, all entities identify themselves to the security system by
means of a unique user ID. Active Directory stores security-related identity information for
users, as well as their credentials (such as passwords), in the form of a user account object.
The system generates a unique security identifier (SID) for every account object that can be
authenticated or authorized for access to resources. Every SID contains the identifier of the
domain in which the object resides.

Objects with a SID are also known as security principals. The following types of objects act
as security principals:

User: a person or a service that requires user credentials

Computer: a workstation or server running Windows

Group: a set of users, computers, or other groups

After Active Directory confirms the identity of the user, the security system on the
authenticating domain controller generates partial authorization data in the form of the user's
primary SID, plus SIDs for groups to which the user belongs that are recognized by all the
resources on the Windows network. The remainder of the authorization data is generated at
the time that the user requests access to a specific network resource, such as a server, file
share, or directory object. The authorization data is used by the computer that houses the
network resource to generate an access token that consists of the list of SIDs representing the
user, all groups (including nested groups) that the user is member of, and the user's privileges
(also called user rights) on the local computer. The access token is used to determine the level
of access that the user has on the network resource.
All objects or resources that are secured have a discretionary access control list (DACL)
assigned to them that specifies the access rights of users and groups on that resource. Access
to one of these objects or resources is gated by an access check, in which the security system
evaluates the content of the access token of the requestor against the DACL on the resource
to determine if the requested access should be granted or not. This process is also known as
access control or authorization.
Planning for Active Directory Security in Depth

A security strategy for an enterprise is most effective when data is protected by more than one
layer of security. With this type of strategy, the potential losses that might be caused by a
security failure in any single layer are minimized by the remaining security layers. For
example, when a home is protected by both door locks and a security system, the homeowner
is implementing a security-in-depth strategy that is more effective than either of these
security features alone.
A security-in-depth approach first divides all security elements into discrete security layers.
This way, the security effectiveness of each layer can be independently determined, and a
security plan can be implemented. Figure 1 shows one way of visualizing the relationships
among these security layers for Active Directory.

Figure 1

Security in Depth for Active Directory

Active Directory security policies and practices can be divided into the following layers:

Physical security for domain controllers and the network (physical access to domain
controllers, backup data, and network components)
Administrative authority (security management and secure administrative practices)

End system (domain controller settings, policy settings, and deployment practices)

This guide provides recommendations for security best practices that are based on security in
depth. This guide is organized along the lines of the security layers for secure deployment of
domain controllers, including physical security, domain and domain controller policies, and
administrative practices.
Process for Securing Active Directory Installations and Operations

This guide focuses solely on the deployment and operation recommendations for creating a
secure Active Directory system. Figure 2 depicts the process flow for these recommendations.

Figure 2

Process Flow for Securing Windows 2000 Active Directory

Part I and II in the flowchart correspond to Parts I and II of this guide.

Part I of the process is designed to create a secure domain controller environment. In
addition, because Domain Name System (DNS) is an integral component of Active Directory,
this guide also includes policies and practices for DNS on a domain controller.
Part II of the process is designed to help maintain a secure Active Directory infrastructure.
This includes a list of day-to-day security operations to perform, specific events and
resources to monitor, administrative activities to audit, and how to detect and respond to an
attack. Finally, in the case of a security attack damaging some portion of the Active Directory
infrastructure, Part II provides recommendations for system recovery.
Top of page
Chapter 1: Planning Active Directory Security

The goal of this guide is to assist organizations in enhancing the security of their Active
Directory systems. However, any guide that addresses a general audience can provide a
security foundation only in the form of guidelines. In some instances, these guidelines may

conflict with the needs of an organization to lower costs, provide services and line-ofbusiness (LOB) applications, or maintain an IT infrastructure. In such cases, an organization's
security planning team can evaluate these other needs against the need for security, to arrive
at suitable tradeoffs.
Evaluating the need for Active Directory security against other business needs of an
organization depends on the type of operating environment in which the domain controllers
are deployed. The three most common operating environments in which domain controllers
are deployed (that is, the three most common deployment scenarios for domain controllers)
are described in the following section.
Deployment Scenarios for Domain Controllers in a Secure NOS

The three most common deployment scenarios for domain controllers deployed in a secure
network operating system (NOS) are as follows:

Datacenter for an intranet

Branch office

Datacenter for an extranet

The way in which domain controllers are deployed in an organization can, in some cases,
affect the feasibility of implementing the Active Directory security guidelines that are
presented in this guide. Each set of guidelines includes a discussion, where appropriate, of
how the deployment model affects the cost and logistical difficulty of implementing the
recommendations.
Domain Controllers in Intranet Datacenters

The datacenter for an enterprise intranet is possibly the most common domain controller
deployment scenario, and it is the easiest scenario in which to deploy and administer domain
controllers. Intranet datacenters normally possess most, if not all, of the following
characteristics:

Fast, high-bandwidth network connectivity among all domain controllers

Centralized, secure facilities for housing and managing domain controllers

Facilities for building and configuring domain controllers

Facilities for testing hardware, operating systems, and policies

Centralized, dedicated IT and security staff with defined administrative roles

Facilities for monitoring and auditing domain controllers

Larger organizations may contain more than one datacenter to support regional business
operations. Each datacenter is likely to have its own IT and security staff.

Figure 3 represents one possible datacenter design for a medium-sized organization with
facilities in two regions. Each datacenter services intranet and remote clients in its region.
Connectivity requirements among datacenters vary in accordance with an organization's
business needs and its Active Directory infrastructure design.

Figure 3

Domain Controllers in Intranet Datacenters

Of the three domain controller deployment scenarios, the intranet datacenter most readily
supports the requirements of a managed environment. IT staff members are generally on-site;
therefore, access to the datacenter and to administrative tasks can easily be restricted to them.
In addition, monitoring and troubleshooting of domain controller problems is simplified, and
attacks can be quickly detected and handled.
Intranet datacenters also possess a high degree of manageability. Intranet datacenter
deployments generally include the following management characteristics:

Centrally designed and managed domain controller and administrative policies

Written administrative practices for building, deploying, and managing domains and
domain controllers

Domain Controllers in Branch Offices

An organization with a large number of locations, each with limited number of users and
servers, may still require local network access to a domain controller for authentication and
authorization at each location. Branch office deployments normally possess most, if not all,
of the following characteristics:

Slow, intermittent connectivity to other domain controllers outside the branch office
Domain controllers sharing a subnet with users and computers

Domain controllers hosting other applications or infrastructure services, such as

Windows Internet Name Service (WINS) and Print Services

Lack of dedicated, secure facilities for housing and managing domain controllers

Lack of local, dedicated IT staff

Figure 4 shows a design for domain controllers in branch offices.

Figure 4

Domain Controllers in Branch Offices

Of the three domain controller deployment models, the branch office presents the greatest
challenges in supporting the requirements of a secure, managed environment. IT staff
members are generally off-site; therefore, all administrative tasks cannot easily be restricted
to them. In addition, restricting physical access to the domain controllers can be difficult.
Detecting and responding to domain controller problems and attacks can be slow and costly.
Another challenge that the branch office model presents is manageability. Branch office
deployments generally include the following management characteristics:

Decentralized domain controller management or remote management of these domain

controllers by administrators in the datacenter

Lack of uniformity in the application of domain controller management and

administrative practices

Domain Controllers in Extranet Datacenters

The extranet datacenter scenario is a variation of the intranet datacenter. Like intranet
datacenters, extranet datacenters normally possess most of the following characteristics:

Fast, high-bandwidth network connectivity among all domain controllers

Centralized, secure facilities for housing and managing domain controllers

Facilities for building and configuring domain controllers

Facilities for testing hardware, operating systems, and policies

Centralized, dedicated IT and security staff with defined administrative roles

Facilities for monitoring and auditing domain controllers

Domain controllers in extranet datacenters fulfill two primary functions. First, they can be
used to manage servers and resources within the extranet. Second, they can be used to
authenticate customers and partners (outward-facing) and to provide them with access to
resources within the extranet. Additional characteristics that most extranet datacenters
possess include the following:

Firewalls that restrict Internet traffic into the datacenter

Firewalls that prevent users in the datacenter from accessing the corporate network

Customers and partners tunneling into the extranet from outside the network

Figure 5 illustrates domain controllers in extranet datacenters.

Figure 5

Domain Controllers in Extranet Datacenters

In addition to the management characteristics of intranet datacenters, extranet datacenters

may have administrators managing accounts within the extranet itself, or they may have
accounts in the enterprise intranet that are used to manage the extranet.
Security Planning

This guide concentrates primarily on recommendations for minimizing known security

threats to Active Directory. However, the following sections provide a short summary of how
threat analysis can be used to create a security plan, based on the security features in
Windows 2000.
Figure 6 illustrates how a threat analysis fits into an overall security plan.

Figure 6

Process for Planning Active Directory Security

Making Active Directory deployment and administration secure encompasses planning for
both mitigation (proactive security) and contingency (reactive security). The proactive
portion of the plan protects assets by alleviating any threats to the system that might be
caused by user mistakes and by attacks based on known threats. The reactive portion of the
plan provides contingency plans to implement under the following conditions:

Threat analysis fails to anticipate a threat.

It is not possible to completely mitigate a threat.

Security recommendations cannot be implemented.

Identifying Types of Threats

In their attempts to breach a system's security, all threats exploit weaknesses in the operating
system, applications, network design, security policies, or administrative practices. In
addition, social engineering phenomena pose a threat to Active Directory. Threats are
commonly categorized according to the goal of the attack. This type of threat analysis is
referred to by the acronym STRIDE, which is derived from the first letter of each category of
threat. These threats are explained in the following sections.
Spoofing

The goal of a spoofing attack is illicit access to network resources by unauthorized users.
Spoofing involves forging the identity of a valid system user or resource to get access to the
system, thereby compromising system security. Spoofing attacks include the following:

Changing the identity that is associated with an Active Directory object

Subverting a secure logon mechanism

Using false credentials

Tampering with Data

The goal of a data-tampering attack is to cause unauthorized modification of data, resulting in

a loss of data integrity. This type of attack modifies system or user data, with or without
detection, resulting in unauthorized changes to network information, network packets in a
communication, sensitive files, or the formatting of a hard disk. Data-tampering attacks
include the following:

Modifying data that should not be accessible

Causing a trusted entity to modify data improperly

Creating an elevation-of-privilege attack that allows a user to tamper with data

Repudiation

The goal of a repudiation attack is to perform an authorized or unauthorized action and to

eliminate any evidence that could prove the identity of the attacker. Repudiation attacks are
associated with users who can deny wrongdoing, without any way to prove otherwise.
Repudiation attacks include the following:

Circumventing the logging of security events

Tampering with the security log to conceal the identity of an attacker

Information Disclosure

An information-disclosure risk exists if a user can gain access to data, intentionally or

otherwise, that the user is not authorized to see, resulting in the loss of data privacy and
confidentiality. Information disclosure attacks include the following:

Accessing data that is considered private and protected

Sniffing data on a network while in transit

Using social engineering to improperly reveal user identity or passwords

Denial of Service

The goal of a denial-of-service attack is the loss of access by legitimate users to a server or
service. Generally speaking, denial-of-service attacks occur when a malicious user either
disables critical services on a computer or consumes so many resources on a system that no
resources are available for legitimate users. The resources that can be exhausted include CPU
cycles, disk space, memory, server connections, or network bandwidth, among others.
Denial-of-service attacks include the following:

Consuming CPU cycles by infinite or very long programmatic looping

Consuming excessive memory or file quotas to block legitimate use

Causing a crash, restart, or error mechanism to interfere with normal use

Elevation of Privilege

The goal of an elevation-of-privilege attack is illicit access to network resources or services

by unauthorized users. The most severe form of an elevation-of-privilege attack is a situation
in which an attacker effectively penetrates all system defenses. The attacker then becomes
part of the trusted system itself and can completely compromise or destroy the system.
Elevation-of-privilege attacks include the following:

Improperly gaining unrestricted rights

Running untrusted data as native code in a trusted process

Spoofing a more privileged identity to gain elevated privileges

Social Engineering

Social engineering represents any type of behavior that can inadvertently aid an attacker in
gaining access to a user's password. Examples include someone in the organization doing the
following:

Writing his or her password and placing it in a location where a coworker could find it
Coaxing a fellow worker into revealing his or her password

Befriending a janitor with physical access to domain controllers

Identifying Sources of Threats

Identification of the various sources of threats to Active Directory provides a basis for
understanding and creating an effective security plan. Active Directory defines groups of
users, and by default it installs policies that limit access of the user groups to network
resources and services. Therefore, each user group represents a different source of threat, as
indicated in Table 1.
Table 1 Sources of Potential Threat to Active Directory
Source

Description of Source and Threat

Represents unauthenticated access to the network that is enabled when
Group Policy settings allow anonymous access and when permissions on
resources are set to allow Everyone access. Supports earlier versions of
clients, such as servers running Microsoft Windows NT, when they
require information from Active Directory to perform their functions.

Anonymous users
Allowing access for anonymous users results in a reduced level of
security for Active Directory, because unauthorized access to Active
Directory information can result in information disclosure. See
"Selecting Policy Settings for Mixed Operating System Environments."
Represents any user who has successfully completed the authentication
Authenticated users process. This implies that the user has an identity in the domain or in a

trusted domain and has provided valid credentials.

Service
administrator

Data administrator

Authenticated users can, by default, access information in the directory

and on domain controllers, and they can view system logs. To enhance
Active Directory security against information disclosure, unnecessary
access should be eliminated. See "Establishing Secure Domain
Controller Policy Settings."
Represents administrative accounts that are used legitimately to control
directory service configuration and policies and to have physical access
to domain controllers to manage server administration. Also used to
control the forest infrastructure by creating or removing domains and
domain controllers, managing domain and domain controller
configuration, and monitoring domain controller health.
Service administrators are in a position to launch attacks throughout the
forest, and therefore they must be highly trusted. See "Trusting Service
Administrators."
Similar to Windows NT administrators in their functions and privileges,
this group supports managing data in Active Directory that does not
control the directory service or its configuration. Supports users and
computers in the forest by adding and removing organizational units
(OUs), computers, users, and groups and by modifying Group Policy
settings.
Data administrators have delegated rights to manage objects in domain
organizational units (OUs) but not to manage domain controllers or
forest configuration. See "Specifying Security and Administrative
Boundaries."

Applies to any situation in which an individual accesses the area where

domain controllers and administrator workstations reside or to a situation
Users with physical
in which an individual steals one of these computers. If an unauthorized
access to domain
individual gains access to these computers, which contain sensitive data,
controllers
information disclosure or data tampering is possible. See "Maintaining
Physical Security."
Top of page
Chapter 2: Establishing Secure Active Directory Boundaries

Active Directory provides an infrastructure that can support an organization's need for
isolation and autonomy, while enabling collaboration among people and organizations. IT
planners must determine precisely their need for isolation, autonomy, and collaboration;
understand the security implications of delegating administration; and be aware of the
tradeoffs in a directory infrastructure.
Specifying Security and Administrative Boundaries

The Active Directory forest represents the outermost boundary within which users,
computers, groups, and other objects exist. Active Directory domains, unlike Windows NT
domains, are always part of a forest. They are the boundaries for administration and security

policies. This means that policies, such as password complexity and password reuse rules,
cannot be inherited from one domain to another. Each Active Directory domain is
authoritative for the identity and credentials of the users, computers, and groups that reside in
that domain.
Important:
Previously published Active Directory documentation states that a domain is a security
boundary, but this documentation does not provide specific details about the level of
autonomy and isolation that is possible among domains in a forest. Although a domain is, in
fact, a security boundary with regard to the management of security policies for Active
Directory, it does not provide complete isolation in the face of possible attacks by service
administrators.
Delegating Administration

Organizations typically delegate the administration of all or part of the Active Directory
service or the data that is stored in their domains. Table 2 lists the reasons for delegating
administration.
Table 2 Reasons to Delegate Administration
Reasons
Organizational

Operational

Explanation
One part of an organization may want to share an infrastructure to reduce costs
but require operational independence from the rest of the organization.
One part of an organization or a single application may place unique
constraints on the directory service configuration, availability, or security.
Examples include:

Military organizations
Hosting scenarios

Extranet-based directory services

Some organizations have legal requirements that compel them to operate in a
specific manner, such as restricting information access. Examples include:

Legal

Financial institutions
Defense contractors

Government organizations

For these reasons, an organization may need to delegate control over service management,
data management, or both. The goal of delegation is to achieve either autonomy or isolation.
Autonomy is the ability of administrators to independently manage part or all of the Active
Directory service or the data in the directory or on member computers. Isolation is the ability
of administrators to prevent other administrators from interfering in or accessing part or all of
the Active Directory service or the data in the directory or on member computers.

For a complete discussion of service and data administrator roles, see "Comparing Service
and Data Ownership" in "Part I: Determining the Number of Forests in Your Organization" of
Best Practice Active Directory Design for Managing Windows Networks on the Microsoft
Web site at http://go.microsoft.com/fwlink/?LinkId=18583.
An organization's requirements for service autonomy, data autonomy, service isolation, and
data isolation determine the Active Directory infrastructure that is best suited to its needs. The
first step is to define precisely the needs of your organization.
Active Directory boundaries can assist an organization in achieving the level of autonomy
and isolation that its business units require. Table 3 provides a comparison of the
characteristics of administrative autonomy and isolation.
Table 3 Comparison of the Characteristics of Autonomy and Isolation in
Administration
Administrative
Role

Autonomy Means to...

Isolation Means to...

Service
administrator

Manage independently all or part Prevent other service administrators from

of service administration (service controlling or interfering with service
autonomy).
administration (service isolation).

Data
administrator

Prevent other data administrators from

Manage independently all or part
controlling or viewing data in the
of the data that is stored in the
directory or on member computers that
directory or on member
are joined to the directory (data
computers (data autonomy)
isolation).

Autonomy is less constrained than isolation. Administrators who require only autonomy
accept the fact that other administrators of equal or higher privilege in the system have
equivalent or overriding control in the forest. Because autonomy is less constrained than
isolation, it is generally less costly and more efficient to delegate administrative autonomy.
Autonomy can be achieved by delegating service or data administration. Isolation requires
that a business unit deploy a separate forest to contain its administrators, users, and resources.
Multiple forests in an organization require external trusts to support collaboration. These
trusts are discussed further in "Establishing Secure Collaboration with Other Directories"
later in this guide.
Trusting Service Administrators

Before choosing an Active Directory delegation model, consider the following facts about
Active Directory administrative roles:

Forest owners maintain the right to control domain-level services and to access data
that is stored on any domain in the forest.

Domain owners maintain the right to access data that is stored on the domain or on its
member computers.

Domain owners, although operating autonomously from forest owners and other
domain owners, cannot prevent a malicious domain owner from controlling their
services and accessing their data.

This high degree of collaboration and trust that is required among the authorities that are
responsible for the management of domains in a forest necessitates that all administrators
who manage domains be highly trusted. Therefore, Active Directory domains in a forest
should never be deployed with the objective of isolating business units that do not trust each
other.
To summarize the facts concerning directory structures and directory structure owners, for an
organization to join a forest or domain infrastructure, it must choose to trust all service
administrators in the forest and in all domains. Trusting service administrators means to:

Believe that service administrators look out for the organization's best interest.
Organizations should not elect to join a forest or domain if the organization fears that
the owner of the forest or domain might behave maliciously.
Believe that service administrators follow best practices for service administrators and
for restriction of physical access to domain controllers.
Understand and accept the risks to the organization that are associated with rogue
administrators and coerced administrators.

Selecting an Active Directory Structure Based on Delegation

Requirements

The following steps can assist you in determining if your organization's specific delegation
requirements justify delegating control of a separate forest, domain, or organizational unit
(OU):
1. Begin by placing all organizations in a single-domain forest.
2. For each business unit with unique administrative requirements, determine the
appropriate level of autonomy, based on the autonomy and isolation characteristics in
Table 3.
3. When recording the justification for each decision, note whether:
o

Delegation is driven by an organizational, operational, legal, or other

requirement, as defined in Table 2.

The requirement pertains to delegation of service management, data

management, or both.

The requirement indicates the need for autonomy, isolation, or both.

For additional assistance in planning Active Directory delegation of administration, see

"Design Considerations for Delegation of Administration in Active Directory" on the
Microsoft TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=10516.
Implications for Active Directory in Extranet Deployment

Outward-facing domain controllers in an extranet are in a portion of the network where

customers and partners can access network resources through the Internet. As a result of the
Internet exposure, any information about the corporate forest that is placed in the extranet is
subject to the risks of information disclosure or data tampering by external users. Further, a
breach of service administration security in the extranet can be used to breach the corporate
intranet, if there is no service isolation boundary.
To mitigate the risks previously discussed, Active Directory implementations in an extranet
should maintain complete service isolation from the rest of the organization. Therefore, a
separate Active Directory forest should be implemented for the extranet. Any service
administrator with responsibilities that span the corporate forest and the extranet forest should
have a separate administrative account in each forest.
Establishing Secure Collaboration with Other Directories

External trusts between domains are created to support collaboration between domains in
different forests for a variety of reasons, including:

Organizational mergers and acquisitions

Limited collaboration between isolated forests within an organization

Shared applications that are accessed from an application forest

Collaboration between domains in different forests can range from simply sharing e-mail to
providing access to data and resources. External trusts in Active Directory extend the use of
security principals that are created in one domain of a forest to domains in other forests.
However, external trusts introduce a potential security risk, because they cross security
boundaries. External trusts, therefore, have security implications that require careful
consideration.
Establishing External Trusts

Although domains that do not mutually trust one another cannot reside in a single forest,
domains in different forests can selectively choose to trust one another. A number of
scenarios, including the need for service isolation, can result in an organization or partnership
spanning multiple forests. A domain administrator in one forest can manually create external
trust relationships with domains in other forests. In some cases, plans may call for
maintaining separate forests with trust relationships to facilitate collaboration. In other cases,
plans may exist to merge forests eventually. In the case of either migration or collaboration,
trust relationships linking domains in different forests may be necessary.
Because every security principal has a unique security identifier (SID) that is relative to the
domain in which the security principal is created, it is not possible to move the security
principal between domains when an account migration is required. Such a move requires that

the security principal be recreated in the new domain, and therefore it must be assigned a new
SID. To preserve access to all the applications, services, and resources that are in place for the
migrated user, Active Directory provides an attribute for user objects and group objects called
SIDHistory.
SIDHistory is a multivalued attribute that contains the list of SIDs previously assigned to a
user or group. These SIDs become part of the authorization data that is forwarded to a
trusting domain through an external trust.
When a user logs on to a domain, the user's primary SID and the SIDs of groups of which the
user is a member are determined by a domain controller in the user's account domain. If the
authenticating domain controller is running Windows 2000 in native mode, it also determines
if the user has any values present in the SIDHistory attribute, and it includes those SIDs in
the authorization data. From the access control perspective, these SIDs are no different from
other group SIDs, which gives the user access to resources to which those groups have
access.
Blocking SIDs from Untrusted Sources

By design, a Windows 2000 domain controller expects any domain controller in a trusted
domain to provide the correct authorization data for a user from that trusted domain. In the
process, the domain controller in the trusting domain accepts all the SIDs that are returned
during authentication, based on the trust relationship.
Accepting all SIDs exposes the trusting domain to potential security threats, because:

Although the authenticating domain may be trusted, a user's SIDHistory might

contain SIDs based on other domains that are not trusted.
If a properly chosen SID can be added to a user's SIDHistory, that user can gain
unauthorized access to resources in the trusting domain, including administrative
privileges, which constitutes an elevation-of-privilege threat.
Note:
Exploiting this vulnerability would be a challenge. At a minimum, an attacker needs
administrative credentials on the trusted domain and the technical ability to modify
low-level operating system functions and data structures. Microsoft is not currently
aware of any programming interface that allows an attacker - even one with
administrative credentials - to introduce a SID into SIDHistory.

To mitigate the threat posed by SIDHistory, the domain controllers in the trusting domain
should filter authorization data to remove any SIDs that are not relative to the user's account
domain. The trusted domain in this case is said to be quarantined. Quarantining is performed
from the trusting domain on a per domain (and, therefore, per external trust) basis. The
trusting domain should only quarantine domains residing in a different forest.
Important:
You should not attempt to use the SID filtering feature to create a "restricted-access" domain
within a forest. Enabling SID filtering between domains in the same forest disrupts the
default trust and authentication behavior of a forest, and it is likely to lead to problems with
programs and the Active Directory service itself that are difficult to troubleshoot.

Unfortunately, SID filtering may cause users in a trusted domain that were migrated to the
trusted domain to lose access to resources, because SID filtering prevents users from
accessing resources if the access is based on a previous domain account SID. To eliminate
this issue, the access control lists (ACLs) on resources should be updated as soon as possible
to preserve resource access for migrated users.
The procedure for "Enabling SID Filtering" is included in "Appendix: Procedures" later in
this guide.
For more information about applying SID filtering, see the following articles in the Microsoft
Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=16462:

Q289243, "Forged SID Could Result in Elevated Privileges in Windows 2000"

Q289246, "Forged SID Could Result in Elevated Privileges in Windows NT"

Recommendations: Establishing Secure Active Directory Boundaries

To help maintain secure Active Directory boundaries, consider implementing the security
recommendations that are described earlier in this section. The following tables contain
checklists that summarize the security recommendations for establishing and maintaining
secure Active Directory boundaries in Windows 2000.
Recommendations for Specifying Security and Administrative Boundaries

The following table provides a checklist of recommendations that are related to security and
administrative boundaries.
Check

Determining Your Organization's Need for Delegation of Administration

Delegate Active Directory administration in accordance with your organization's need
for autonomy and isolation.
Place outward-facing domain controllers that are deployed in an extranet in a separate
forest.

Recommendations for Establishing Secure Collaboration with Other Directories

The following table provides a checklist of recommendations for creating secure trusts with
domains in other forests.
Check

Establishing External Trusts and Blocking SIDs from Untrusted Sources

Enable SID filtering when you create an external trust between domains in isolated
forests.

Top of page

Chapter 3: Deploying Secure Domain Controllers

The Active Directory executables and database are stored on the domain controllers in your
Active Directory infrastructure. The domain controllers are the servers in your network
infrastructure that you must secure to protect Active Directory. If the security of any domain
controller in your Active Directory infrastructure is compromised, the entire Active Directory
security is at risk.
An essential part of deploying your domain controllers is ensuring that they are deployed
securely. If you are in the process of deploying your domain controllers, the steps in this
section include recommendations for deploying your domain controllers in a manner that
enhances their security. If you have already deployed your domain controllers, consider
whether to configure your existing domain controllers to reflect the security
recommendations in this section.
To deploy secure domain controllers, perform the following tasks:
1. Establish secure domain controller build practices.
2. Ensure predictable, repeatable, and secure domain controller deployments.
3. Enable only essential services.
4. Secure domain controller files and executables.
5. Run virus scans on domain controllers.
6. Maintain physical security.
Establishing Secure Domain Controller Build Practices

One of the essential practices in deploying secure domain controllers is building the domain
controllers in as secure an environment as possible. Building the domain controllers is the
process of installing the Windows 2000 Server operating system and then promoting the
server to a domain controller. The physical environment and the method that you use for
building domain controllers influence the security of the domain controllers.
Secure domain controller build practices include the following:

Securing the domain controller build environment

Selecting secure domain controller build methods

Securing the Domain Controller Build Environment

The domain controller build environment is the network environment (routers, network
segments, switches, and so forth) and physical room (datacenter, secured room, wiring closet,
utility closet, and so forth) in which you build your domain controllers. Depending on your
IT organizational infrastructure, you may have a centralized datacenter that is secure, both
from a network perspective and physically. On the other hand, your IT organization

infrastructure may have locations that are not secure from either perspective, such as branch
offices.
Building Domain Controllers in Datacenter Environments

Whenever possible, build your domain controllers in a secure environment, such as a

datacenter. Building your domain controllers in a secure datacenter environment reduces the
security risks by restricting domain controller access to trusted personnel during the critical
build process. This helps to prevent rogue applications, drivers, services, or configurations
from being introduced by unauthorized personnel.
If possible, build domain controllers in the datacenter environment, and then ship them to the
final location for deployment. This deployment approach is referred to as a staged domain
controller deployment.
To help ensure that the domain controller stays secure until deployment, ship the domain
controller to the final location using a trusted shipping method, for example, one that requires
signatures for the domain controller at the origination and destination locations. Building and
shipping the domain controller in this way enhances the integrity of the domain controller.
For more information about building (staging) domain controllers, see the "Active Directory
Branch Office Planning Guide" on the Microsoft Web site at http://go.microsoft.com/fwlink/?
LinkID=3459.
Building Domain Controllers in Branch Office Environments

If your organization supports branch offices, in some instances you may need to build a
domain controller in this relatively insecure environment. For example, you may need to
replace a failed domain controller on-site. Table 4 lists recommendations and the
corresponding rationales for building domain controllers in branch offices.
Table 4 Recommendations for Building Domain Controllers in Branch Offices
Recommendation

Rationale

To avoid the theft of directory data or the possibility of

Limit physical access to domain
an altered, less secure domain controller configuration
controllers to trusted personnel only. through human intervention, domain controllers should
not be left unattended.
Use an automated method for
operating system installation and
Active Directory promotion.

Domain controllers should be promoted using an

automated script to reduce the possibility of human
intervention, which could result in a vulnerable domain
controller configuration.

Promote and operate new domain

controllers in a restricted access
area.

To prevent unauthorized users from compromising the

domain controller's security, the domain controller
should be physically located in a room with restricted

access.
Selecting Secure Domain Controller Build Methods

Automating the build process for domain controllers minimizes the possible introduction of
rogue programs, rogue services, and insecure configuration into the build process through
manual intervention. Automating the installation of Windows 2000 Server helps to ensure a
secure platform on which to run Active Directory. Automate the promotion of a server to a
domain controller through the use of the Active Directory Installation Wizard (Dcpromo.exe)
to ensure that Active Directory is configured in a secure and consistent manner.
Automating the Windows 2000 Installation Process

Automated installation processes for Windows 2000 Server can be categorized as imagebased and non-image-based. Because non-image-based methods can affect the integrity and
predictability of the installation process as a result of the need for manual intervention, we
recommend using only image-based methods for installing Windows 2000 Server.
When using an image-based process to install Windows 2000 Server, perform the following
tasks:
1. Create a clean installation of Windows 2000 Server.
2. Configure server security as specified in the following sections, which appear later in
this guide:
o

"Ensuring Predictable, Repeatable, and Secure Domain Controller

Deployments"

"Enabling Only Essential Services"

"Securing Domain Controller Files and Executables."

3. Configure the computer to run Dcpromo.exe when it starts for the first time. For more
information, see "Automating the Promotion of Servers to Domain Controllers" later
in this guide.
4. Create an image of that computer.
5. Deploy the image to the target computer using one of the methods listed below.
6. Configure computer-specific settings, such as the computer name and IP addresses, on
the newly imaged computer.
You can use one of the following image-based methods for the automated installation of
Windows 2000 Server:

SYSPREP
Remote Installation Services (RIS)

Third-party tools

If you must use a non-image-based method, unattended setups generally present few security
risks and provide consistent server configuration.
SYSPREP, RIS, and unattended setup are Windows 2000 features. Table 5 compares and
contrasts SYSPREP, RIS, and unattended setup. Third-party tools have some combination of
the features found in each of these technologies. For further information about third-party
automated setup software that may be used by your organization, see the documentation that
accompanies the software.
Table 5 Comparison of Windows 2000 Automated Installation Methods

Characteristics
Provides image-based installations

Allows a variety of hardware configurations from a single

automation script or image

Requires high-bandwidth, well-connected network

infrastructure

Appropriate for datacenter deployments

Appropriate for branch office deployments

Unattended
Setup

SYSPREP RIS

For more information about SYSPREP, RIS, and unattended setup, see "Automating Server
Installation and Upgrade" in the Windows 2000 Server Deployment Planning Guide of the
Microsoft Windows 2000 Server Resource Kit at: http://go.microsoft.com/fwlink/?
LinkId=18578.
Automating the Promotion of Servers to Domain Controllers

The Active Directory Installation Wizard (Dcpromo.exe), which is used to promote domain
controllers, can be automated through the use of an answer file. Automating the promotion
process generally increases its predictability and consistency by eliminating the need for
manual intervention. When running Dcpromo.exe, use the following command:
dcpromo.exe /answer:answer_file_name

You can automatically start Dcpromo.exe after you complete the installation of Windows
2000 Server by running this command the first time the server starts. Automatically starting
Dcpromo.exe ensures that the promotion to a domain controller occurs immediately after the
implementation of Windows 2000 Server. This reduces the potential for the introduction of
unauthorized files or executables before the server is promoted. Configure the server to
automatically start Dcpromo.exe just before making your image.

Automatically start Dcpromo.exe the first time the server starts, following the installation of
Windows 2000, by using one of the following methods:

For third-party tools or RIS-based deployments, add the following entry under the
registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce:
Entry name: dcprom
Data type: REG_SZ
Value: dcpromo.exe
Caution:
Do .tdnot edit the registry unless you have no alternative. The registry editor bypasses
standard safeguards, allowing settings that can damage your system, or even require
you to reinstall Windows. If you must edit the registry, back it up first and see the
Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .

For SYSPREP, modify the [GuiRunOnce] section of the Sysprep.inf answer file
before running SYSPREP.
The following is an example of a Sysprep.inf answer file that is modified to start
Dcpromo.exe automatically the first time the server starts:
[GuiRunOnce]
Command0 = "dcpromo /answer:ansfile.txt"

If you are creating an image of a server that you plan to use for imaging multiple domain
controllers, place the Dcpromo.exe answer file on a floppy disk so that one image can be used
to deploy all domain controllers. Also, ensure that the Dcpromo.exe answer file path
designates the floppy disk drive.
Important:
Because the Dcpromo.exe answer file is stored on the floppy disk in plaintext, do not include
an administrative account name or a password in this file. This information must be entered
during the automated domain controller promotion process. The answer file automatically
provides all other parameters.
For more information about automating the promotion of servers to domain controllers, see
"Automating Server Installation and Upgrade" in the Windows 2000 Server Deployment
Planning Guide of the Windows 2000 Server Resource Kit on the Microsoft Web site at
http://go.microsoft.com/fwlink/?LinkId=18578.
Ensuring Predictable, Repeatable, and Secure Domain Controller
Deployments

Throughout the domain controller deployment process, there are security configuration
settings that you need to apply to all domain controllers. To ensure that these security settings
are applied uniformly to all domain controllers, implement a predictable, repeatable domain
controller deployment process by performing the following tasks:
1. Install Windows 2000 Server with the latest service packs and hotfixes.

2. Disable NTFS automatic 8.3 name generation.

3. Run virus-scanning software on the server.
4. Select secure domain controller promotion settings.
5. Prohibit the use of cached credentials when unlocking a domain controller console.
6. Create a reserve file to enable recovery from potential disk-space, denial-of-service
attacks.
Installing Windows 2000 Server with Service Packs and Hotfixes

When you create the first master image of a secure Windows 2000 server to be used for
installing and promoting multiple domain controllers, apply the configuration settings that are
listed in Table 6 to enhance security.
In situations where your domain controllers already exist, check these recommendations and
modify domain controller configurations accordingly.
Table 6 Configuration Settings for Windows 2000 Servers
Setting

Rationale

Format all partitions as NTFS.

NTFS provides a secure file system.

Install only TCP/IP as the transport

protocol.

Limiting transport protocols reduces the attack surface

on the domain controller.

Do not install Internet Information

Services (IIS); remove its default
selection during Windows 2000
Server setup.

IIS is not required for domain controller operations.

Eliminating IIS on dedicated domain controllers
reduces the attack surface.

Do not install Simple Mail Transfer

Protocol (SMTP) during Windows
2000 Server setup unless you are
using SMTP for Active Directory
intersite replication.

SMTP is not required for normal domain controller

operations unless it is used for intersite replication. This
recommendation reduces the attack surface on the
domain controller.

Do not install Indexing Service;

remove its default selection during
Windows 2000 Server setup.

Indexing Service is not required for domain controller

operations. Inadvertently indexing files can make the
location and content of the files available through Web
query interfaces. This recommendation reduces the
attack surface on the domain controller.

Install Domain Name System (DNS) Installing DNS during Windows 2000 Server setup
by selecting it during Windows 2000 ensures that DNS is available in the master image.

Server setup.
Use a strong password for the
computer local administrator
account.

A strong password reduces the threat of spoofing this

administrator account, which becomes the domain
"Administrator" account after the server is promoted to
a domain controller.

Creating a Strong Administrator Password

A strong password minimizes the threat of an attacker guessing (cracking) the password and
acquiring the credentials of the administrator account (spoofing). A strong password includes
all of the following characteristics:

Contains at least nine characters.

Does not contain an account name, real name, or company name.

Does not contain a complete dictionary word.

Is significantly different from previous passwords. Passwords that increment

(Password1, Password2, Password3 ...) are not strong.

Contains at least one symbol in the first seven characters.

Contains characters from each of the groups listed in Table 7.

Table 7 Groups of Characters to Include in Strong Passwords

Uppercase letters

A, B, C ...

Lowercase letters

a, b, c ...

Numerals

0, 1, 2, 3, 4, 5, 6, 7, 8, 9

Symbols found on the keyboard (all keyboard

characters not defined as letters or numerals)

`~!@#$%^&*()_+-=
{}|[]\:";'<>?,./

Examples of strong passwords are Pa$sw0rD1 and J*p2leO4>F.

After you complete the installation of Windows 2000 Server, obtain any additional security
protections that may have been implemented for Windows 2000 Server by applying the most
recent service packs and security-related hotfixes from the Microsoft Web site at
http://go.microsoft.com/fwlink/?LinkId=102.

Disabling NTFS Automatic 8.3 Name Generation

Many viruses and utilities that are used by attackers are 16-bit applications that expect
8.3compatible file names. Secure domain controllers do not run 16-bit applications locally.
Therefore, disable 8.3 automatic name generation to prevent these viruses and utilities from
compromising your domain controller security.
Disable automatic 8.3 name generation by setting the following entry under the registry key
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem:
Entry name: NtfsDisable8dot3NameCreation
Data type: REG_DWORD
Value: 1
Caution:
Do not edit the registry unless you have no alternative. The registry editor bypasses standard
safeguards, allowing settings that can damage your system, or even require you to reinstall
Windows. If you must edit the registry, back it up first and see the Registry Reference in the
Microsoft Windows 2000 Server Resource Kit at .
You can create a script that disables automatic 8.3 name generation on all domain controllers
in the domain automatically by performing the following tasks:
1. Create the ComputerSearch.vbs script, and copy it to a computer that is a member of
the domain.
For information about how to create this script, see "Identifying Computers to
Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B:
Procedures" of the Best Practice Guide for Securing Active Directory Installations
and Day-to-Day Operations: Part II.
2. Create a list of domain controllers in the domain by typing the following command at
a command prompt:
3. Cscript computersearch.vbs /r:DC

This command creates a list of domain controllers in the domain and saves this list as
ComputerSearch-date-time.csv.
4. Create the ApplyReg.vbs script and copy it to a computer that is a member of the
domain.
For information about how to create this script, see "Applying Registry Settings to a
List of Computers with ApplyReg.vbs" in "Appendix B: Procedures" of the Best
Practice Guide for Securing Active Directory Installations and Day-to-Day
Operations: Part II.
5. Create a .reg file for the following path, registry entry, and value:

6. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem]
7. "NtfsDisable8dot3NameCreation"=dword:00000001

Save the file as Registryfile.reg. For information about how to create the .reg file, see
"Creating a .reg File" in "Appendix: Procedures" of this guide:
8. Apply the registry entry to the domain controllers by typing the following command
at the command prompt:
9. Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-datetime.csv

This task applies the registry changes that are expressed in the file Registryfile.reg to
all computer that are listed in the file ComputerSearch-date-time.csv.
Running Virus-Scanning Software on the Server

After you install Windows 2000 Server, but before you promote the server to a domain
controller, install and run antivirus software on the domain controller to ensure that no viruses
have been introduced during the installation of Windows 2000 Server.
For image-based methods of automating the installation of Windows 2000 Server, make sure
that you install the virus-scanning software as part of the image. For other methods, install
and run the virus scanning software immediately after installing Windows 2000 Server.
Note:
If you are automatically starting Dcpromo.exe by using one of the RunOnce methods
discussed later in this section, modify your scripts to run the virus-scanning software first and
then automatically start Dcpromo.exe.
Selecting Secure Domain Controller Promotion Settings

During domain controller promotion, a number of configuration settings should be applied to

the server to enhance security. These settings are specified in the Dcpromo.exe answer file.
Note:
Many of the configuration settings that are required for domain controller promotion depend
on whether you are installing the first domain controller or an additional domain controller in
the forest or domain. If you are installing the first domain controller in the forest or domain,
the configuration settings in the Dcpromo.exe answer file are different from the settings that
are required for adding a domain controller to an existing domain.
Specifying Locations for the Active Directory Database, Logs, and SYSVOL

By default, Dcpromo.exe places the database, log files, and SYSVOL folder on the system
volume. During the promotion of a server to a domain controller, the Dcpromo.exe answer
file can specify an alternative location for the Active Directory database (Ntds.dit), log files,
and SYSVOL folder. Table 8 provides recommended alternative locations for these Active
Directory components for enhanced security and improved performance.
Table 8 Recommended Drive Locations for Active Directory Components
Recommendation

Security Rationale

Place the database and

SYSVOL folder on the same
dedicated physical drive that
does not contain the system
volume.

Place the log files on a

dedicated physical drive that
does not contain the system
volume.

The system volume is a common target of disk-space

attacks, such as spooling large print jobs. Putting the
database on a separate drive makes it immune to
damage caused by attacks that target the system
volume.

Placing the database and SYSVOL in a location other

than the default location reduces the likelihood of
disk-space attacks.

Attacks can be performed against IIS that allow

unauthorized users to navigate the folder structure of
its disk volume. Because Web sites are typically
stored on the system volume, this increases the risk of
information disclosure on this volume. Although
dedicated domain controllers are recommended, this
cannot always be adhered to in a branch office
situation.

This recommendation improves the reliably of

recovering Active Directory operations after a diskspace attack. For more information, see "Creating a
Reserve File to Enable Recovery from Disk-Space
Attacks" later in this guide.

This recommendation has no security implications,

but it will improve performance. The system volume
typically includes the paging file, which has high disk
utilization.

On existing domain controllers, move the Active Directory database, log files, and SYSVOL
folder to a dedicated physical drive, for the reasons described in Table 8.
For information about:

Moving the database and log files, see "Moving the Directory Database Files to a
Local Drive" in the Active Directory Operations Guide at
http://go.microsoft.com/fwlink/?LinkId=18545.

Moving the SYSVOL folder, see "Moving SYSVOL Manually" in the Active
Directory Operations Guide at http://go.microsoft.com/fwlink/?LinkId=18545.

Disabling Pre-Windows 2000 Compatibility

During the promotion of the first domain controller in a domain, one optional configuration
setting that significantly affects Active Directory security is "Permissions compatible with
pre-Windows 2000 servers." This setting enables Pre-Windows 2000 Compatibility for
certain applications that need to query the directory using anonymous access.

Applications or services that may query the directory using anonymous access include those
applications or services that run in the security context of Local System:

On a server running Windows NT 4.0 within or outside the forest.

On a server running Windows 2000 in a trusting domain outside the forest.

An example of such an application or service is the Routing and Remote Access Service
(RRAS) running on Windows NT 4.0.
In Active Directory, the group Pre-Windows 2000 Compatible Access is assigned Read
permissions on the domain root, as well as on all user, computer, and group objects. When
you enable Pre-Windows 2000 Compatibility, the special group Everyone is added as a
member of the Pre-Windows 2000 Compatible Access group. Because Everyone includes
anonymous users, in addition to authenticated users, anyone with network access can read
these objects.
When this setting is enabled, any user with network access, even one without an account in
the forest, can query and discover information about Active Directory users, groups, and
computers. If you do not have applications that require Active Directory access enabled for
Pre-Windows 2000 Compatibility, you should not select this setting during domain controller
promotion.
Note:
By default, the setting Permissions compatible with pre-Windows 2000 servers is selected in
the Active Directory Installation Wizard.
Analyzing the Need for Pre-Windows 2000 Compatibility

Disable Pre-Windows 2000 Compatibility, unless your applications require anonymous

access to Active Directory. Before deploying a production domain, you need to know whether
it will be possible to disable Pre-Windows 2000 Compatibility. During the lab testing phase
of your deployment, determine the applications that require anonymous access by performing
the following tasks:
1. When deploying the first domain controller in your test domain, select Permissions
compatible with pre-Windows 2000 servers.
2. Include at least one instance of each application running in your organization.
3. Enable security auditing on all domain controllers in the test domain to monitor
anonymous access to the directory. Collect security logs for 30 days.
For additional information about performing this task, see "Enabling Monitoring for
Anonymous Access" in "Appendix: Procedures" later in this guide.
4. Analyze the security logs for computers that initiate anonymous access to the
directory.
For additional information about performing this task, see "Monitoring for
Anonymous Access" in "Appendix: Procedures" later in this guide.

5. Identify the applications or services running on the computers from which anonymous
access was initiated.
Note:
Access to resources between domains that are connected by an external trust requires
Pre-Windows 2000 Compatibility. Because external trusts only support NTLM
authentication, queries to a directory in a different forest are always handled as
anonymous access.
After you have determined the applications that require anonymous access, determine if the
applications can be upgraded to versions that do not require anonymous access. After
upgrading the applications to newer versions, verify that the applications no longer require
anonymous access in your lab environment.
Typically, a newer version of the software, for example, Routing and Remote Access in
Windows 2000, does not require anonymous access. Whenever possible, upgrade to a newer
version of the software running on Windows 2000 or later operating systems so that you can
disable Pre-Windows 2000 Compatibility.
Prohibiting the Use of Cached Credentials When Unlocking a Domain Controller
Console

When the console on a domain controller is locked, either by the action of a user or
automatically by a screensaver time-out, the console must be unlocked to regain access to the
domain controller. The domain controller maintains cached credentials for any users that have
been authenticated locally. When the console is unlocked, by default the domain controller
uses these cached credentials, if they exist, for the user who attempts to unlock the console.
When cached credentials are used to unlock the console, any changes to the account, such as
user rights assignment, group membership changes, or disabling of the account, are not
enforced. For example, if an administrator, who is logged on to a domain controller console,
is terminated, he can still unlock the console, even if his account is disabled. To ensure that
any changes to the account are enforced immediately, require domain controller
authentication of the account to unlock the console, instead of cached credentials.
You can configure the domain controller to require domain controller authentication to
unlock the domain controller console by adding or modifying the following entry under the
registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
Entry name: ForceUnlockLogon
Data type: REG_DWORD
Value: 1
Caution:
Do not edit the registry unless you have no alternative. The registry editor bypasses standard
safeguards, allowing settings that can damage your system, or even require you to reinstall
Windows. If you must edit the registry, back it up first and see the Registry Reference in the
Microsoft Windows 2000 Server Resource Kit at .

You can create a script that specifies automatically that domain controller authentication is
required to unlock any domain controllers in the domain by performing the following tasks:
1. Create the ComputerSearch.vbs script, and copy it to a computer that is a member of
the domain.
For information about how to create this script, see "Identifying Computers to
Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B:
Procedures" of the Best Practice Guide for Securing Active Directory Installations
and Day-to-Day Operations: Part II.
2. Create a list of domain controllers in the domain by typing the following command at
a command prompt:
3. Cscript computersearch.vbs /r:DC

This command creates a list of domain controllers in the domain and saves this list as
ComputerSearch-date-time.csv.
4. Create the ApplyReg.vbs script, and copy it to a computer that is a member of the
domain.
For information about how to create this script, see "Applying Registry Settings to a
List of Computers with ApplyReg.vbs" in "Appendix B: Procedures" of the Best
Practice Guide for Securing Active Directory Installations and Day-to-Day
Operations: Part II.
5. Create a .reg file for the following path, registry entry, and value:
6. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon]
7. "ForceUnlockLogon"=reg_dword:00000001

Save the file as Registryfile.reg. For information about how to create the .reg file, see
"Creating a .reg File" in "Appendix: Procedures" of this guide.
8. Apply the registry entry to the domain controllers by typing the following command
at the command prompt:
9. Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-datetime.csv

This set of tasks applies the registry changes that are expressed in the file
Registryfile.reg to all computers that are listed in the file ComputerSearch-datetime.csv.
Creating a Reserve File to Enable Recovery from Disk-Space Attacks

Many security attacks attempt to consume the system resources of the targeted system. One
of the commonly attacked system resources is available disk space. Available disk space can
be exhausted by the addition of a large number of objects to the directory by a malicious user
or administrator. Active Directory requires that deleted objects continue to exist in the
directory as tombstones for an extended period of time to allow the deletion to replicate.

Therefore, the disk space that is consumed by the deleted objects cannot be reclaimed until
the tombstone lifetime has expired (by default, 60 days).
One way of mitigating the effects of this type of attack is by implementing preventive
measures. You can provide for a fast recovery by creating a reserve file on the same disk
volume as the Active Directory database (Ntds.dit file). A reserve file is simply a large file
that takes up available disk space. In the event that an attacker exhausts all disk space by
adding a large number of objects to the directory, you can delete the reserve file to quickly
restore normal operation while the rogue objects inside Active Directory are identified and
removed. For a procedure for performing this task, see "Creating a Reserve File" in
"Appendix: Procedures" later in this guide.
Enabling Only Essential Services

Every service running on a domain controller provides a potential target for an attack that can
compromise domain controller security. Therefore, it is prudent to enable only those services
that are essential to normal domain controller function, so that you can reduce the surface
area of attack. Table 9 lists the services that are installed during Windows 2000 Server
installation if you follow the security recommendations provided in "Installing Windows
2000 Server with Service Packs and Hotfixes" earlier in this guide. Table 9 also provides the
recommended startup type for each service to be configured.
Note:
For new domain controller deployments, configure these service startup types before creating
the master image for image-based deployments, as discussed in "Automating the Windows
2000 Installation Process" earlier in this guide.
Table 9 Recommended Services to Install on Windows 2000 Server

Service Name

Alerter

Application
Management

Automatic
Updates

Default
Startup
Type

Recommended
Startup Type

Comment

Automatic (No change)

Notifies selected users and computers of

administrative alerts.

Manual

Provides software installation services for

applications that are deployed through
Add/Remove Programs. On dedicated
domain controllers, this service can be
disabled to prevent unauthorized installation
of software.

(See comment)

Automatic (See comment)

Provides the download and installation of

critical Windows updates, such as security
patches or hotfixes. This service can be
disabled when automatic updates are not
performed on the domain controller. It is

included when Service Pack 3 (SP3) is

applied.

Background
Intelligent
Transfer Service

Manual

(See comment)

Provides a background file transfer

mechanism and queue management, and it is
used by Automatic Update to automatically
download programs, such as security
patches. This service can be disabled when
automatic updates are not performed on the
domain controller. It is included when SP3 is
applied.

ClipBook

Manual

(See comment)

Enables the Clipbook Viewer to create and

share "pages" of data to be reviewed by
remote users. On dedicated domain
controllers, this service can be disabled.

COM+ Event
System

Manual

(No change)

Provides automatic distribution of events to

COM components.

Computer Browser Automatic (See comment)

Maintains the list of computers on the

network, and supplies the list to clients that
request the list. If you do not have earlier
versions of clients that use this feature, set to
Manual.

DHCP Client

Automatic (See comment)

Updates DNS records using Dynamic

update. If your organization does not use
dynamic IP addresses for domain controllers,
set to Manual.

Automatic (No change)

Manages logical volumes that are distributed

across a local area network (LAN) or wide
area network (WAN), and it is required for
the Active Directory SYSVOL share.

Automatic Disabled

Maintains links between NTFS v5 file

system files on the domain controllers and
other servers in the domain. Disable this
service on dedicated domain controllers.

Distributed Link
Tracking Server

Manual

Tracks information about files that are

moved between NTFS v5 volumes
throughout a domain. Disable this service on
dedicated domain controllers.

DNS Client

Automatic (No change)

Distributed File
System

Distributed Link
Tracking Client

Disabled

Allows resolution of DNS names.

DNS Server

Automatic (No change)

Required for Active Directory-integrated

DNS zones.

Event Log

Automatic (No change)

Writes event log messages that are issued by

Windows-based programs and components
to the log files.

Manual

Disabled

Provides the ability to send and receive

faxes through fax resources that are
available on the domain controller and the
network. On dedicated domain controllers,
this service can be disabled, because sending
and receiving faxes is not a normal function
of a domain controller.

(No change)

Enables files to be automatically copied and

maintained simultaneously on multiple
computers, and it is used to replicate
SYSVOL among all domain controllers.

(See comment)

Indexes content and properties of files on the

domain controller to provide rapid access to
the file through a flexible querying
language. On dedicated domain controllers,
disable this service to prevent users from
searching files and file content if sensitive
files and folders are inadvertently indexed.

Fax Service

File Replication
Service

Manual

Indexing Service Manual

Internet
Connection
Sharing

Manual

Disabled

Provides network address translation (NAT),

addressing and name resolution, and
intrusion detection when connected through
a dial-up or broadband connection. On
dedicated domain controllers, disable this
service to prevent inadvertent enabling of
NAT, which would prevent the domain
controller from communicating with the
remainder of the network.

Intersite
Messaging

Disabled

(No change)

Required by SMTP replication in Active

Directory, Distributed File System (DFS),
and Netlogon.

IPSEC Policy
Agent

Automatic (See comment)

Provides management and coordination of

Internet Protocol security (IPSec) policies
with the IPSec driver. If your organization
does not use IPSec, set the startup type to
Manual.

Kerberos Key
Disabled
Distribution enter

(No change)

Provides the ability for users to log on using

the Kerberos V5 authentication protocol.

License Logging
Service

Automatic (See comment)

Monitors and records client access licensing

for portions of the operating system, such as
IIS, Terminal Services, and file and print
sharing, and for products that are not a part
of the operating system, such as Microsoft
SQL Server or Microsoft Exchange Server.
On a dedicated domain controller, this
service can be disabled.

Logical Disk
Manager

Automatic (No change)

Required to ensure that dynamic disk

information is up to date.

Logical Disk
Manager
Administrative
Service

Manual

Required to perform disk administration.

Messenger

Net Logon

(No change)

Automatic (See comment)

Transmits net sends and Alerter service

messages between clients and servers. If
your organization does not use this feature,
set the startup type to Manual.

Manual

(No change)

Maintains a secure channel between the

domain controller, other domain controllers,
member servers, and workstations in the
same domain and trusting domains.

NetMeeting
Remote Desktop
Sharing

Manual

Disabled

Eliminates a potential security threat by

allowing domain controller remote
administration through NetMeeting.

Network
Connections

Manual

(No change)

Manages objects in the Network

Connections folder.

Network DDE

Manual

(See comment)

Provides network transport and security for

Dynamic Data Exchange (DDE) for
programs running on the domain controller.
This service can be disabled when no DDE
applications are running locally on the
domain controller.

Network DDE
DSDM

Manual

(See comment)

Used by Network DDE. This service can be

disabled when Network DDE is disabled.

NTLM Security

Manual

(No change)

Provides security to remote procedure call

Support Provider

(RPC) programs that use transports other

than named pipes, and enables users to log
on using the NTLM authentication protocol.

Performance Logs
Manual
and Alerts

Collects performance data for the domain

controller, writes the data to a log, or
generates alerts. This service can be set to
automatic when you want to log
performance data or generate alerts without
an administrator being logged on.

Plug and Play

Print Spooler

(See comment)

Automatic (No change)

Automatically recognizes and adapts to

changes in the domain controller hardware
with little or no user input. If your
organization does not change hardware on
domain controllers, set the startup type to
Manual.

Automatic (See comment)

Manages all local and network print queues,

and controls all print jobs. Can be disabled
on dedicated domain controllers where no
printing is required.

Protected Storage Automatic (No change)

Protects storage of sensitive information,

such as private keys, and prevents access by
unauthorized services, processes, or users.
This service is used on domain controllers
for smart card logon.

QoS RSVP

(See comment)

Provides support for Quality of Service

(QoS) Resource Reservation Protocol
(RSVP) routing information. This service
can be disabled when QoS is not used to
allocate network bandwidth in network
infrastructure.

(See comment)

Detects unsuccessful attempts to connect to

a remote network or computer, and provides
alternative methods for connection. This
service can be disabled on dedicated domain
controllers where no virtual private network
(VPN) or dial-up connections are initiated.

Manual

Remote Access
Auto Connection Manual
Manager

Remote Access
Connection
Manager

Manual

(See comment)

Manages VPN and dial-up connection from

the domain controller to the Internet or other
remote networks. This service can be
disabled on dedicated domain controllers
where no VPN or dial-up connections are

initiated.
Remote Procedure
Manual
Call (RPC)

(No change)

Serves as the RPC endpoint mapper for all

applications and services that use RPC
communications.

Remote Procedure
Call (RPC)
Automatic (No change)
Locator

Enables RPC clients using the RpcNs*

family of application programming
interfaces (APIs) to locate RPC servers and
manage the RPC name service database.

Remote Registry
Service

Automatic (No change)

Enables remote users to modify registry

settings on the domain controller, provided
that the remote users have the required
permissions. By default, only Administrators
and Backup Operators can access the
registry remotely.

Removable
Storage

Automatic (See comment)

Manages and catalogs removable media, and

operates automated removable media
devices, such as tape auto loaders or CD
jukeboxes. This service can be disabled
when removable media devices are not
directly connected to the domain controller.

Routing and
Remote Access

Disabled

(No change)

Enables LAN-to-LAN, LAN-to-WAN, VPN,

and NAT routing services.

Automatic (No change)

Allows you to run specific tools and

programs with different privileges than your
current logon provides.

RunAs Service

Security Accounts
Automatic (No change)
Manager

A protected subsystem that manages user

and group account information.

Server

Automatic (No change)

Provides RPC support, file print, and named

pipe sharing over the network.

Smart Card

Manual

(No change)

Manages and controls access to a smart card

that is inserted into a smart card reader that
is attached to the domain controller.

Smart Card Helper Manual

(No change)

Provides support for legacy, non-plug-andplay smart card readers.

Automatic (No change)

Monitors system events and notifies

subscribers to the COM+ Event System of
these events.

System Event
Notification

Automatic (No change)

Provides the ability to schedule automated

tasks on the domain controller.

TCP/IP NetBIOS
Automatic (No change)
Helper Service

Provides support for the NetBIOS over

TCP/IP (NetBT) service and network basic
input/output system (NetBIOS) name
resolution for clients.

Telephony

(See comment)

Provides Telephony API (TAPI) support of

client programs that control telephony
devices and IP-based voice connections.
This service can be disabled on dedicated
domain controllers where TAPI is not used
by applications.

Disabled

Enables a remote user to log on and run

applications from a command line on the
domain controller. Enable Telnet only when
it is used for remote administration for
branch offices or remotely administered
domain controllers. Terminal Services is the
recommended method for remote
administration.

(See comment)

Allows multiple remote users to be

connected interactively to the domain
controller, and provides display of desktops
and run applications. To reduce the surface
area of attack, disable Terminal Services
unless it is used for remote administration
for branch offices or remotely administered
domain controllers.

Task Scheduler

Telnet

Manual

Manual

Terminal Services Disabled

Uninterruptible
Power Supply

Utility Manager

Automatic (No change)

Manages an uninterruptible power supply

(UPS) that is connected to the domain
controller by a serial port.

Manual

Disabled

Allows faster access to some accessibility

tools, such as Magnifier, Narrator, and OnScreen Keyboard, and also displays the
status of the tools or devices that it controls.
Disable Utility Manager unless you require
these special accessibility tools.

(No change)

Adds, modifies, and removes applications

that are provided as a Windows Installer
(.msi) package.

Windows Installer Manual

Windows
Management
Instrumentation
Windows
Management
Instrumentation
Drivers

Manual

Manual

(No change)

Provides a common interface and object

model to access management information
about the domain controller through the
WMI interface.

(No change)

Monitors all drivers and event trace

providers that are configured to publish
WMI or event trace information.

(No change)

Sets the domain controller clock, and

maintains date and time synchronization on
all computers in the network.

Windows Time

Manual

Workstation

Automatic (No change)

Creates and maintains client network

connections to remote servers.

Note:
The antivirus software installed earlier in the process describe in this section may run as a
service in Windows 2000 Server. Do not change the default configuration of your antivirus
software.
Table 10 lists the changes to the service startup configuration when a server running
Windows 2000 is promoted to a domain controller. This table is provided as a reference, and
you can combine it with the list in Table 9 to arrive at the final list of services to have running
on a domain controller.
Table 10 Recommended Changes to Service Startup Type After Promotion to Domain
Controller

Service Name

Distributed Link
Tracking Server

File Replication
Service

Default
Startup
Type

Automatic

Automatic

Intersite Messaging Automatic

Recommended
Startup Type

Comment

Disabled

Tracks information about files that are

moved between NTFS v5 volumes
throughout a domain. Disable this service
on dedicated domain controllers.

(No change)

Enables files to be automatically copied

and maintained simultaneously on
multiple computers. This service is used
to replicate SYSVOL between all domain
controllers.

(No changes)

Required by SMTP replication in Active

Directory, DFS, and Netlogon.

Kerberos Key
Distribution enter

Net Logon

Automatic

Automatic

Remote Procedure
Automatic
Call (RPC) Locator
Windows
Management
Instrumentation

Windows Time

Automatic

Automatic

(No change)

Provides the ability for users to log on

using the Kerberos V5 authentication
protocol.

(No change)

Maintains a secure channel between the

domain controller, other domain
controllers, member servers, and
workstations in the same domain and in
trusting domains.

(No change)

Enables RPC clients using the RpcNs*

family of APIs to locate RPC servers and
manage the RPC name service database.

(No change)

Provides a common interface and object

model to access management information
about the domain controller through the
WMI interface.

(No change)

Sets the domain controller clock, and

maintains date and time synchronization
on all computers in the network.

The recommended services as listed in Table 9 and Table 10 are just the services that are
required to support a dedicated domain controller. Although it is recommended that you have
only dedicated domain controllers, if your domain controller serves other roles, such as a file
server or print server, you may need to enable other services for proper operation.
Securing Domain Controller Files and Executables

When Windows 2000 Server is installed with NTFS partitions, the files and executables on
the server are assigned baseline NTFS permissions. After successfully promoting a server to a
domain controller, Dcpromo.exe sets secure NTFS permissions on the system files and
executables, as well as on Active Directory files and folders.
After promotion to domain controller, the default permissions on the root of each logical disk
volume grant Full Control access to the special group Everyone. This causes the root of each
disk volume, including the volume housing the Active Directory database files, to be
susceptible to disk-space attacks.
To guard against this threat, secure each volume with the additional settings listed in Table
11.
Table 11 Additional Files and Folders to Be Secured After Promotion to Domain
Controller
File or Folder

Permissions

Root of each logical disk volume

Allow Read and Execute for Everyone

Allow Full Control for Administrators

Running Virus Scans on Domain Controllers

After domain controllers are promoted, continue to run virus scans and to obtain regular virus
signature updates from your antivirus software vendor. Before you initiate regular antivirus
scanning, be aware that some antivirus software can interfere with the proper operation of
domain controllers by:

Interfering with directory database and log file access by the Extensible Storage
Engine (ESE).
Interfering with File Replication service (FRS) database and log file access by ESE.

Causing excessive replication by FRS.

Some versions of antivirus software modify the security descriptor of files during scans.
Modifying security descriptors triggers FRS, which creates high volumes of replication traffic
unnecessarily. These issues with running antivirus software on domain controllers are
addressed by the recommendations in the following three sections.
For more information about using antivirus software on your domain controller, see article
284947, "Antivirus Problems May Modify Security Descriptors Causing Excessive
Replication of FRS Data in Sysvol and DFS" in the Microsoft Knowledge Base at
http://go.microsoft.com/fwlink/?LinkId=4441.
Preventing Interference Between Virus Scans and Active Directory Database and
Log File Access

ESE, which underlies Active Directory, opens database and log files in exclusive mode. This
means that if the antivirus software opens one of these files, ESE fails when it tries to open
the same file. Alternatively, the antivirus software cannot open these files for scanning if they
have already been opened by ESE.
Furthermore, these database and log files have internal checksums that, when altered through
file changes by the antivirus software, can cause either an access error to occur or the
database to fail on restart or restore. In all cases, this results in Active Directory failing on the
domain controller.
To run antivirus software on your domain controllers, configure the antivirus software to
exclude from scanning the Active Directory database and log files that are specified in Table
12.
Table 12 Files Not Scanned and Registry Entry Values Specifying Their Location
Exclude from Scan

In HKLM\System\Services\NTDS\Parameters

Ntds.dit

DSADatabaseFile

Edb*.log, Edb*.pat, Res.log, and Res2.log DatabaseLogFilesPath

Temp.edb and Edb.chk

DSAWorkingDirectory

Ntds.pat

DSADatabaseFile

Note:
For Windows Server 2003 and later operating systems, the Ntds.pat file is no longer used.
Therefore, it is not an issue when you run antivirus software on those operating systems.
Excluding the files in Table 12 from regular virus scanning does not increase a domain
controller's vulnerability to a virus attack. Viruses tend to attach to files that are executed,
such as binaries or scripts, rather than to data files. Dedicated domain controllers with no
user-modifiable content are therefore less vulnerable to common virus attacks.
Preventing Interference Between Virus Scans and FRS Database and Log File
Access

As previously explained for Active Directory database access, either the antivirus software
can prevent ESE from opening the FRS database and log files or the other way around.
Furthermore, a change in the internal checksums of these files can cause an access error to
occur or the database to fail on restart or restore. In all cases, this results in Active Directory
failing on the domain controller.
To run antivirus software on your domain controllers, configure the antivirus software to
exclude from regular virus scanning the FRS database and log files that are specified in Table
13.
Table 13 Files and Folders Not Scanned and Registry Entry Values Specifying Their
Location

Exclude Files from

Scan

In HKLM\System\CurrentControlSet\Services\NtFrs\Parameters

Jet\sys\edb.chk,
jet\ntfrs.jdb and
jet\log\*.log

WorkingDirectoryFile

Log\*log

DBLogFileDirectory

Exclude Folders
from Scan

HKLM\ System\CurrentControlSet\Services\NtFrs\Parameters\
ReplicaSets\GUID

replica_root

ReplicaSetRoot

staging_directory

ReplicaSetStage

preinstall_directory

replica_root \DO_NOT_REMOVE_Ntfrs_Preinstall_Directory

Preventing Virus Scans from Triggering Excessive FRS Replication

Domain controllers running Windows 2000 use FRS to replicate system policy and logon
scripts that reside in the SYSVOL folder. Antivirus software can interfere with the normal
functioning of FRS by modifying the security descriptor and the time stamp of files in the
SYSVOL folder. This causes FRS to replicate the changes to other domain controllers, which
create a high volume of file replication traffic.
Because some antivirus software scans every file and directory in an FRS replicated tree, this
action is similar to requesting a full synchronization of all files and folders from every
domain controller running the antivirus software. Administrators may see the following
symptoms of this problem in their environments:

Files in SYSVOL shares replicate excessively.

Network traffic between replication partners consumes excessive bandwidth.

The number of files in the staging directory constantly grows and then empties
sometime after the antivirus scan completes or after FRS replication.
Note:
The staging directory behavior changes for Windows Server 2003, Windows 2000
Server SP3 and later. These systems contain an updated FRS version that leaves
staging files in place for one week before removing them.

For more information about running antivirus software on domain controllers, see article
815263, "Antivirus, Backup, and Disk Optimization Programs That Are Compatible with the
File Replication Service" in the Microsoft Knowledge Base at
http://go.microsoft.com/fwlink/?LinkId=4441.
You can prevent antivirus software from causing excessive replication, while continuing to
maintain a high level of security on domain controllers, by performing the following tasks:

Configure antivirus software to not scan files in the SYSVOL directory tree.

Require script signing on domain controllers and administrative workstations.

Excluding Antivirus Scanning of SYSVOL

Antivirus software can interfere with the normal functioning of FRS by modifying the
security descriptor and time stamp of files in the SYSVOL folder. This triggers FRS to
replicate the changes in the SYSVOL folder to other domain controllers, creating a high
volume of file replication traffic. The result is excessive FRS replication between domain
controllers.

Note:
The following antivirus applications do not modify SYSVOL files in a way that triggers
excessive replication:

eTRUST Antivirus build 96 or later with the NTFS incremental scan feature disabled
McAfee/NAI NetShield 4.50 with the NetShield Hot Fix Rollup

Norton Antivirus 7.6 or later

To run antivirus software on domain controllers, configure the antivirus software to exclude
from scanning the SYSVOL folder its subdirectories.
Requiring Script Signing on Domain Controllers and Administrative Workstations

In contrast to the situation for the directory database and log files, excluding the SYSVOL
folder from virus scanning does increase the risk of a virus attack on a domain controller.
Viruses tend to attach to files that are executed, such as binaries or scripts. If you exclude the
SYSVOL folder from virus scans, you increase the risk of virus attacks on logon scripts and
startup scripts in the SYSVOL folder on domain controllers. As a countermeasure, implement
script signing to protect the integrity of scripts running on domain controllers and
administrative workstations.
Windows 2000 supports the enforcement of script signing to validate the integrity of scripts
and binaries before executing them. Establish a practice for your organization that requires all
scripts in the SYSVOL folder to be signed. Windows Script Host (WSH) scripts (such as
.vbs, .js, and .wmf scripts) can be signed or verified using the same tools that are ordinarily
used to sign other executables. The script signer, one of the security tools provided by
WinTrust, generates a digital signature of the contents of a script. That information is then
formatted as a comment and added to the end of the script.
Note:
You can obtain the WinTrust tools for signing and verifying scripts (signcode.exe and
chktrust.exe, respectively) in the Windows 2000 Platform Software Development Kit (SDK).
Sign scripts, and verify that the scripts are properly signed, by performing the following tasks
on every domain controller and administrative workstation:
1. To require that only signed scripts be run on a computer, add the following entry
under the registry key HKEY_LOCAL_SYSTEM\Software\Microsoft\Windows
Script Host :
Entry name: TrustPolicy
Data type: REG_DWord
Value: 2
Caution:
Do not edit the registry unless you have no alternative. The registry editor bypasses
standard safeguards, allowing settings that can damage your system, or even require
you to reinstall Windows. If you must edit the registry, back it up first and see the
Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .

2. Enroll to acquire a certificate from an internal certification authority (CA).

Choose an internal CA so that confirmation of the current validity of the certificate
does not require an Internet lookup. To ensure that the certificate has not been
revoked, the code checks the CA's certificate revocation list (CRL).
3. Secure all scripts by signing.
Two alternatives exist for creating signed scripts. If you are interested in developing
your own script host, the Windows Product SDK contains a set of tools for signing
scripts (signcode.exe and chktrust.exe). Alternatively, WSH version 5.6 ships with a
signer object to sign or verify scripts.
4. Verify that all scripts are signed.
For the code required to verify that the scripts have been signed, see "Securing Scripts
with Script Signing" in "Appendix: Procedures" later in this guide.
Note:
As a minimum, you should enforce script signing on domain controllers and
administrative workstations. However, it is a best practice recommendation that script
signing be enforced on all computers on the network running operating systems that
support script signing. Operating systems that support script signing include the
Windows 2000 family of operating systems, Windows XP, and the Windows Server
2003 family.
For more information about implementing script signing, see:

"Digital Code Signing Step-by-Step Guide" on the Microsoft MSDN Web site at
http://go.microsoft.com/fwlink/?LinkId=18548.
"Windows Script Host: New Code-Signing Features Protect Against Malicious
Scripts" on the Microsoft MSDN Web site at http://go.microsoft.com/fwlink/?
LinkId=18550.
Note:
Batch files cannot be signed; therefore, they are inherently less secure. Convert all
batch files to Microsoft Visual Basic scripts as soon as possible.

Maintaining Physical Security

All of the descriptions of domain controller security measures in the previous sections
assume that the domain controller is physically secure. Physical security ensures that
unauthorized users cannot turn the domain controller on or off, add or remove hardware,
insert or remove removable media, log on by using the domain controller's keyboard and
display, or remove backup media.
To maintain physical security for your domain controllers, perform the following tasks:

Secure domain controllers against physical access.

Prevent domain controllers from booting into alternate operating systems.

Protect domain controllers on restart by using SYSKEY.

Secure backup media against physical access.

Enhance the security of the network infrastructure.

Secure the remote restart of domain controllers.

Securing Domain Controllers Against Physical Access

The first line of defense in maintaining physical security is to secure domain controllers
against any attacks that can be accomplished with physical access to the domain controller.
Note that changes in the domain controller's environmental conditions, such as power
failures, can also compromise the security of the domain controller.
Take the following common security precautions for restricting physical access to the domain
controller:

Use UPSs to prevent loss of power.

Place domain controllers and UPSs in a locked room.

Require cardkey locks or cipher-locks on the entrances to the locked room.

Require locks on individual domain controllers or on doors to the racks housing the
domain controllers.

Require specific processes and procedures for any administration or repair of the
domain controllers.

These security precautions are intended to prevent a potential attacker from gaining physical
access to your domain controllers. However, in an environment where these
recommendations cannot be strictly enforced, such as in branch offices, additional security
measures may be required, as described in the following sections.
Preventing Domain Controllers from Booting into Alternate Operating Systems

A domain controller can be booted into an alternate operating system. For example, public
domain drivers exist for MS-DOS that an attacker can use to boot the domain controller and
directly access files that are stored on NTFS disk volumes, bypassing existing NTFS
permissions. Similar utilities exist for Linux and UNIX operating systems. You can take steps
to avoid this type of attack.
To minimize the possibility of domain controllers booting into an alternate operating system:

Disable or remove the floppy disk drive, unless it is required by SYSKEY. For more
information, see "Protecting Domain Controllers on Restart Using SYSKEY" later in
this guide.
Disable or remove the CD-ROM or DVD drive.

Set the [timeout] parameter in the Boot.ini file to 0.

Disable remote network boot and installation, for example, by RIS or Bootstrap
Protocol (BOOTP).

When you are unable to use SYSKEY with a password or floppy disk, require a basic
input/output system (BIOS) password to boot the computer.

Protecting Domain Controllers on Restart by Using SYSKEY

In secure datacenter environments, generally, only authorized personnel can restart domain
controllers. However, in an environment where these recommendations cannot be strictly
enforced, such as in branch offices, there is increased potential for an unauthorized person to
restart a domain controller.
An unplanned or unexpected restart of a domain controller can indicate that an attacker has
booted the domain controller with an alternate operating system and compromised its
security. On the other hand, the restart might simply be due to a loss of power or to scheduled
maintenance on the domain controller.
Evaluating the Need for SYSKEY

The system key (SYSKEY) in Windows 2000 protects security information, including
passwords in the Active Directory database and other Local Security Authority (LSA) secrets,
against offline attacks by encrypting their storage on the domain controller. SYSKEY can
either be derived from a secret password that you specify, or it can be stored on offline media,
such as a floppy disk. On a domain controller reboot, either the password or the floppy disk
containing SYSKEY must be supplied to successfully restart the computer.
Implementing SYSKEY provides two security advantages:

Point-in-time control of the domain controller restart, which evaluates the reason for
the domain controller restart and determines if security has been compromised

Protection for passwords that are stored in the directory database against offline
attacks if the domain controller or a disk are stolen

You can use the system key utility (Syskey.exe), which is installed on the domain controller
during the Windows 2000 Server installation, to select one of these two configurations for the
SYSKEY source.
There are certain logistic operational issues involved with the use of SYSKEY:

Management of SYSKEY passwords or floppy disks can present challenges.

Requiring a branch manager or local administrative staff to come to the office at 3
A.M. to enter the passwords or insert a floppy disk might be difficult.
Alternatively, allowing centralized IT operations personnel to provide the SYSKEY
password remotely requires additional hardware, such as Compaq Remote Insight

Lights-out (RILO) or Dell Remote Access Card (DRAC III) boards. For more
information about restarting domain controllers remotely, see "Securing the Remote
Restart of Domain Controllers" later in this guide.

Loss of the SYSKEY password or floppy disk leaves the domain controller in a state
in which it cannot be restarted.
There is no way to recover a domain controller if the SYSKEY password or floppy
disk is lost. In this situation, it would be necessary to rebuild the domain controller.

Selecting a Method for Securing Domain Controller Restarts with SYSKEY

Each method noted in the previous section (specifically, manually entered SYSKEY or
SYSKEY supplied on a floppy disk) has advantages and difficulties. If you choose to add
SYSKEY protection to your domain controllers, you should first evaluate your security
environment to determine which method will work best for you.
Providing SYSKEY Passwords to Secure Domain Controller Restarts

SYSKEY passwords do not require physical media that could be lost, as there are no floppy
disks. Trusted personnel must enter a password in the event that the domain controller needs
to be restarted. The password should be known to only a small group of trusted
administrators, preferably only member of the Domain Admins group. The disadvantage of
using passwords to secure SYSKEY is that trusted personnel are required to memorize
another password and be on-site to enter the password.
To support branch offices, you may need to provide the SYSKEY password remotely through
central IT trusted personnel. However, this requires additional hardware, such as Compaq
RILO or Dell DRAC III boards. For more information about restarting domain controllers
remotely, see "Securing the Remote Restart of Domain Controllers" later in this guide.
Because passwords can be compromised, you may be able to increase the security of
passwords that are used for SYSKEY restarts by:

Using strong passwords.

Storing the passwords in a secure environment, such as a bank safety deposit box.

Requiring the periodic changing of the SYSKEY passwords.

Providing SYSKEY Floppy Disks to Secure Domain Controller Restarts

Using SYSKEY with a password that is stored on a floppy disk does not require that a
password be memorized by trusted personnel. However, implementing SYSKEY with a
floppy disk does introduce the risk of lost or damaged physical media. Furthermore, trusted
personnel are required to insert the floppy disk during domain controller restart. Again, only
trusted personnel, preferably members of the Domain Admins group, should have access to
the SYSKEY floppy disk.
To support branch offices, you may need to install third-party hardware devices, such as
Compaq RILO or Dell DRAC III boards, so that images of floppy disks can be remotely

transferred to the domain controller. Using these devices, central IT trusted personnel can
transfer a copy of the SYSKEY disk image to a remote domain controller. After the domain
controller is restarted, IT operations personnel can delete the remote image of the SYSKEY
floppy disk.
Because the floppy disk contains the cryptographic key for SYSKEY, you should take
measures to ensure that the floppy disk is not stolen, lost, destroyed, or copied by an
unauthorized person. Some ways to mitigate these possibilities include:

Copying the floppy disk and storing the copy off-site, such as in a bank safe deposit
box.
Storing the working copy of the floppy disk in a secure place on-site.

Removing the floppy disk from the domain controller immediately after it restarts.

Securing Backup Media Against Physical Access

As part of your normal operational practices, you should regularly back up your domain
controllers and secure the backup media to minimize the risk of data tampering or theft.
Because the backup contains all the information in the Active Directory database, theft of the
backup media presents the same risks as theft of the domain controller or a disk drive from
the domain controller. The attacker can restore the information elsewhere and illegally access
Active Directory data.
Some methods for helping to prevent unauthorized users from gaining physical access to
backup media include:

Storing backup media for on-site use in a secure location where access is audited.
Storing archival backup media securely off-site.

Establishing processes and procedures that require the signatures of authorized

administrators when any archival backup media is brought back on-site.

Ensuring that backup media is only in the backup device during backup or recovery.

Enhancing the Security of the Network Infrastructure

The placement of domain controllers in your environment directly affects the security of your
domain controllers. The primary focus in network security is to isolate the domain controllers
from unauthorized users while providing high-speed, secure access to authorized users. To
ensure that domain controllers are properly isolated, secure any cabling rooms, and place
domain controllers on secured network segments in your network.
Securing Cabling Rooms

If an attacker can gain access to your cabling rooms, the attacker can potentially use a
protocol analyzer to capture network traffic and compromise your network's security,
including domain controller security. In intranet and perimeter network datacenters, the

possibility of unauthorized personnel gaining access to these cabling rooms is negligible.

However, in branch offices the cabling rooms may be shared with telephony wiring and other
utilities.
Typically, your cabling rooms are where some of your routers and switches are located. The
routers and switches contain a logical diagram of your network because they manage and
maintain routing information. This routing information is used by Active Directory to
determine IP subnets, and it determines the preferred domain controller for computers in the
network.
Attackers can gain access to your switches and routers by using Telnet or Web interfaces that
are provided by these devices. If attackers gain access to the configuration information of
these devices, they can use this information to mount attacks on your domain controllers.
In most environments, all routers and switches use the same passwords for reading and
configuring information. IT administrators may want to have a single password to simplify
the management of a large number of switches, or the management software for routers and
switches may only support the use of a single name.
Regardless of the environment, you can improve the security of your cabling rooms by:

Requiring cardkey locks or cipher-locks on entrances to the cabling rooms.

Requiring locks on the racks that house wiring panels, switches, or routers.

Including UPSs to prevent loss of power.

Requiring specific processes and procedures for any administration or repair of

cabling, switches, or routers.

Using strong passwords to secure the configuration of routers and switches.

Using different passwords for reading and configuring routers and switches.

Placing Domain Controllers in Secured Network Segments

Placing domain controllers in secured segments of your network assists in isolating the
domain controllers from unauthorized users. At the same time, ensure that users and
computers have high-speed connectivity to their respective domain controllers.
Placing Domain Controllers in Datacenters

Place domain controllers physically within the datacenter so that only designated personnel
have direct physical contact with the domain controllers. Place your forest root, application,
and regional domain controllers for use in your organization's private network in the
datacenter. The placement of domain controllers for your perimeter network is discussed in a
later section.
Placing domain controllers physically within the datacenter reduces the chance that anyone
other than designated personnel will have direct physical contact with the domain controllers.
Place domain controllers so that firewalls protect domain controllers from Internet users

while routers, and possibly firewalls, protect domain controllers from users within the
organization's private network. Figure 7 illustrates the placement of domain controllers in a
datacenter.

Figure 7

Domain Controllers in a Datacenter

Placing Domain Controllers in Perimeter Networks

Place domain controllers in your perimeter networks so that the domain controllers are not
directly accessible by Internet users. Ensure that only Web servers, database servers, file
servers, users in the private network, and computers in the private network have direct access
to the domain controllers.
Placing the domain controller behind a standalone router helps prevent Internet users from
directly accessing the domain controller. To help minimize security risks, place the domain
controller on the same network segment as the client computers. You should also ensure that
the router communicates exclusively with the organization's hub or central location by using
VPN tunnels. Prevent any other requests that originate from the Internet from reaching the
branch office's network segment and, subsequently, the domain controller.
Figure 8 illustrates the placement of domain controllers in a perimeter network.

Figure 8

Domain Controllers in a Perimeter Network

Placing Domain Controllers in Branch Offices

In branch offices, domain controllers often provide other services, such as file or print
services, to users in the branch office. These multifunction domain controllers communicate
with the rest of the organization through a routed connection, possibly a dial-up modem that
is managed by a stand-alone router. The stand-alone router provides the isolation and firewall
functionality to protect the domain controller and the users in the branch office.
Place the domain controller behind the stand-alone router to prevent Internet users from
directly accessing the domain controller. Place the domain controller on the same network
segment as the client computers. Ensure that the router communicates exclusively with the
organization's hub or central location by using VPN tunnels. Prevent any other requests that
originate from the Internet from reaching the branch office's network segment and,
subsequently, the domain controller.
Note:
Whenever possible, use dedicated domain controllers in branch offices to minimize the
threats that can compromise the security of Active Directory.
Figure 9 illustrates the placement of domain controllers in a branch office.

Figure 9

Domain Controllers in a Branch Office

Additionally, a modem can provide out-of-band management capability for a remote domain
controller. The modem directly connects either to a COM port on the domain controller or to
remote management hardware (such as the Compaq RILO board) or an intelligent UPS. This

out-of-band management capability can provide the ability to perform BIOS configuration,
monitor and select the boot process, and turn the domain controller on and off.
Ensure that the number to the modem is kept secret. Require the modem to call back to a
predetermined list of numbers, and require user identification for callback.
Securing the Remote Restart of Domain Controllers

In some situations, your domain controllers may require remotely administered management,
or they may be placed in branch offices outside your organization's datacenter. In these
situations, the restart of a domain controller must be performed remotely.
Tasks that must be performed during the remote restart of a domain controller include:

Selection of the Windows 2000 Server boot options

Configuration of the BIOS on the domain controller

Terminal Services is unable to perform these tasks, because Windows 2000 Server must be
running to support Terminal Services. These tasks require additional hardware to support
remote restart functionality. Examples of this type of hardware include:

Smart UPSs
Remote access hardware that is integrated into the server, such as Compaq RILO or
Dell DRAC III boards

Video switches that connect to the keyboard, mouse, and display that provide services
similar to Terminal Services

Most of these devices communicate by using RS-232 or Ethernet, and they have only
rudimentary security, such as a password. In datacenters, the devices that communicate
through RS232 are connected to a terminal concentrator. The terminal concentrator
multiplexes a number of RS-232 connections into a single RS-232 or Ethernet connection.
Smart UPS and remote access hardware typically communicate through Telnet.
Secure the remote restart of domain controllers by doing the following:

When the domain controller is in a datacenter, connect the remote restart device's
RS232 or Ethernet connection to a network segment that is dedicated to network
management and that is isolated from clients.

When the domain controller is in a branch office, connect the remote restart device to
a dedicated modem, and require the modem to provide password identification and
callback functionality.

Recommendations: Deploying Secure Domain Controllers

Following the security recommendations that are described earlier in this section will help
minimize the security risks involved in deploying domain controllers. Of course, as

previously mentioned, you should consider the recommendations described in other sections
in considering how best to enhance your comprehensive Active Directory security.
In most instances, these recommendations are intended for intranet datacenter, extranet
datacenter, and branch office scenarios. However, some of the recommendations depend on
the particular scenario. When the recommendations are scenario specific, notes are included
to direct you to the section where the recommendation is discussed.
Recommendations for Establishing Secure Domain Controller Build Practices

The following table provides a checklist of recommendations for establishing secure domain
controller rollout practices.

Check Securing the Domain Controller Build Environment

Whenever possible, build domain controllers in secured environments, such as
datacenters.
When building domain controllers in unsecured environments, ensure that only trusted
personnel have physical access.
Check Selecting Secure Domain Controller Build Methods
Use imaged-based, automated deployment methods for installing Windows 2000
Server.
Note:
This recommendation may vary or may not be feasible, based on your scenario. For
more information, see "Selecting Secure Domain Controller Build Methods" earlier in
this guide.
Automate the promotion of servers to domain controllers.
Recommendations for Ensuring Predictable, Repeatable, and Secure Domain
Controller Deployments

The following table provides a checklist of recommendations for ensuring that your domain
controller deployments are predictable, repeatable, and secure.

Check Installing Windows 2000 Server with Service Packs and Hotfixes
Install Windows 2000 Server with the most recent service packs.
Apply all current security-related hotfixes.

Format all partitions as NTFS.

Create a strong password for the Administrator account.
Deselect IIS during installation.
Select DNS during installation.
Deselect SMTP unless Active Directory replication uses SMTP.
Check Disabling NTFS Automatic 8.3 Name Generation
Disable NTFS automatic 8.3 name generation.
Check Running Virus-Scanning Software on the Server
Run virus-scanning software before promoting any server to a domain controller.
Ensure that virus-scanning software includes any updates to detect and remove the
latest viruses.
Check Selecting Secure Domain Controller Promotion Settings
Place the Active Directory database (Ntds.dit) on a separate physical drive.
Place the Active Directory logs on a separate physical drive.
Place SYSVOL on the same physical drive as the Active Directory database.
Disable Pre-Windows 2000 Compatibility, if possible.
Check

Prohibiting the Use of Cached Credentials when

Unlocking a Domain Controller Console
Prohibit cached credentials from unlocking a domain controller console.

Check Creating a Reserve File to Enable Recovery from Disk-Space Attacks

Create a reserve file on the same disk volume as Ntds.dit. Ensure that the reserve file
is either 250 MB or 1 percent of the available disk space, whichever is larger.
Recommendations for Enabling Only Essential Services

The following table provides a checklist of recommendations for enabling only essential
services and protocols on your domain controllers.

Check

Enabling Only Essential Services

Enable only the services that are required for a computer running Windows 2000
Server in the role of a domain controller.

Recommendations for Securing Domain Controller Files and Executables

The following table provides a checklist of recommendations for securing the Active
Directory files and executables on your domain controllers.
Check

Setting Appropriate NTFS File and Folder Permissions

Change the default permissions assignment on the volume root from Everyone to
Administrators.

Recommendations for Running Virus Scans on Domain Controllers

The following table provides a checklist of recommendations for running virus scans on
domain controllers.

Check Running Virus Scans on Domain Controllers

After promoting servers to domain controllers, continue to run virus scans and to
obtain regular virus signature updates from your antivirus software vendor.
Check

Preventing Interference Between Virus Scans and Active

Directory Database and Log File Access
Configure the antivirus software to exclude from scanning the Active Directory
database and log files that are specified in Table 12.

Check

Preventing Interference Between Virus Scans and FRS

Database and Log File Access
Configure the antivirus software to exclude from scanning the FRS database and log
files that are specified in Table 13.

Check Preventing Virus Scans from Triggering Excessive FRS Replication

Configure antivirus software to not scan files in SYSVOL.
Require script signing on domain controllers and administrative workstations.

Recommendations for Maintaining Physical Security

The following table provides a checklist of recommendations for maintaining the physical
security of your domain controllers.

Check Securing Domain Controllers Against Physical Access

Include UPSs.
Place domain controllers and UPSs in locked rooms.
Require cardkey locks or cipher-locks on the entrances to the locked rooms.
Require locks on individual domain controllers or on doors to the racks housing
domain controllers.
Require specific processes and procedures for the administration or repair of domain
controllers.
Check Preventing Domain Controllers from Booting into Alternate Operating Systems
Disable or remove the floppy disk drive, unless it is required for SYSKEY.
Disable or remove the CD-ROM or DVD drive.
Set the [timeout] parameter in the Boot.ini file to 0.
Check Protecting Domain Controllers on Restart by Using SYSKEY
Enable SYSKEY.
Note:
This recommendation may vary or may not be feasible, based on your scenario. For
more information, see "Protecting Domain Controllers on Restart by Using SYSKEY."
Check Securing Backup Media Against Physical Access
Store backup media used on-site in a locked cabinet or container.
Store archival backup media in off-site storage.
Establish processes and procedures that require signatures to bring any archival
storage back on-site.
Ensure that backup media is only installed during backup and that it is in secured
storage otherwise.

Check Enhancing the Security of the Network Infrastructure

Require cardkey locks or cipher-locks on the entrances to cabling rooms.
Require processes and procedures for any administration or repair of cabling,
switches, or routers.
Use strong passwords to secure the configuration of routers and switches.
Use different passwords for reading and configuring your routers and switches.
Check Securing the Remote Restart of Domain Controllers
When the domain controller is in a datacenter, connect the remote restart devices to the
secured management network.
When the domain controller is in a branch office, connect the remote restart device to
a dedicated modem, and require the modem to provide password identification and
callback functionality.
Top of page
Chapter 4: Establishing Secure Domain and Domain Controller Policy
Settings

Windows 2000 Active Directory contains default security policy settings for the domain and
for domain controllers. These settings are configured by default when Windows 2000 Server
Active Directory is installed, and they are applied to all newly promoted domain controllers.
To augment security for the domain and domain controllers, consider implementing the
changes to the default policy settings presented here. To improve security for domain and
domain controller policy settings, perform the following tasks:

Establish secure domain policy settings.

Establish secure domain controller policy settings.

Select policy settings for mixed operating system environments.

Apply selected domain and domain controller policy settings.

Establishing Secure Domain Policy Settings

Domain security policy settings provide Active Directory with domain-wide security options
for handling authentication and authorization of Active Directory security principals. These
policy settings are applied to all security principal accounts in the domain, unless inheritance
is specifically blocked or overridden by another policy.
Note:
Make all changes to the domain policy settings directly in the default Domain Group Policy

object (GPO), because application programming interfaces (APIs) that were developed for
earlier versions of the operating system update policy settings in the default Domain
Controllers GPO.
Domain Group Policy controls various categories of settings. To increase comprehensive
security for your domain, apply the recommended password, account lockout, and Kerberos
policy settings.
Domain policy settings are divided into multiple categories of settings. To increase
comprehensive domain security, perform the following tasks:

Establish password policy settings for domains.

Establish account lockout policy settings for domains.

Establish Kerberos policy settings for domains. (No changes to the default settings are
recommended.)

Securing Password Policy Settings for Domains

In Windows 2000, the most common method for authenticating a user's identity is the use of
secret user passwords. Once a user has been identified and authenticated, the user can
perform any tasks or access any resource for which he or she is authorized. Strong passwords
generally enhance security for Active Directory users. Using strong passwords helps avoid
the threat of an unauthorized user guessing (cracking) a weak password and acquiring the
credentials of the compromised user account (spoofing). This is especially true for
administrative accounts, because an unauthorized user could obtain administrative credentials
and gain elevated privileges.
A complex password that changes regularly reduces the likelihood of a successful spoofing
attack. Password policy settings control the complexity and lifetime for passwords. Table 14
includes the default and recommended password policy settings for a domain.
Table 14 Default and Recommended Password Group Policy Settings
Policy
Enforce password history

Default Recommended
1
24 passwords
passwords

Maximum password age 42 days

(No change)

Minimum password age

0 days

2 days

Minimum password
length

0
8 characters
characters

Comments
Prevents users from reusing passwords.

Prevents users from cycling through

their password history to reuse
passwords.
Ensures minimum password strength.

Password must meet

Disabled
complexity requirements

Enable

Store password using

reverse encryption for all Disabled
users in domain

(No change)

For the definition of a complex

password, see "Creating a Strong
Administrator Password" earlier in this
guide.

Note:
If possible, use smart cards throughout the organization to ensure the strongest possible
passwords on user accounts. Using smart cards causes the system to automatically generate
cryptographically strong random passwords for accounts. When you are unable to provide
smart cards for all users, require service administrator accounts to use smart cards. For more
information about smart cards, see "Establishing Secure Administrative Practices" later in this
guide.
Securing Account Lockout Policy Settings for Domains

More than a few unsuccessful password tries during logon could represent an attacker's
attempt to determine an account password by trial and error. Windows 2000 keeps track of
logon attempts, and it can be configured to respond to this type of attack by disabling the
account for a preset period of time. This is referred to as account lockout.
Account lockout policy settings control the threshold for this response and the actions to be
taken once the threshold is reached. Table 15 includes the default and recommended account
lockout policy settings.
Table 15 Default and Recommended Account Lockout Group Policy Settings
Policy
Account
lockout
duration
Account
lockout
threshold

Default Recommended

Reason

Not
0 minutes
defined

The value 0 means that after account lockout an

Administrator is required to re-enable the account
before account lockout reset has expired.

0 tries

The value 0 means that failed password tries never

cause account lockout. Because we are
recommending an account lockout duration of 0
(administrator reset), a small number here could
result in frequent administrator interventions.

20 tries

Reset account
Not
lockout
30 minutes
defined
counter after

This setting protects against a sustained dictionary

attack by imposing a nontrivial delay after five
unsuccessful attempts. A higher value for this setting
could result in increased help-desk calls for legitimate
account lockouts.

Securing Kerberos Policy Settings for Domains

In Windows 2000, Kerberos provides the default mechanism for authentication services, as
well as the authorization data necessary for a user to access a resource and perform a task on
that resource. By reducing the lifetimes of Kerberos tickets, the risk of having a legitimate
user's credentials stolen and successfully used by an attacker diminishes. However,
authorization overhead increases. Table 16 includes the default and recommended Kerberos
policy settings.
Table 16 Default and Recommended Kerberos Group Policy Settings
Policy

Default Recommended

Enforce user logon

restrictions

Enabled (No change)

Maximum lifetime for

service ticket

600
(No change)
minutes

Maximum lifetime for

user ticket

10 hours (No change)

Maximum lifetime for

user ticket renewal

7 days

Maximum tolerance for

computer clock
synchronization

5
(No change)
minutes

Comments
A user must have the right to log on
locally (for service on the same
computer) or to access the service from
the network.

(No change)
This refers to maximum tolerance
between the client's and server's clocks.

Establishing Secure Domain Controller Policy Settings

In addition to establishing Group Policy settings for your domains in Active Directory, you
can also establish Group Policy settings and Windows 2000 configuration settings to secure
your domain controllers. Domain controller policies are set on the Domain Controllers
organizational unit (OU) in each domain.
Domain controller policies are divided into multiple categories of settings. To enhance
comprehensive security for your domain controllers, perform the following tasks:

Establish domain controller user rights assignment policy settings.

Establish domain controller audit policy settings.

Enable auditing on Active Directory database objects.

Establish domain controller security options policy settings.

Establish domain controller event log policy settings.

Establishing Domain Controller User Rights Assignment Policy Settings

User rights allow users to log on and perform specific administrative or operations tasks on
your domain controllers. Ensure that the appropriate user rights are assigned to users in the
domain so that the users can perform their intended functions without compromising the
security of the domain controllers. Establish the policy settings for domain controller user
rights assignment to properly limit the users who can log on to the domain controllers and
perform the necessary administrative tasks.
Table 17 lists the default and recommended settings for domain controller user rights
assignment policies. All other user rights assignment policies are unchanged.
Note:
Make changes to the user rights assignment policy settings directly in the default Domain
Controllers GPO because APIs that were developed for earlier versions of the operating
system update the user rights assignment in the default Domain Controllers GPO.
Table 17 Default and Recommended Domain Controller User Rights Assignment
Policy Settings

Policy

Default Setting

Recommended
Setting

Comments

Administrators
Backup
Operators
Log on
locally

Account
Operators

Administrators
Backup Operators
Server Operators

Account Operators are for account

management and have few (if any) reasons
to log on locally.

Server
Operators
Administrators
Backup
Operators
Shut down
the system

Account
Operators
Server
Operators
Print Operators

Administrators
Backup Operators
Server Operators

Account Operators and Print Operators have

few (if any) reasons to shut down domain
controllers.

Note:
Members of the Backup Operators group can log on locally to domain controllers, archive
files to backup media, and overwrite system files through restore operations. The only
members of this group should be those users who perform domain controller backup and
restore operations. To reduce the number of users that have these rights, do not make users
who are responsible only for application backup and restore operations, such as SQL Server
operators, members of the Backup Operators group.
Establishing Domain Controller Audit Policy Settings

By default, Windows 2000 Active Directory does not configure any audit policy settings, and
no Active Directory access or domain controller operation is audited in the default
configuration. The recommendations presented here provide the minimum recommended
security audit policy settings that you should configure to maintain an audit trail of securitysensitive operations.
Important:
There are many possible goals that you can have when you audit a domain for security
purposes, such as intrusion detection or forensic analysis of security breaches. The primary
goal of the security audit settings is to provide accountability for sensitive directory
operations, including any administrative or configuration changes. When auditing for other
reasons, such as intrusion detection, additional auditing may need to be enabled.
When you enable auditing on a domain controller, the number of events that are recorded in
the Security event log increases. As a result, the maximum size of the Security event log must
be increased. For the recommended settings for the maximum size of the Security event log,
see "Establishing Domain Controller Event Log Policy Settings" later in this guide.
Note:
Make all changes to the domain controller audit policy settings directly in the default Domain
Controllers GPO, because APIs that were developed for earlier versions of the operating
system update in the default Domain Controllers GPO.
Table 18 lists the default and recommended settings for domain controller audit policies.
Table 18 Default and Recommended Domain Controller Audit Policy Settings

Policy

DefaultSetting

Audit account
No auditing
logon events
Audit account
Not defined
management

Recommended
Setting

Comments

Success

Account logon events are generated when a

domain user account is authenticated on a
domain controller.

Success

Account management events are generated

when security principal accounts are
created, modified, or deleted.

Audit directory
No auditing
service access

Success

Directory services access events are

generated when an Active Directory object
with a system access control list (SACL) is
accessed.
Logon events are generated when a domain
user interactively logs on to a domain
controller or when a network logon to a
domain controller is performed to retrieve
logon scripts and policies.

Audit logon
events

No auditing

Success

Audit object
access

No auditing

(No change)

Audit policy
change

No auditing

Success

Audit privilege
No auditing
use

(No change)

Audit process
tracking

(No change)

Audit system
events

No auditing

No auditing

Success

Policy change events are generated for

changes to user rights assignment policies,
audit policies, or trust policies.

System events are generated when a user

restarts or shuts down the domain controller
or when an event occurs that affects either
the system security or the security log.

Enabling Auditing on Active Directory Database Objects

Enabling the audit policies for your domain controller is only part of the task for auditing
your domain controller. In addition, you should enable auditing on important Active
Directory objects with suitable audit policy settings.
To set the required audits for an Active Directory object, you need to change the system
access control list (SACL) on the object. You should change the SACL of objects in Active
Directory based on the tables provided later in this section.
Active Directory comprises multiple directory partitions. Directory partitions are logical
divisions of the Active Directory database. To enable auditing on Active Directory database
objects, perform the following tasks:

Enable auditing on the Schema directory partition.

Enable auditing on the Configuration directory partition.

Enable auditing on the Domain directory partition.

For a procedure for these tasks, see "Enabling Auditing on Active Directory Database
Objects" in "Appendix: Procedures" later in this guide.
Note:
Be sure to remove any SACLs that were previously applied.
Enabling Auditing On the Schema Directory Partition

To enable auditing on the Schema directory partition, set the SACLs for the objects that are
listed in Table 19. The directory operations that are audited by the settings in Table 19 include
any additions, deletions, or modifications to the schema, as well as the transfer of the schema
operations master role.
Table 19 Settings for CN=Schema,CN=Configuration,DC=ForestRootDomain
Type

Name

Access
Modify Permissions

Apply To

Modify Owner
Create All Child Objects
Success Everyone

Delete

This object only

Delete All Child Objects

Delete Subtree
Success Everyone

Write All Properties

This object and all child objects

Success Everyone

Change Schema Master This object only

Success Administrator All Extended Rights

This object only

Success Domain Users All Extended Rights

This object only

Enable Auditing on the Configuration Directory Partition

To enable auditing on the Configuration directory partition, set the SACLs for the objects
listed in Table 20, Table 21, Table 22, Table 23, and Table 24.
The directory operations that are audited by the settings in Table 20 include any
modifications to the permissions and the wellKnownObjects attribute on the Configuration
directory partition.
Table 20 Settings for CN=Configuration,DC=ForestRootDomain

Type

Name

Success Everyone

Access
Modify Permissions
Modify Owner

Apply To

This object only

Write All Properties

Success Administrator All Extended Rights This object only
Success Domain Users All Extended Rights This object only
The directory operations that are audited by the settings in Table 21 include:

Addition and removal of domain controllers in the forest

Addition and removal of Group Policy settings that are applied to a site

Association and disassociation of a subnet with a site

Execution of the following control operations on a domain controller: Do Garbage

Collection, Recalculate Hierarchy, Recalculate Security Inheritance, and Check Stale
Phantoms
Table 21 Settings for CN=Sites,CN=Configuration,DC=ForestRootDomain
Type

Name

Access
Create All Child Objects

Apply To

Delete
Success Everyone

Delete All Child Objects

This object and all child objects

Delete Subtree
Success Everyone All Extended Rights
Write gPLink (property)

Domain Controller Settings objects

Success Everyone

Site objects

Write gPOptions (property)

Success Everyone Modify siteObject (property) Subnet objects

Success Everyone Modify siteObject (property) Site link objects
Success Everyone Modify siteObject (property) Connection objects
The directory operations that are audited by the settings in Table 22 include:

Addition and removal of domains (or external directory knowledge references) in the
forest
Modifications to valid UPN Suffixes for the forest

Transfer of the domain naming operations master role

Table 22 Settings for CN=Partitions,CN=Configuration,DC=ForestRootDomain

Type

Name

Access
Modify Permissions

Apply To

Modify Owner
Write All Properties
Success Everyone

Create All Child Objects

This object and all child objects

Delete All Child Objects

Delete Subtree
All Extended Rights
The directory operations that are audited by the settings in Table 23 include changes to the
dsHeuristics attribute, which controls certain characteristics of forest-wide behavior of the
directory service.
Table 23 Settings for CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=ForestRootDomain
Type

Name

Access

Apply To

Success Everyone Write dSHeuristics (property) This object only

The directory operations that are audited by the settings in Table 24 include changes to forestwide parameters that govern the behavior of Lightweight Directory Access Protocol (LDAP)based queries and operations.
Table 24 Settings for CN=Default Query Policy,CN=Query-Policies,CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain
Type

Name

Access

Apply To

Success Everyone Write lDAPAdminLimits (property) This object only

Enabling Auditing on the Domain Directory Partition

To enable auditing for the Configuration directory partition, set the SACLs for the objects
listed in Table 25, Table 26, Table 27, Table 28, Table 29, and Table 30.
The directory operations that are audited by the settings in Table 25 include:

Transfer of the PDC emulator operations master role

Addition and removal of Group Policy settings that are applied to the domain

Modifications to valid DNS Suffixes for the domain

Modifications to the permissions and the wellKnownObjects attribute on the Domain

directory partition

Migration of SID history

Table 25 Settings for DC=Domain,DC=...ForestRootDomain
Type

Name

Success Everyone

Access
Modify Permissions
Modify Owner

Apply To

This object only

Write All Properties

Success Administrators All Extended Rights This object only
Success Domain Users All Extended Rights This object only
The directory operations that are audited by the settings in Table 26 include:

Addition and removal of domain controllers for the domain

Modifications to any properties of domain controller computer accounts
Table 26 Settings for OU=Domain
Controllers,DC=Domain,DC=...ForestRootDomain
Type

Name

Access
Modify Permissions

Success Everyone

Apply To
This object only

Modify Owner
Create All Child Objects
Delete

Delete All Child Objects

Delete Subtree
Success Everyone Write All Properties

This object and all child objects

The directory operations that are audited by the settings in Table 27 include the transfer of the
infrastructure operations master role.
Table 27 Settings for CN=Infrastructure,DC=Domain,DC=...ForestRootDomain
Type

Name

Access
All Extended Rights

Success Everyone

Write All Properties

Apply To
This object only

The directory operations that are audited by the settings in Table 28 include:

Addition and removal of GPOs

Modifications to GPOs
Table 28 Settings for
CN=Policies,CN=System,DC=Domain,DC=...ForestRootDomain
Type

Name

Access
Modify Permissions

Apply To

Modify Owner
Create groupPolicyContainer
Objects
Success Everyone

Delete

This object only

Delete groupPolicyContainer
Objects
Delete Subtree
Modify Permissions
Success Everyone

Write All Properties

GroupPolicyContainer objects

The directory operations that are audited by the settings in Table 29 include modifications to
the special security descriptor that protects all service administrator accounts.

Table 29 Settings for

CN=AdminSDHolder,CN=System,DC=domain,DC=...ForestRootDomain
Type

Name

Success Everyone

Access
Modify Permissions
Modify Owner

Apply To

This object only

Write All Properties

The directory operations that are audited by the settings in Table 30 include the transfer of the
RID operations master role.
Table 30 Settings for CN=RID
Manager$,CN=System,DC=Domain,DC=...ForestRootDomain
Type

Name

Success Everyone

Access
All Extended Rights
Write All Properties

Apply To
This object only

Establishing Domain Controller Security Options Policy Settings

Policy settings for domain controller security options affect the security-related Windows
2000 Server configuration settings. The domain controller security options policy settings
affect not only the Active Directory-related security configuration settings, but other
components in Windows 2000 as well, such as the network, file system, and user logon
security configuration settings. Table 31 lists the default and recommended policy settings for
domain controller security options.
Table 31 Recommended Domain Controller Security Options Policy Settings

Policy
Additional
restrictions for
anonymous
connections

DefaultSetting

Recommended
Setting

Not defined

For operating system requirements, see

(See comments) "Selecting Policy Settings for Mixed
Operating System Environments."

Allow Server
Operators to
schedule tasks
Not defined
(domain controllers
only)

Disabled

Comments

Restricts the individuals who can

schedule tasks to Administrators,
because scheduling usually runs as an
elevated service.

Allow system to be
shut down without Not defined
having to log on

Disabled

Allow to eject
removable NTFS
media

Allows only Administrators to eject

Administrators removable NTFS media to protect
against the theft of sensitive data.

Not defined

Requires an authenticated, authorized

service account to shut down or restart
the domain controller.

15 minutes

Controls when a domain controller

suspends an inactive server message
block (SMB) session, which has no
security implications but which reduces
SMB traffic resource usage.

Disabled

Disables the creation of a default SACL

on system objects, such as mutexes
(mutual exclusive), events, semaphores,
and DOS devices because the default
policy is "No auditing."

Disabled

Disables auditing for the use of user

privileges, including Backup and
Restore, when the "Audit privilege use"
policy is enabled because this policy is
configured for "No auditing."

Enabled

Forcibly disconnects client sessions

with the SMB Service when the user's
logon hours expire to ensure that
network connections are secured during
nonworking hours.

Enabled

Forcibly logs off users with interactive

sessions when the user's logon hours
expire to ensure that network
connections are secured during
nonworking hours.

Clear virtual
memory pagefile
Not defined
when system shuts
down

Enabled

Eliminates process memory data from

going into the pagefile on shutdown in
case an unauthorized user manages to
directly access the pagefile.

Digitally sign client

communication
Not defined
(always)

See "Selecting Policy Settings for

(See comments) Mixed Operating System
Environments" for requirements.

Digitally sign client Not defined

(No change)

Amount of idle time

required before
Not defined
disconnecting
session

Audit the access of

global system
Not defined
objects

Audit use of
Backup and Restore Not defined
privilege

Automatically log
off users when
Not defined
logon time expires

Automatically log
off users when
Not defined
logon time expires
(local)

See "Selecting Policy Settings for

communication
(when possible)

Mixed Operating System

Environments" for requirements.

Digitally sign server

communication
Not defined
(always)

See "Selecting Policy Settings for

(See comments) Mixed Operating System
Environments" for requirements.

Digitally sign server

communication
Enabled
(when possible)

(No change)

See "Selecting Policy Settings for

Mixed Operating System
Environments" for requirements.

Disabled

Requires CTRL+ALT+DEL before

users log on to ensure that users are
communicating by means of a trusted
path when entering their passwords.

Do not display last

user name in logon Not defined
screen

Enabled

Removes the name of the last user to

successfully log off from the Log On to
Windows dialog box to prevent
attackers from discovering service
account names on domain controllers.

LAN Manager
Authentication
Level

See "Selecting Policy Settings for

(See comments) Mixed Operating System
Environments" for requirements.

Disable CTRL +
ALT + DEL
requirement for
logon

Not defined

Not defined

Message text for

users attempting to Not defined
log on

(No change)

Message title for

users attempting to Not defined
log on

(No change)

Number of previous
logons to cache (in
case domain
Not defined
controller is not
available)
Prevent system
maintenance of
computer account
password

Not defined

0 logons

Disabled

The value 0 indicates that the domain

controller does not cache previous
logons and requires authentication at
each logon.
Not enabled because computer account
passwords are used to establish secure
channel communications between
members and domain controllers and,
within the domain, between the domain
controllers themselves. After it is
established, the secure channel is used
to transmit sensitive information that is

necessary for making authentication and

authorization decisions.

Enabled

Allows only Administrators and Server

Operators to install a printer driver
when adding a network printer to ensure
that users cannot install a printer driver
(add a network printer) and perform
disk-space attacks by submitting large
print jobs.

14 days

Notifies users in advance (in days) that

their password is about to expire so that
the user has time to construct a
password that is sufficiently strong.

Disabled

Requires that an Administrator account

password must be given before access is
granted to a domain controller to ensure
that anyone logging on requires
administrator credentials.

Recovery Console:
Allow floppy copy
and access to all
Not defined
drivers and all
folders

Disabled

Prevents unauthorized users from

gaining access to, copying, and
removing the Active Directory database
and other secure files from the domain
controller.

Rename
administrator
account

Not defined

(No change)

Rename guest
account

Not defined

(No change)

Prevent users from

installing printer
Not defined
drivers

Prompt user to
change password
before expiration

Not defined

Recovery Console:
Allow automatic
Not defined
administrative
logon

Restrict CD-ROM
access to locally
Not defined
logged-on users
only

Restrict floppy
access to locally
logged-on users
only

Not defined

Enabled

Allows only the interactively logged-on

service administrator to access
removable CD-ROM media to ensure
that when no one is logged on
interactively, the CD-ROM cannot be
accessed over the network.

Enabled

Allows only interactively logged-on

service administrators to access
removable floppy media to ensure that
the floppy cannot be accessed over the
network when no one is logged on.

Secure channel:
Digitally encrypt or
Not defined
sign secure channel
data (always)

Enabled

Secure channel:
Digitally encrypt
Not defined
secure channel data
(when possible)

(No change)

Secure channel:
Digitally sign
Not defined
secure channel data
(when possible)

(No change)

Secure channel:
Require strong
Not defined
(Windows 2000 or
later) session key

Enabled

Secure system
partition (for RISC Not defined
platforms only)

(No change)

Send unencrypted
password to connect
Not defined
to third-party SMB
servers

Shut down system

immediately if
Not defined
unable to log
security audits

Smart card removal

Not defined
behavior

Requires Windows NT 4.0 with Service

Pack 6 (SP6) or newer software on all
domain controllers in local and all
trusted domains to ensure that all
security fixes have been made.

Requires that a secure channel be

established with 128-bit encryption to
ensure that the key strength is not
negotiated but always uses the most
secure connection possible with the
domain controller.

Disabled

Prohibits the SMB redirector from

sending plaintext passwords to nonMicrosoft SMB servers that do not
support password encryption. Disable
this policy unless your domain
controller needs to communicate with
non-Microsoft SMB servers.

Disabled

Stops the domain controller if a security

audit cannot be logged. The auditing
goals for domain controllers in
"Establishing Domain Controller Audit
Policy Settings" allow overwriting
Security audit events as required.

Force logoff

Forces service administrators to keep

smart cards inserted while logged on
interactively on domain controllers to
ensure that domain controllers are not
left logged on to and unattended.

Strengthen default
permissions of
global system
Not defined
objects (e.g.
Symbolic Links)

Enabled

Allows users who are not administrators

to read shared objects but not modify
them. Strengthens the default DACL of
objects in the global list of shared
resources, such as DOS device names,
mutexes, and semaphores.

Unsigned driver
installation
behavior

Not defined

Do not allow
installation

Prevents insecure or untrusted device

drivers from being installed on domain
controllers.

Not defined

Nondriver signing was not implemented

in most software applications and
Silently succeed services. This policy has no real benefit,
and it is set to eliminate unnecessary
notification.

Unsigned nondriver installation

behavior

Establishing Domain Controller Event Log Policy Settings

If you enable the recommended domain controller audit policy, the maximum size of the
security log should also be increased to accommodate the increased number of audited events
that will be generated.
The event log policy settings recommended here reflect the changes that are necessary to
support the recommended audit policy. In your environment, you may need to adjust the
policy settings for the application or system event logs to support other operational goals.
As a part of your normal operations tasks, archive the security and system event logs
regularly and frequently before they fill up, which can cause events to be missed. The
recommended event log policy settings allow the events in the security and system event logs
to be overwritten as needed. Back up the logs for future reference before any events can be
overwritten.
Table 32 lists the default and recommended settings for domain controller event log policy
settings.
Table 32 Recommended Domain Controller Event Log Policy Settings

Policy

DefaultSetting

Recommended
Setting

Maximum
Not defined
application log size

(No change)

Maximum security
Not defined
log size

128 MB

Comments

Increased to accommodate security

auditing that is enabled in the domain
controller audit policies.

Maximum system
Not defined
log size

(No change)

Restrict guest
access to
application log

Not defined

Enabled

Prevents members of the built-in group

Guests from reading the application log
events.

Restrict guest
access to security Not defined
log

Enabled

Prevents members of the built-in group

Guests from reading the security log
events.

Enabled

Prevents members of the built-in group

Guests from reading the system log
events.

Restrict guest
access to system
log

Not defined

Retain application
Not defined
log

(No change)

Retain security log Not defined

(No change)

Retain system log Not defined

(No change)

Retention method
Not defined
for application log

(No change)

Retention method
Not defined
for security log

Overwrites the security log when the

maximum log size is reached to ensure
Overwrite events
that the log contains the most recent
as needed
security events and to ensure that
logging continues.

Retention method
Not defined
for system log

Overwrites the system log when the

maximum log size is reached to ensure
Overwrite events
that the log contains the most recent
as needed
security events and to ensure that
logging continues.

Shutdown the
computer when the
Not defined
security audit log
is full

(No change)

Selecting Policy Settings for Mixed Operating System Environments

Although you are deploying - or have already deployed - Active Directory and Windows
2000 Server, your organization may have a mixture of earlier versions of Windows operating
systems running on client and server systems. These operating systems include Microsoft
Windows 95, Windows 98, Windows Millennium Edition, and Windows NT 4.0.

Although Active Directory domain controllers support all the security features discussed in
this guide, earlier versions of Windows operating systems support only a subset of the
security features in Active Directory and Windows 2000 Server. These earlier versions of
Windows operating systems can run on workstation computers, member servers, and domain
controllers. When your environment includes a mixture of Windows operating systems, you
may have to adjust the security recommendations, given earlier in this chapter, to provide
compatibility with the earlier versions of Windows operating systems.
Some of the security settings cannot be configured through Group Policy. Instead, these
settings must be set directly through the domain controller's registry. Incorporate as many of
these additional security settings as possible. When you are unable to adopt all the
recommendations presented here, modify the registry script to reflect the security settings that
you need in your organization.
Caution:
Do not edit the registry unless you have no alternative. The registry editor bypasses standard
safeguards, allowing settings that can damage your system, or even require you to reinstall
Windows. If you must edit the registry, back it up first and see the Registry Reference in the
Microsoft Windows 2000 Server Resource Kit at .
Secure Active Directory in mixed operating system environments by:

Identifying when earlier versions of operating systems are an issue.

Restricting anonymous access to domain controllers.

Disabling LAN Manager authentication.

Signing SMB traffic between domain controllers and between domain controllers and
member computers.

Disabling Pre-Windows 2000 Compatibility access.

Note:
Restart the domain controller after any change to any of these registry settings so that
the settings can take effect.

Identifying When Earlier Versions of Operating Systems Are an Issue

When your network environment is made up of Windows 2000 and later operating systems,
you can incorporate all the security recommendations that are described in this document.
When your network environment is made up of Windows operating systems earlier than
Windows 2000, implementing these security recommendations may disrupt the normal
operation of your network.
Compatibility issues with Windows operating systems earlier than Windows 2000 can be
divided into the following categories:

Authenticating users with earlier authentication protocols

Digitally signing file services, print services, and other SMB traffic

Allowing anonymous access to domain controllers

Authenticating Users with Earlier Authentication Protocols

Any authentication protocol earlier than Windows NT challenge/response version 2

(NTLMv2) provides weaker security. To provide the strongest possible security, ensure that
all domain controllers, member servers, and workstations support NTLMv2. For a more
detailed description of the requirements to support NTLMv2, see "Disabling LAN Manager
Authentication" later in this guide.
Digitally Signing File Services, Print Services, and Other SMB Network Traffic

The SMB protocol provides the basis for Microsoft file and print sharing and for many other
networking operations, such as remote Windows administration. To prevent attacks that
modify SMB packets in transit, the SMB protocol supports the digital signing of SMB
packets.
Domain controllers, member servers, and workstations access file shares during the user
logon process to access logon scripts and profiles in the NETLOGON share. Also, the File
Replication service (FRS) uses file shares. As a result, all domain controllers should take
advantage of SMB signing to improve security. For a more detailed description of the
requirements for supporting SMB signing, see "Enabling SMB Signing on Domain
Controllers" later in this guide.
Allowing Anonymous Access to Domain Controllers

Some of the operating systems and applications that were developed before Windows 2000
require anonymous access to other servers, including domain controllers. For example, the
Spooler service running on Windows NT 4.0 requires anonymous access to remote printers.
Because the focus for this guide is on securing Active Directory, the ideal security goal would
be to disable all anonymous access to your domain controllers. For a more detailed
description of the requirements for allowing anonymous access to domain controllers, , see
"Restricting Anonymous Access to Domain Controllers" later in this guide.
Allowing Anonymous Access to Active Directory Data

Certain applications also require anonymous access to Active Directory data. For example,
SQL Server version 6.0 and Routing and Remote Access Service running on Windows NT 4.0
require anonymous access to Active Directory to authenticate users and enumerate their
group memberships when it is running in Mixed or Windows Integrated security modes.
Because the focus for this guide is on securing Active Directory, the ideal security goal is to
disable all anonymous access to Active Directory data. You can eliminate anonymous access
to your Active Directory data by performing the following tasks:
1. Enable security monitoring for anonymous access on all domain controllers. For a
procedure to perform this task, see "Monitoring for Anonymous Access" in
"Appendix: Procedures" later in this guide.

2. Monitor the security logs for servers that initiate anonymous access to the domain
controllers for about 30 days. For a procedure to perform this task, see "Monitoring
for Anonymous Access" in "Appendix: Procedures" later in this guide.
3. Identify the applications running on the server that initiate anonymous access.
4. Eliminate the requirement for anonymous access to the domain controllers.
Based on the type of anonymous access that you identify in the list below, follow the
recommendations in the corresponding section to eliminate the requirement for that
type of anonymous access to your domain controllers:
o
o

Restricting Anonymous Access to Domain Controllers

Disabling Pre-Windows 2000 Compatibility Access

5. Monitor the security logs for servers that initiate anonymous access to the domain
controllers for another 30 days.
6. After reviewing the security logs and ensuring that the domain controllers are not
accessed anonymously, you are ready to disable the corresponding security feature
that allows anonymous access by following the tasks for the same corresponding
sections that you select in step 4.
Figure 10 illustrates the process that is described in the previous steps.

Figure 10 Process for Detecting and Eliminating Anonymous Access to

Active Directory Data
Restricting Anonymous Access to Domain Controllers

If possible, restrict anonymous user access to your domain controllers. However, many
earlier-version domain controllers, member servers, or workstations use anonymous access to
perform normal system functions. For example, establishing trust relationships between a
Windows NT 4.0 domain and a Windows 2000 domain requires anonymous access. These
anonymous access connections are also known as null session connections.
You can use the Security Option policy Additional restrictions for anonymous
connections, which is listed in "Establishing Domain Controller Security Options Policy
Settings" earlier in this guide, to adjust the level of anonymous access that you can allow to
your domain controller.
The levels of anonymous access that you can allow include:

None. Rely on default permissions (default).

With this policy setting, anonymous connections are only restricted by the resource
permissions on individual resources.

Do not allow enumeration of SAM accounts and shares.

With this policy setting, anonymous connections cannot display lists of share names.
This setting does not affect the ability of anonymous connections to enumerate users
and groups in Active Directory, because domain controllers have no registry-based
SAM. For more information about disabling anonymous access to Active Directory,
see "Disabling Pre-Windows 2000 Compatible Access" later in this guide.

No access without explicit anonymous permissions.

With this policy setting, anonymous connections have no access without explicit
anonymous permissions being granted to resources. The access token that is built for
anonymous connections on a domain controller with this setting does not include the
special group Everyone. As a result, anonymous connections cannot enumerate users
and groups in Active Directory even if the domain is in Pre-Windows 2000
Compatibility mode. This can cause undesired behavior, because many Windows
2000 services, as well as third-party programs, rely on anonymous access capabilities
to perform legitimate tasks.

Consider using the last two policy settings only when your network environment consists of
domain controllers, member servers, and workstations - all running Windows 2000 or later.
For example, when an administrator in a trusting domain wants to grant local access to a user
in a trusted domain, the users in the trusted domain need to be enumerated. Because the
trusted domain cannot authenticate the trusting domain's administrator, the request is made
anonymously.
The benefits of restricting the capabilities of anonymous users from a security perspective
should be weighed against the corresponding requirements of services and programs that rely
on anonymous access for complete functionality.
The following limitations apply when the policy is set to No access without explicit
anonymous permissions:

Earlier-version member workstations or servers are not able to set up a Netlogon

secure channel.
Note:
Earlier-version workstations and servers include computers running Microsoft
operating systems earlier than Windows NT 4.0 SP3.

Earlier-version domain controllers in trusting domains are not be able to set up a

Netlogon secure channel.
Windows NT users are not able to change their passwords after they expire. Also,
Macintosh users are not able to change their passwords at all.

The Browser service is not able to retrieve domain lists or server lists from backup
browsers, master browsers, or domain master browsers running on domain controllers
with the policy set. Because of this, any program that relies on the Browser service
does not function properly.

Because of these side effects, avoid setting the policy to No access without explicit
anonymous permissions in mixed-mode environments that include earlier-version clients.
Configuring the policy to this setting should only be considered in Windows 2000
environments and only after sufficient quality assurance tests have verified that appropriate
service levels and program functionality are maintained.
The registry setting that corresponds to this policy setting is as follows:
HKLM\System\CurrentControlSet\Control\Lsa
Entry name: RestrictAnonymous
Data type: REG_DWORD
Value: 1
For more information about restricting anonymous access, see article Q246261, "How to Use
the RestrictAnonymous Registry Value in Windows 2000," and related articles in the
Microsoft Knowledge Base.
You can create a script that automatically restricts anonymous access on all domain
controllers in the domain by performing the following tasks:
1. Create the ComputerSearch.vbs script, and copy it to a computer that is a member of
the domain.
For information about how to create this script, see "Identifying Computers to
Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B:
Procedures" of the Best Practice Guide for Securing Active Directory Installations
and Day-to-Day Operations: Part II.
2. Create a list of domain controllers in the domain by typing the following command at
a command prompt:
3. Cscript computersearch.vbs /r:DC

This command creates a list of domain controllers in the domain and saves this list as
ComputerSearch-date-time.csv.
4. Create the ApplyReg.vbs script, and copy it to a computer that is a member of the
domain.
For information about how to create this script, see "Applying Registry Settings to a
List of Computers with ApplyReg.vbs" in "Appendix B: Procedures" of the Best
Practice Guide for Securing Active Directory Installations and Day-to-Day
Operations: Part II.
5. Create a .reg file for the following path, registry entry, and value:
6. [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa]

7. "RestrictAnonymous"=dword:00000001

Save the file as Registryfile.reg. For information about how to create the .reg file, see
"Creating a .reg File" in "Appendix: Procedures" later in this guide:
8. Apply the registry entry to the domain controllers by typing the following command
at the command prompt:
9. Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-datetime.csv

This set of tasks applies the registry changes that are expressed in the file
Registryfile.reg to all computers that are listed in the file ComputerSearch-datetime.csv.
Disabling LAN Manager Authentication

By default, earlier versions of Windows operating systems support only the LAN Manager
(LM) authentication protocol. To provide compatibility with these earlier versions of
Windows, Active Directory stores the account passwords in an LM hash format. Active
Directory stores the password for the Windows NT authentication protocol (NTLM) and
NTLM version 2 (NTLMv2) protocols in NTLM hash format.
Because the NTLM hash is cryptographically stronger than the LM hash, disable the storage
of passwords in LM hash format to provide higher security. In the event that an attacker
removes a domain controller or a domain controller hard disk, it is easier for that attacker to
decrypt the passwords in LM hash format.
When you use a SYSKEY password or floppy disk, you encrypt the entire Active Directory
database and protect any passwords. When you use one of these SYSKEY methods, there is
no benefit to disabling the storing of passwords in LM hash format, aside from reducing the
size of the Active Directory database.
For more information about allowing only the NTLMv2 authentication protocol, see articles
285901, "Remote Access and VPN Clients Cannot Connect to a Server with
NtlmcompatabilityLevel Set to 5"; 281648, "Error Message: The Account Is Not Authorized
to Login from This Station"; and Q239869, "How to Enable NTLM 2 Authentication for
Windows 95/98/2000 and NT" in the Microsoft Knowledge Base at
http://go.microsoft.com/fwlink/?LinkId=4441.
Disable the storing of passwords in LM hash format by performing the following tasks:
1. Configure all domain controllers, member servers, and workstations to support the
NTLMv2 authentication protocol.
Table 33 lists the operating systems and the software requirements to support the
NTLMv2 authentication protocol.
Table 33 Operating System and Software Requirements to Support NTLMv2

Operating System

Requires

Windows 95, Windows

98, Windows Me

The Directory Services Client (Dsclient.exe), found in the

Clients\Win9x folder on Windows 2000 CD-ROM.

Windows NT 4.0
Workstation and Server

Service Pack 4 (SP4) or later.

Windows 2000
Professional and Server

Included as part of the operating system.

Windows XP Professional Included as part of the operating system.

2. Configure the domain controller Group Policy setting LAN Manager Authentication
Level found in Table 31 to the value Send NTLMv2 responses/reject LM.
3. Configure each domain controller registry setting to disable the creation of passwords
in LM hash format by modifying the registry key
HKLM\System\CurrentControlSet\Control\Lsa:
Entry name: NoLMHash
Data type: REG_DWORD
Value: 1
Caution:
Do not edit the registry unless you have no alternative. The registry editor bypasses
standard safeguards, allowing settings that can damage your system, or even require
you to reinstall Windows. If you must edit the registry, back it up first and see the
Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
You can create a script that automatically disables the creation of passwords in LM
hash format on all domain controllers in the domain by performing the following
tasks:
1. Create the ComputerSearch.vbs script, and copy it to a computer that is a
member of the domain.
For information about how to create this script, see "Identifying Computers to
Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B:
Procedures" of the Best Practice Guide for Securing Active Directory
Installations and Day-to-Day Operations: Part II.
2. Create a list of domain controllers in the domain by typing the following
command at a command prompt:
3. Cscript computersearch.vbs /r:DC

This command creates a list of domain controllers in the domain and saves this
list as ComputerSearch-date-time.csv.

4. Create the ApplyReg.vbs script, and copy it to a computer that is a member of

the domain.
For information about how to create this script, see "Applying Registry
Settings to a List of Computers with ApplyReg.vbs" in "Appendix B:
Procedures" of the Best Practice Guide for Securing Active Directory
Installations and Day-to-Day Operations: Part II.
5. Create a .reg file for the following path, registry entry, and value:
6. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
7. "NoLMHash"=dword:00000001

Save the file as Registryfile.reg. For information about how to create the .reg file, see
"Creating a .reg File" in :Appendix: Procedures" later in this guide.
4. Apply the registry entry to the domain controllers by typing the following command
at the command prompt:
5. Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-datetime.csv

This set of tasks applies the registry changes that are expressed in the file
Registryfile.reg to all computers that are listed in the file ComputerSearch-datetime.csv.
6. Require all users to change their passwords immediately.
The passwords that are already created in LM hash format are retained until the users
change their passwords. Forcing password changes eliminates any passwords that are
stored in LM hash format.
Enabling SMB Signing on Domain Controllers

The SMB protocol provides the basis for Microsoft file and print sharing and many other
networking operations, such as remote Windows administration. To prevent "man-in-themiddle" attacks that modify SMB packets in transit, the SMB protocol supports the digital
signing of SMB packets.
Domain controllers, member servers, and workstations access file shares during the user
logon process to access logon scripts and profiles in the NETLOGON share. In addition,
domain policies are accessed through the SYSVOL share. As a result, all domain controllers
should take advantage of SMB to improve security.
You can specify Group Policy settings that make SMB signing a requirement or that allow the
SMB server or client to negotiate SMB packet signing. Table 34 lists the Group Policy
settings for SMB signing, and it explains how each setting affects client and server
communications.
Table 34 Group Policy Settings for SMB Packet Signing

SMB Setting
Digitally sign client
communication
(always)

Explanation
The domain controller requires SMB signing when initiating SMB
requests with other domain controllers, member servers, or
workstations. The domain controller will not communicate with other
systems that do not support SMB signing. For enhanced security,
enable this Group Policy setting.

The domain controller negotiates SMB signing when initiating SMB

requests with other domain controllers, member servers, or
Digitally sign client
workstations. The domain controller requests SMB signing, but it will
communication (when
communicate with other systems that do not support SMB signing. For
possible)
compatibility with Windows 95 and earlier operating systems, enable
this Group Policy setting.
Digitally sign server
communication
(always)

The domain controller requires SMB signing when receiving SMB

requests from other domain controllers, member servers, or
workstations. The domain controller will not communicate with other
systems that do not support SMB signing. For higher security, enable
this Group Policy setting.

The domain controller negotiates SMB signing when receiving SMB

requests with other domain controllers, member servers, or
Digitally sign server
workstations. The domain controller requests SMB signing, but it will
communication (when
communicate with other systems that do not support SMB signing. For
possible)
compatibility with Windows 95 and earlier operating systems, enable
this Group Policy setting.
Enable the Digitally sign client communication (when possible) and Digitally sign server
communication (always) Group Policy settings on your domain controller unless:

Your network has a large number of Windows 95 and earlier operating systems, and
you are unable to upgrade these systems to Windows 98 or later operating systems.
(SMB signing requires Windows 98 and later operating systems.)
Your domain controllers, member servers, and workstations have insufficient
available processor utilization to support SMB signing. SMB signing generates higher
processor utilization on the client and server side (an increase of up to 15 percent in
processor utilization).

Enabling Digitally sign server communication (always) on your domain controller

overrides the default value of Digitally sign server communication (when possible).
Note:
By default, the local policy on stand-alone computers does not perform SMB signing.
Therefore, if a domain controller with the setting Digitally sign client communication
(always), attempts to communicate with a server that does not perform SMB signing, the
operation fails.

Disabling Pre-Windows 2000 Compatible Access

In some instances, your domain controllers are already installed and configured with PreWindows 2000 Compatibility enabled. For security reasons, you should, if possible, disable
Pre-Windows 2000 Compatibility to prevent anonymous access to Active Directory.
As previously discussed, enabling Pre-Windows 2000 Compatibility allows certain
applications, such as Routing and Remote Access Service on Windows NT 4.0, to query
information about Active Directory objects. These applications run in the security context of
the Local System. When they attempt to query Active Directory, they do so as anonymous
users. Enabling Pre-Windows 2000 Compatibility allows anonymous Read access to these
applications.
In Active Directory, the group Pre-Windows 2000 Compatible Access is assigned Read
permissions on the domain root and on user, computer, and group objects. When you enable
Pre-Windows 2000 Compatibility, the special group Everyone is added to the group PreWindows 2000 Compatible Access. Because Everyone includes anonymous users, in addition
to authenticated users, anonymous users can read these objects.
The process for identifying the server and applications that require anonymous access to
Active Directory is discussed in general in "Allowing Anonymous Access to Domain
Controllers" earlier in this guide. However, the specifics on how to eliminate the requirement
for anonymous access and how to disable anonymous access on your domain controller are
provided in the following sections, below:

"Eliminating the Requirement for Pre-Windows 2000 Compatibility"

"Disabling Pre-Windows 2000 Compatibility on Your Domain Controllers"

For more information about Pre-Windows 2000 Compatibility, see articles 257942, "Error
Message: Unable to Browse the Selected Domain Because the Following Error Occurred ...";
303973, "HOW TO: Add Users to the Pre-Windows 2000 Compatible Access Group";
240855, "Using Windows NT 4.0 RAS Servers in a Windows 2000 Domain"; 254311,
"Enable Windows NT 4.0-Based RAS Servers in a Windows 2000-Based Domain"; and
266712, "SMS: Security Based on Global Groups Fails in Windows 2000 Domains" in the
Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=4441.
Eliminating the Requirement for Pre-Windows 2000 Compatibility

Typically, a newer version of the software, for example Routing and Remote Access in
Windows 2000, does not require anonymous access. You must upgrade to a newer version of
the software before you can disable Pre-Windows 2000 Compatibility.
Disabling Pre-Windows 2000 Compatibility on Your Domain Controllers

After you are certain that no applications are establishing anonymous connections to your
domain controllers, you are ready to disable Pre-Windows 2000 Compatibility. You can do
this by removing the special group Everyone from the group Pre-Windows 2000 Compatible
Access and adding the special group Authenticated Users to the group Pre-Windows 2000
Compatible Access.

To disable Pre-Windows 2000 Compatibility

1. On the PDC emulator role holder, remove Everyone from the Pre-Windows 2000
Compatible Access group.
2. Add Authenticated Users to the Pre-Windows 2000 Compatible Access group.
3. Wait for changes to replicate to all domain controllers in the domain.
Note:
You can push the changes to other domain controllers by using the following
command:
repadmin /syncall /d/e/P/q DNS name of the PDC emulator role holder

4. On every domain controller in the domain, run the following command:

5. net session /delete

For more information about performing this task, see "Disabling Pre-Windows 2000
Compatibility" earlier in this guide.
Applying Selected Domain and Domain Controller Security Settings

The changed policy settings recommended in this chapter apply to either the default domain
Group Policy or the default Domain Controllers OU Group Policy. After you have selected
the list of settings that you want to update according to the business considerations and
security requirements for your environment, the method that you use to make the necessary
changes depends on the specific policy or settings that are updated.
To apply the recommended security updates, you can modify Group Policy in one of two
ways. First, you can modify the default domain policy and the default Domain Controllers
OU policy directly to update policy settings. Second, you can create a new Group Policy
object (GPO) with the modified settings and link it above the default GPO so that the
changed settings take precedence over the default settings.
When you apply changes to Group Policy settings in the following policies, the changes must
be made directly in the default domain GPO or in the default Domain Controllers OU GPO:

Domain password policy

Domain account lockout policy

Domain Kerberos policy

Domain Controller User Rights Assignment policy

Domain Controller Audit policy

Important:
Policy setting changes to the policies listed above must be made in the default policy,
because the APIs from previous versions of the operating system change the settings
for these policies by making updates directly to the default policy GPO.

Table 35 lists the Active Directory locations where the default policies are applied, the type of
settings in each default policy, and the method for applying the recommended changes to the
Group Policy settings.
Table 35 Methods for Applying Changed Settings in Group Policy
Location Where
Policy Is Applied

Policy Settings Being Changed

How to Apply the Changed

Settings in Policy

Domain root

Domain security policy settings

(Password Policy, Account Lockout
Policy, and Kerberos Policy)

Make all changes to the default

domain GPO.

Domain
Controllers OU

User Rights Assignment

Make all changes to the default

Domain Controllers OU GPO.

Audit

Make all changes to the default

Domain Controllers OU GPO.

Event Log

Create a new GPO, and link this

GPO above the default Domain
Controllers OU GPO.

Security Options

Create a new GPO, and link this

GPO above the default Domain
Controllers OU GPO.

When a new Windows 2000 domain is created, Active Directory creates a domain object and
a built-in, protected OU called OU=Domain Controllers directly under the domain root for
domain controllers. Active Directory places the new domain controller computer account in
this special OU. As additional domain controllers are promoted, the corresponding computer
accounts are also placed in the Domain Controllers OU. Figure 11 shows the Domain
Controllers OU and two of the default containers that are created when Active Directory is
installed.

Figure 11

Default Containers and OU Created by Active Directory

All domain controller computer accounts in a domain should remain in the default Domain
Controllers OU to ensure that domain-controller-specific Group Policy settings are
consistently applied to all domain controllers in a domain.
Note:
In addition to the Domain Controllers OU, Active Directory also builds two containers: Users
and Computers. Unlike the Domain Controllers OU, Users and Computers represent
containers; therefore, Group Policy settings cannot be applied to objects in these containers.
Modifying the Default Group Policy for the Domain and the Domain Controllers
OU

Apply changes directly in the default domain GPO for Password Policy settings, Account
Lockout Policy settings, and Kerberos Policy settings. Apply changes directly in the default
Domain Controller OU GPO for User Rights Assignment Policy settings and Audit Policy
settings.
Update the default domain and Domain Controllers OU GPOs by following the procedure
"Updating the Default Group Policy on the Domain and the Domain Controllers OU" in
"Appendix: Procedures" later in this guide.
Applying a New GPO to the Domain Controllers OU

As a best practice, you should create and link a new GPO above the default policy when you
want to apply changed policy settings to the entire domain or domain controllers, with the
exception of the policies listed earlier that must be changed directly in the default policy. The
advantage of this approach is that if a problem is encountered because of the changed
settings, the new GPO can very easily be backed out, restoring the original policy settings.
Apply the changed policy settings to the default Domain Controllers OU policy through a
new GPO by following the procedure "Linking a New Policy to the Domain Controller OULevel GPOs" in "Appendix: Procedures" later in this guide.
Recommendations: Establishing Secure Domain and Domain Controller
Policy Settings

You can create secure domain and domain controller policy settings by following the security
recommendations described earlier in this section. Of course, as previously mentioned, your
comprehensive Active Directory security plan should also take into consideration the
recommendations that are described in the other sections of this guide.
Recommendations for Establishing Secure Domain Policy Settings

The following table provides a checklist of recommendations for ensuring that your domain
and domain controller policy settings are applied in a secure and consistent manner.

Check Securing Password Policy Settings for Domains

Apply the password policy settings in Table 14 at the domain level.

Check Securing Account Lockout Policy Settings for Domains
Apply the account lockout policy settings in Table 15 at the domain level.
Check Securing Kerberos Policy Settings for Domains
Apply the Kerberos policy settings in Table 16 at the domain level.
Recommendations for Establishing Secure Domain Controller Policy Settings

The following table provides a checklist of recommendations for ensuring that your domain
controller policy settings are applied in a secure and consistent manner.

Check Establishing Domain Controller User Rights Assignment Policy Settings

Apply the domain controller User Rights Assignment policy settings in Table 17.
Check Establishing Domain Controller Audit Policy Settings
Enable auditing to provide accountability for sensitive operations.
When needed, enable additional auditing for other requirements, such as intrusion
detection.
Apply the domain controller Audit policy settings in Table 18.
Check Enabling Auditing on Active Directory Database Objects
Enable auditing on the Schema directory partition.
Enable auditing on the Configuration directory partition.
Enable auditing on the Domain directory partition.
Check Establishing Domain Controller Security Options Policy Settings
Apply the domain controller Security Options policy settings in Table 31.
Check Establishing Domain Controller Event Log Policy Settings
Apply the domain controller event log policy settings in Table 32.

Recommendations for Selecting Policy Settings for Mixed Operating System

Environments

The following table provides a checklist of recommendations for securing Active Directory in
mixed operating system environments.

Check Identifying When Earlier Versions of Operating Systems Are an Issue

Identify users that are authenticated with earlier versions of authentication protocols.
Identify computers that do not support SMB signing.
Identify anonymous access to domain controllers.
Check

Restricting Anonymous Access to Domain Controllers

and Domain Controller Resources
Change the Security Option policy Additional restrictions for anonymous
connections to Do not allow enumeration of SAM accounts and shares.
Configure the registry setting for RestrictNullSessAccess to Reg_Dword=1.

Check Disabling LAN Manager Authentication

Configure the registry setting for NoLMHash to Reg_Dword=1.
Check Enabling SMB Signing on Domain Controllers
Enable SMB client and server signing so that SMB signing is always required.
Check Disabling Pre-Windows 2000 Compatible Access
Disable Pre-Windows 2000 Compatibility.
Recommendations for Applying Selected Domain and Domain Controller Security
Settings

The following table provides a checklist of recommendations for ensuring that your domain
controller policy settings are applied in a secure and consistent manner.

Check Updating Group Policy settings

Create a new GPO for the recommended domain policies.

Create a new GPO for the recommended domain controller policies.
Link the domain security template to the domain GPO.
Link the domain controller security template to the Domain Controllers OU GPO.
Set each new security policy with the highest precedence.
Check Applying New GPOs to the Domain and Domain Controllers OU
Ensure that all domain controller computer accounts reside in the Domain Controllers
OU.
Top of page
Chapter 5: Establishing Secure Administrative Practices

Any user who has administrative access to domain controllers can cause breaches in security.
Individuals seeking to damage the system may be unauthorized users who have obtained
administrative passwords, or they may be legitimate administrators who are coerced or
disgruntled for one reason or another. Furthermore, not all problems are caused with
malicious intent. An inexperienced user who is granted administrative access may
inadvertently cause problems by failing to understand the ramifications of configuration
changes.
You can minimize these problems by carefully controlling the scope of influence that you
give your administrative accounts. For the day-to-day management of your environment,
avoid using all-powerful administrative accounts that have complete access to every domain
controller and full access to the directory. Instead, configure your administrative accounts so
that their scope of influence is limited to the specific containers in Active Directory that they
need to do their jobs. In the event that one of these accounts is misused, this will limit the
amount of damage that can be done.
For Windows 2000 Active Directory, there are two types of administrative responsibility:
service management and data management. Service administrators are responsible for
maintaining and delivering the directory service. This includes managing the domain
controllers and configuring the directory service. Data administrators are responsible for
maintaining the data that is stored in the directory service and on domain member servers.
Service administrators are responsible for the delivery of the directory service, directory-wide
settings, installation and maintenance of software, and application of operating system
service packs and fixes on domain controllers. To perform these functions, service
administrators must have physical access to domain controllers.
Data administrators are responsible for managing data that is stored in the directory and on
computers that are members of the forest. They have no control over the configuration and
delivery of the directory service itself. Data administrators control subsets of objects in the

directory. Using access control list (ACL) settings on objects that are stored in the directory, it
is possible to limit the control of a given administrator account to very specific areas of the
directory. Data administrators also manage computers (other than domain controllers) that are
members of their domain. Data administrators can perform all of their responsibilities from
management workstations, and they do not need physical access to the domain controllers.
Some information that is needed to manage or configure the Active Directory service is
controlled by objects that are stored in directory itself. Even though this information is stored
in the directory, it is used and managed by service administrators. Because of this, service
administrators can act as data administrators. As a result of their limited access, data
administrators cannot act as service administrators.
Establishing Secure Service Administrative Practices

Service administrators have the ability to configure domain controllers and control your
Active Directory environment. They are responsible for installing and maintaining all
software, including the operating system and patches, on all domain controllers. They control
server settings and networking options on domain controllers. They also manage the overall
configuration of the directory service, including replication behavior, schema management,
and domain creation and deletion. Service administrators have the most widespread power in
your environment.
Because of the elevated privileges of service administrators, steps must be taken to keep the
service administrator accounts secure. There are two aspects to securing your service
administrator accounts. You can control:

How the accounts are used, by securing the service administrator accounts
themselves.

Where the accounts can be used, by securing the service administrator workstations.

Securing Service Administrator Accounts

Like regular user access, administrative access to resources is controlled by the ACLs that are
set on the various resources being managed and by the privileges that are granted to the
administrative accounts. Active Directory has a number of default service administrator
accounts. By default, these accounts are granted access to directory and server resources
when Active Directory is installed. Table 36 lists the default service administrator accounts
and provides a brief description of each account.
Table 36 Default Service Administrator Accounts
Account Name
(Mnemonic)
Enterprise
Admins (EA)

Scope
Forest

Description
This group is automatically added to the Administrators group in
every domain in the forest, providing complete access to the
configuration of all domain controllers. This group can modify
the membership of all administrative groups. Its own membership

can be modified only by the default service administrator groups

in the root domain. This account is considered a service
administrator.

Schema Admins
Forest
(SA)

Administrators
(BA)

This group has full administrative access to the schema. The

membership of this group can be modified by any of the service
administrator groups in the root domain. This account is
considered a service administrator because its members can
modify the schema, which governs the structure and content of
the entire directory.

This built-in group controls access to all the domain controllers in

its domain, and it can change the membership of all
administrative groups. Its own membership can be modified by
the default service administrator groups BA and DA in the
Domain domain, as well as the EA group. This group has the special
privilege to take ownership of any object in the directory or any
resource on a domain controller. This account is considered a
service administrator because its members have full access to the
domain controllers in the domain.

This group controls access to all domain controllers in a domain,

and it can modify the membership of all administrative accounts
Domain Admins
in the domain. Its own membership can be modified by the
Domain
(DA)
service administrator groups BA and DA in its domain, as well as
the EA group. This is a service administrator account because its
members have full access to a domain's domain controllers.
By default, this built-in group has no members, and it has access
to server configuration options on domain controllers. Its
membership is controlled by the service administrator groups BA
and DA in the domain, as well as the EA group. It cannot change
Server Operators
Domain any administrative group memberships. This is a service
(SO)
administrator account because its members have physical access
to domain controllers and they can perform maintenance tasks
(such as backup and restore), and they have the ability to change
binaries that are installed on the domain controllers.
By default, this built-in group has no members, and it can create
and manage users and groups in the domain, including its own
membership and that of the SO group. This group is a service
Account
Domain administrator because it can modify the SO group, which in turn
Operators (AO)
can modify domain controller settings. As a best practice, you
should leave the membership of this group empty and not use it at
all for any delegated administration.
Backup
Domain By default, this built-in group has no members, and it can
Operators (BO)
perform backup and restore operations on domain controllers. Its

membership can be modified by the default service administrator

groups BA and DA in the domain, as well as the EA group. It
cannot modify the membership of any administrative groups.
While members of this group cannot change server settings or
modify the configuration of the directory, they do have the
permissions needed to replace files (including operating system
binaries) on the domain controllers. Because of this, they are
considered service administrators.

Administrator

DS
Restore
Mode

This special account is created during the Active Directory

installation process, and it is not the same as the Administrator
account in the Active Directory database. This account is only
used to start the domain controller in Active Directory Restore
mode. When it is in restore mode, this account has full access to
the directory database, as well as files (including operating
system binaries) on the domain controller. Because of this, this
account is considered a service administrator.

Limiting the Exposure of Service Administrator Accounts

Service administrator accounts are highly privileged, making them desirable as targets for
attack. Therefore, it is especially important to protect the integrity of these accounts. The
recommendations in this section of the guide are designed to enhance the security of your
service administrator accounts. Limiting the exposure of the service administrator accounts
gives attackers fewer targets of opportunity. Observe the practices in the following sections to
limit the exposure of service administrator accounts.
Limiting the Number of Service Administrator Accounts

Keep the membership of service administrator accounts to the absolute minimum that is
necessary to support your organization. Do not use service administrator accounts for day-today administrative tasks, such as account and member server management; instead, delegate
these tasks to data administrators. Tasks that are performed by service administrators should
be limited to changing the Active Directory service configuration and reconfiguring domain
controllers, and they should not include normal, day-to-day operations.
Separating Administrative and User Accounts for Administrative Users

For users who fill administrative roles, create two accounts: one regular user account that to
be used for normal, day-to-day tasks and one administrative account to be used only for
performing administrative tasks. The administrative account should not be mail enabled or
used for running applications that are used every day, such as Microsoft Office, or for
browsing the Internet. These precautions reduce the exposure of the accounts to the outside
world, and they reduce the amount of time that administrative accounts are logged on to the
system.
Hiding the Domain Administrator Account

Every installation of Active Directory has an account named Administrator in each domain.
This is the default administrative account, which is created during domain setup, that you use
to access and administer the directory service. This is a special account that the system
protects to help ensure that it is available when needed. This account cannot be disabled or
locked out.
The fact that this account is always created during domain setup, cannot be deleted, and
cannot be disabled means that every malicious user who attempts to break into your system
will assume that the account exists and that can it can be used as a target. For this reason, you
should rename it to something other than Administrator. When you rename the account, make
sure that you also change the text in the Description field for the account. In addition, you
should create a decoy user account, called Administrator, that has no special permissions or
user rights.
To hide the default Administrator account, perform the following tasks:
1. Rename the default Administrator account. For a procedure to perform this task, see
"Renaming the Default Administrator Account" in "Appendix: Procedures" later in
this guide.
2. Create a decoy Administrator account with no special permissions or privileges. For a
procedure to perform this task, see "Creating a Decoy Administrator Account" in
"Appendix: Procedures" later in this guide.
Managing Service Administrators in a Controlled Subtree

To help protect highly privileged service administrator accounts, allow only service
administrators to manage service administrator accounts. Because such accounts have
elevated privileges, data administrators should not be given the authority to modify these
accounts. Doing so allows data administrators to elevate their privileges. Service
administrator accounts should be accessed and managed in a highly controlled subtree in each
domain.
To provide a more controlled environment that facilitates the management of service
administrator accounts and workstations, create a controlled subtree to manage service
administrator accounts in Active Directory, as shown in Figure 12. The controlled subtree
structure should be created for each domain by a member of the Domain Admins group for
that domain, and it should be configured with the recommended security settings.
By creating your own subtree containing all service administrator accounts and the
administrative workstations that they use, you have the ability to apply controlled security
and policy settings to them to maximize their protection. Figure 12 shows an example of a
controlled administrative subtree and its access control settings.

Figure 12
Accounts

Sample Subtree for Managing Service Administrator

To create the controlled subtree, perform the following tasks:

1. Create the organizational unit (OU) structure for the controlled subtree.
2. Set the ACLs on the controlled subtree OUs.
3. Add service administrator groups to the controlled subtree.
4. Add service administrator user accounts to the controlled subtree.
5. Add service administrator workstation accounts to the controlled subtree.
6. Enable auditing on the controlled subtree.
7. Protect service administrator groups outside the controlled subtree.
The steps that follow describe each of the tasks in greater detail.
Step 1: Create the OU structure for the controlled subtree.

Create a high-level OU to hold the groups and user accounts that constitute your service
administrators and their workstations. Within that OU, create one OU to hold administrative
user and group accounts and another OU for administrative workstations.
Figure 12 depicts a recommended OU hierarchy for the controlled subtree to manage service
administrator accounts and workstations. It consists of a controlled subtree rooted at the
Service Admins OU that contains two additional OUs: the Users and Groups OU, to hold the
administrative user and group accounts, and the Administrative Workstations OU, to hold the
computer accounts of the workstations that are used by the service administrators.
Step 2: Set the ACLs on the controlled subtree OUs.

To limit access to the controlled subtree such that only service administrators would typically
be able to administer the membership of service administrator groups and workstations, do
the following:

Block inheritance of permissions on the Service Admins OU so that future changes

that are made higher up in the domain tree are not inherited down, altering the lockeddown settings.
Set the ACL on the Service Administrators OU, as indicated in Table 37.
Table 37 ACL Settings for the Service Administrators OU
Type

Name

Access

Applies To

Allow Enterprise Admins

Full Control

This object and all child

objects

Allow Domain Admins

Full Control

This object and all child

objects

Allow Administrators

Full Control

This object and all child

objects

List Contents
Pre-Windows 2000 Compatible
Allow
Access

Read All
Properties

User Objects

Read Permissions
Step 3: Add service administrator groups to the controlled subtree.

Move the following service administrator groups from their current location in the directory
into the Users and Groups OU in your controlled subtree:

Domain Admins
Enterprise Admins (if this is the root domain of the forest)

Schema Admins (if this is the root domain of the forest)

For complete protection of service administrator groups, it would be ideal to move the builtin groups from Table 36 (Administrators, Server Operators, Account Operators, and Backup
Operators) to the controlled subtree. However, built-in groups cannot be moved from their
default container. Step 7 explains how to protect those accounts.
Step 4: Add service administrator user accounts to the controlled subtree.

Move all administrative user accounts that are members of any of the service administrator
groups listed in Table 36 from their current locations in the directory into the Users and
Groups OU in your controlled subtree. This also includes the domain Administrator account.

As recommended, each service administrator should have two accounts: one for
administrative duties and one for their normal user access. Place the administrative user
accounts in the Users and Groups OU in your controlled subtree. If these accounts already
exist elsewhere in the directory, move them into the subtree now. The regular user account for
those administrators should not be placed in this controlled subtree.
Step 5: Add service administrator workstation accounts to the controlled subtree.

Designate administrator's computers as administrative workstations. Move the computer

accounts for those workstations into the Administrative Workstations OU in your controlled
subtree.
Important:
Do not move any domain controller accounts out of the default Domain Controllers OU, even
if some administrators log on to them to perform administrative tasks. Moving these accounts
will disrupt the consistent application of domain controller policies to all domains.
Step 6: Enable auditing on the controlled subtree.

It is important to audit and track any additions, deletions, and changes to the service
administrator accounts and workstations - and changes in policies that are applied to them so that improper or unauthorized changes can be detected.
Assuming that you have enabled auditing on your domain controllers in accordance with the
recommendations in Chapter 4, "Establishing Secure Domain and Domain Controller
Policies," set the system access control list (SACL) on the Service Administrators OU, as
specified in Table 38. Monitor the security audit log for changes to the controlled subtree so
that you can ascertain that the changes are legitimate.
Table 38 SACL Settings on OU=Service Admins , DC
=Domain,DC=...ForestRootDomain
Type

Name

Access
Write All Properties

Allow Everyone

Applies To
This object and all child objects

Delete
Delete Subtree
Modify Permissions
Modify Owner
All Validated Writes
All Extended Rights

Create All Child Objects

Delete All Child Objects
Step 7: Protect service administrator groups outside the controlled subtree.

Some of the built-in service administrator accounts are protected by special default security
descriptor settings that are applied during the installation of Active Directory. These settings
are described in the following section, "Protecting the Service Administrator Accounts."
However, the Server Operators, Backup Operators, and Account Operators groups are not
protected by these settings.
Also, because these are built-in accounts, they cannot be moved to the controlled subtree for
protection. To protect these three groups, apply the same default ACL that is used to protect
the other service administrator accounts, as listed in Table 39.
At this point, your controlled subtree for service administrators is set up and ready for use.
Protecting the Service Administrator Accounts

To prevent the security descriptors on the key service administrator accounts in each domain
from being modified and possibly becoming unusable, a background process runs on the
primary domain controller (PDC) emulator operations master that periodically checks and
applies a standard security descriptor on the protected accounts. This background process
overwrites the administrative policies that are stored as the protected settings in the
AdminSDHolder object to protect service administrator accounts. This process starts 15
minutes after the system boots and then runs once every half hour thereafter. This refresh
interval is not configurable.
This process ensures that if a hostile user or other administrator does manage to modify the
security descriptor on one of the administrative accounts, the modified security descriptor is
overwritten and replaced with the standard security descriptor within a half hour.
In Windows 2000 Active Directory, the following administrative groups and all their nested
member groups and users are protected with this process:

Administrators
Domain Admins

Enterprise Admins

Schema Admins

The master security descriptor for service administrator accounts is stored as the security
descriptor attribute of the AdminSDHolder object, which is located in the system container
(CN=AdminSDHolder,CN=System,DC=DomainName) of the domain directory partition.
The security descriptor on this object serves two purposes. First, it controls access to the
AdminSDHolder object itself. Second, it acts as the master security descriptor that is
periodically applied to the service administrator accounts listed above and their members to

ensure that they remain protected. The default settings in the master security descriptor of the
AdminSDHolder object are listed in Table 39.
Table 39 Default Permissions on the AdminSDHolder Object on
CN=AdminSDHolder,CN=System,DC= DomainName , DC =...ForestRootDomain
Type

Name

Allow Everyone

Permission
Change Password
List Contents

Apply To
This Object Only

Read All Properties

Write All Properties
Delete
Read Permissions
Allow Administrators

Modify Permissions

This Object Only

Modify Owner
All Validated Writes
All Extended Rights
Create All Child Objects
Delete All Child Objects
List Contents
Allow Authenticated Users

Read All Properties

This Object Only

Read Permissions
List Contents
Allow Domain Admins

This Object Only

Read All Properties
Write All Properties
Read Permissions
Modify Permissions
Modify Owner

All Validated Writes

All Extended Rights
Create All Child Objects
Delete All Child Objects
List Contents
Read All Properties
Write All Properties
Read Permissions
Modify Permissions
Allow Enterprise Admins

Modify Owner

This Object Only

All Validated Writes

All Extended Rights
Create All Child Objects
Delete All Child Objects
List Contents
Allow Pre-Windows 2000 Compatible Access

Read All Properties

Special

Read Permissions
Allow SYSTEM

Full Control

This Object Only

If you want to modify the security descriptor on one of the service administrator groups or on
any of its member accounts, you must modify the security descriptor on the
AdminSDHolder object so that it will be applied consistently. Be careful when making these
modifications, because you are also changing the default settings that will be applied to all of
your protected administrative accounts.
Configure the default security descriptor settings on the service administrator accounts by
changing the security descriptor on AdminSDHolder. For a procedure to perform this task,
see "Changing the Security Descriptor on AdminSDHolder" in "Appendix: Procedures" later
in this guide.
Hiding the Membership of the Service Administrator Groups

Because members of the service administrator groups are highly privileged, they constitute an
attractive target for attackers. Therefore, the membership information of these groups should
be guarded as much as possible. For maximum security, it is best to hide the membership
information for all service administrator groups from regular users. However, the default
security descriptor on AdminSDHolder that is used to protect service administrator groups
allows their membership information to be visible to regular users.
The entry in Table 39 that grants Read Access to Authenticated Users allows them to list the
membership information for all service administrator groups. Some applications and services
rely on this access control entry (ACE) to enumerate the members of an administrative group.
For example, applications such as SQL Server, which run under service accounts, may read
the list of administrative group members to make its own application-specific access control
decisions. Other third-party applications and line-of-business (LOB) applications may also
rely on this capability. Because there is no way to anticipate every service account that will
need this type of read access, the Authenticated Users entry exists to support all such cases.
It is possible to tighten security further by removing access for Authenticated Users from the
security descriptor on AdminSDHolder. Because this can cause some server-based
applications to stop functioning, care must be taken when doing this. Systematically remove
access for Authenticated Users by performing the following set of tasks:
1. If you have not already done so, disable Pre-Windows 2000 Compatible Access for
your domain. For more information, see "Disabling Pre-Windows 2000 Compatible
Access" earlier in this guide.
2. Create a group called "Server Applications," and grant it Read access to
AdminSDHolder by adding the ACE, as shown in Table 40.
3. Add the individual service accounts used by your applications that require the ability
to enumerate group membership of the service administrator groups to this group.
4. Remove the Authenticated User entry and the Pre-Windows 2000 Compatible Access
entry from the security descriptor.
Table 40 ACL Change on AdminSDHolder for the Server Applications Group
Type

Name

Allow Server Applications

Permission
List Contents
Read All Properties

Apply To

This Object Only

Read Permissions
At this point, your service administrator accounts should not be visible to regular users on
your network. Because it is impossible to predict the impact on every application, closely
monitor applications running in your environment, and make sure that they still function
properly. If you observe application problems, simply add Authenticated Users as a member
of the newly created Server Applications group to restore functionality while you diagnose
how to remove the application dependency.

Managing Group Memberships for Service Administrator Accounts

To enhance security, we recommend limiting the membership in each of the service

administrator groups to the absolute minimum that your organizational logistics allow, while
still enabling you to manage your Active Directory service functions. This reduces the
number of possible administrative accounts that can be compromised by hostile users. The
following sections explain some recommended practices for managing the membership of the
service administrator groups.
Assigning Trustworthy Personnel

Service administrators control the configuration and functioning of the directory service.
Therefore, this responsibility should be given only to reliable, trusted users who have
demonstrated responsible ownership and who fully understand the operation of the directory.
They should be completely familiar with your organization's policies regarding security and
operations, and they should have demonstrated their willingness to enforce those policies
Restricting Service Group Membership to Users in the Forest

Do not include users or groups from another forest as members of service administrator
groups, unless you completely trust the service administrators of the other forest. Because
service administrators in the other forest have full control on the user accounts in that forest,
they can easily impersonate or authenticate to your forest using the credentials of one of those
users. Further, by trusting the remote domain (or forest) in this way, you also trust their
security measures, which is something over which you have no control.
If it is necessary to have a user from another forest act as a service administrator in your
domain, create an account in your domain that he or she can use when performing the
administrative role. This eliminates your dependence on the security measures of the other
forest.
Limiting the Schema Admins Group to Temporary Members

The Schema Admins group is a special group in the forest root domain that provides
administrative access to the Active Directory schema. Members of this group have the
necessary user rights to make changes to the schema. In general, because schema changes are
only made rarely, it is not necessary for a schema administrator to be available at all times.
This account is needed only when a schema update must be processed or if a change must be
made to the configuration of the schema operations master role holder.
To minimize the possibility of an Active Directory attack through a schema administrator
account, keep the membership of the Schema Admins group empty. Add a trusted user to the
group only when an administrative task must to be performed on the schema. Remove the
member after the task is completed.
Limiting Administrator Rights to Those Rights That Are Actually Required

Active Directory contains a built-in group named Backup Operators. Members of this group
are considered service administrators, because the group's members have the privilege to log
on locally and restore files, including the system files, on domain controllers. Membership in

the Backup Operators group in Active Directory should be limited to those individuals who
back up and restore domain controllers.
All member servers also contain a built-in group called Backup Operators that is local to each
server. Individuals who are responsible for backing up applications (for example, SQL
Server) on a member server should be made members of the local Backup Operators group
on that server - as opposed to the Backup Operators group in Active Directory.
On a dedicated domain controller, you can reduce the number of members in the Backup
Operators group. When a domain controller is used for running other applications, as it might
be in a branch office, individuals who are responsible for backing up applications on the
domain controller must also be trusted as service administrators, because they will have the
privileges necessary to restore files, including system files, on domain controllers.
Avoid using the Account Operators group for strictly delegating a "data administration" task,
such as account management. Because the default directory permissions give this group the
ability to modify the membership of other service administrator groups, such as Server
Operators, a member of the Account Operators group can elevate his or her privileges to
become a service administrator. By default, there are no members of the Account Operators
group, and its membership should be left empty.
Controlling the Administrative Logon Process

The members of the Administrators, Enterprise Admins, and Domain Admins groups
represent the most powerful accounts in your forest and in each individual domain. To
minimize security risks, it is recommended that you take the steps in the following sections to
enforce strong administrative credentials.
Requiring Smart Cards for Administrative Logon

Require your service administrators to use smart cards for their interactive logons. Besides
forcing the administrative users to have physical possession of the cards to log on, smart
cards also ensure the use of cryptographically strong passwords on the user accounts that are
randomly generated. This helps protect against the theft of weak passwords to gain
administrative access. To implement this strategy, you must have a public key infrastructure
(PKI) available to authenticate the smart cards.
You can enforce the use of smart cards by enabling the Smart card is required for
interactive logon option for each administrative account. If you create a subtree, as described
in "Managing Service Administrators in a Controlled Subtree" earlier in this guide, set this
option for each user account in the Users and Groups OU.
Require the use of smart cards for administrative logon by setting the smart card option on
the administrative accounts. For procedures to perform these tasks, see "Appendix:
Procedures" later in this guide.
For more information about using smart card authentication, see "The Smart Card
Deployment Cookbook" on the Microsoft TechNet Web site at
http://go.microsoft.com/fwlink/?LinkId=18552.

Sharing Logons for Sensitive Administrative Accounts

For each account that is a member of the Enterprise Admins and Domain Admins groups in
the forest root domain, assign two users to share that account, so that both users must be
present for a successful logon with that account. This provides inherent visual auditing of the
use of the account, where one user observes the actions that are performed by the other. It
also means that a single user cannot log on privately to access the system as an administrator
and compromise its security, either as a rogue administrator or under circumstances involving
coercion.
Shared administrative accounts can be implemented through either split passwords or split
smart cards plus personal identification numbers (PINs). If you are using:

Password-based credentials for administrative accounts:

Split the password for the administrative account between the two users sharing that
account so that each user knows only one half of the password. Each user is
responsible for maintaining their half of the password. For example, you can create an
administrative account called Admin1 and assign two trusted users, Jane and Bob, to
share this account. Each of them maintains half of the password. For one of them to
log on and use the account, the other must be present to enter the other half of the
password.

Smart-card-based credentials for administrative accounts:

Split the ownership of the smart card and its PIN between the two users sharing that
account so that one user retains physical ownership of the smart card and the other
user maintains the PIN for the card. This way, both users must be present for the
account to be used. In the example above, Jane keeps the smart card, and Bob is the
only one who knows the PIN for that card.

Securing Service Administrator Workstations

In addition to limiting access to resources that are stored on the domain controllers and the
information that is stored in the directory, you can also enhance security by strictly
controlling the workstations that can be used by service administrators for administrative
functions and by controlling the security on those workstations.
Restricting Service Administrators Logon to Administrative Workstations

Each administrative account can be restricted so that it is only allowed to log on to specific
workstations. If one of your administrative accounts is compromised, this will limit the
number of locations where that account can be used to log on.
The "Managing Service Administrators in a Controlled Subtree" section earlier in this guide
describes the process of creating a controlled subtree of OUs to facilitate tighter control on
the management of service administrator accounts. Moving the administrative workstations
into this subtree makes it easy to apply Group Policy settings that control who can log on at
which location.

To limit the locations where the service administrator accounts can log on, perform the
following set of tasks:
1. Modify the User Rights Assignment policy in the default domain policy to Deny
logon locally to the following groups: Administrators, Schema Admins, Enterprise
Admins, Domain Admins, Server Operators, Backup Operators, and Account
Operators.
For a procedure to perform this task, see "Denying Logon Access to the Domain" in
"Appendix: Procedures" later in this guide.
2. Create and apply Group Policy settings to the Administrative Workstations OU in the
controlled subtree that sets the User Rights Assignment policy to allow Log on
locally to Everyone.
3. Enable the Deny logon locally setting in the User Rights Assignment policy for the
Administrative Workstations OU.
4. If the Deny logon locally setting in the User Rights Assignment policy for the
Administrative Workstations OU is already enabled, remove any users.
For a procedure to perform this task, see "Allowing Logon Access to Administrator
Workstations" in "Appendix: Procedures" later in this guide.
Figure 13 provides a summary of policies to apply to restrict administrative logon.

Figure 13
Logon

Summary of Policies Applied to Restrict Administrative

Note:
The default domain controller policy, which is applied to the Domain Controllers OU, allows
administrators to log on to the domain controllers. Denying logon access across the entire
domain applies to all workstations and member servers.

Prohibiting the Use of Cached Credentials When Unlocking an Administrative

Console

When the console on an administrative workstation is locked, either by the action of a user or
automatically by a screensaver time-out, the console must be unlocked to regain access to the
workstation. The workstation maintains cached credentials for any users that have been
authenticated locally. When the console is unlocked, by default the workstation uses these
cached credentials, if they exist, for the user who attempts to unlock the console.
When cached credentials are used to unlock the console, any changes to the account, such as
user rights assignment, group membership changes, or disabling of the account, are not
enforced. For example, if an administrator who is logged on to a workstation console is
terminated, he or she could still unlock the console, even if his or her account were disabled.
To ensure that any changes to the account are enforced immediately, require domain
controller authentication of the account to unlock the console, instead of cached credentials.
Configure the administrative workstation to require domain controller authentication to
unlock the workstation console by adding or modifying the following entry under the registry
key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
Entry name: ForceUnlockLogon
Data type: REG_DWORD
Value: 1
Caution:
Do not edit the registry unless you have no alternative. The registry editor bypasses standard
safeguards, allowing settings that can damage your system, or even require you to reinstall
Windows. If you must edit the registry, back it up first and see the Registry Reference in the
Microsoft Windows 2000 Server Resource Kit at .
Avoiding Running Applications in Administrative Contexts

When a computer becomes a member of a domain, the Domain Admins group is

automatically added to the local Administrators group on that computer. This gives members
of the Domain Admins group full access to the member computer. On the downside, however,
if the computer contracts a virus while a domain administrator is logged on, the virus runs in
the context of that domain administrator, which is also a local administrator. This enables the
virus to use the administrator's privileges to infect the workstation.
Avoid running applications in the context of a service administrator account by removing the
Domain Admins group from the local Administrators group on workstations in the
Administrative Workstations OU in your controlled subtree. If a service administrator
contracts a virus while logged on, the virus will not have administrative access to the
computer.
Avoid running application or service agents on administrative workstations in the context of
an service administrator account. For example, a monitoring agent running in the context of a
Domain Admins member might make it possible for compromised agent software to be used
to compromise the security of the domain and the domain controllers. The local administrator
account on the workstation has the necessary privileges to take control of the agent and act as

the service administrator. If a user manages to gain access to the system as a local
administrator, that user can then assume control of the agent and any information it is
collecting.
Running Antivirus Software

Running antivirus software regularly on administrative workstations helps to protect the

workstations from contracting a virus that can exploit the privileges of a logged-on service
administrator to spread itself through the computer and into the domain.
Securing Traffic Between Administrative Workstations and Domain Controllers

It is possible for attackers to gain access to sensitive information by intercepting network

traffic between administrative workstations and domain controllers. Managing domain
controllers from administrative workstations results in two types of vulnerabilities to the data:
information disclosure and data tampering.
Table 41 lists the features in Windows 2000 that can be used to secure traffic between
administrative workstations and domain controllers, along with the threats that are mitigated
by each feature.
Table 41 Features in Windows 2000 Used to Secure Administrative Traffic

Feature

Information Disclosure
Threat

LDAP packet signing

Terminal Services for remote
administration

Data Tampering
Threat
Mitigated

Obfuscated*

Obfuscated

Requiring LDAP Packet Signing on Administrator Workstations

Lightweight Directory Access Protocol (LDAP) packet signing can help prevent packet
tampering between administrative workstations and domain controllers.
LDAP packet signing does not encrypt the data in the packet, and the data can still be read by
someone who captures the packet. LDAP packet signing does, however, use a digital
signature to help prevent the attacker from altering the packet and putting it back on the
network. Digital signatures in the packet guarantee the integrity of the data. LDAP packet
signing applies only to LDAP traffic to Active Directory.
To use LDAP packet signing, both the administrative workstations as well as the domain
controllers must be running at least Windows 2000 with Service Pack 3 (SP3), and they must
require LDAP packet signing. Update the following registry entries to enforce LDAP signing.
Configure each administrative workstation registry setting to enable LDAP packet signing by
modifying the registry key HKLM\System\CurrentControlSet\Services\LDAP:

Entry name: LDAPClientIntegrity

Data type: REG_DWORD
Value: 2
Caution:
Do not edit the registry unless you have no alternative. The registry editor bypasses standard
safeguards, allowing settings that can damage your system, or even require you to reinstall
Windows. If you must edit the registry, back it up first and see the Registry Reference in the
Microsoft Windows 2000 Server Resource Kit at .
Using Terminal Service for Remote Administration

Terminal Services is the graphical remote administration component in the Windows 2000
Server family. Terminal Services is built into each version of Windows 2000 Server, and it is
the recommended method for all graphical remote administration tasks that are performed on
computers running Windows 2000 Server
Terminal Services in Remote Administration mode enables system administrators with the
appropriate permissions to remotely administer any domain controller over a TCP/IP
connection. In this scenario, a system administrator can use any of the built-in Windows 2000
management tools, such as Microsoft Management Console (MMC)-based Active Directory
Users and Computers, to remotely administer any domain controller in the forest. Remote
management can be provided to both native and mixed mode domains.
Remote access to your domain controllers permits most administrative personnel to work
from a centralized datacenter and still perform normal administrative tasks on a domain
controller in a branch office site. This feature can reduce costs by minimizing the number of
service administrators needed to support branch offices.
Limiting administrative access to domain controllers to a few secure workstations can also
enhance Active Directory security by minimizing the number of locations where Active
Directory can be administered and minimizing the number of individuals that require
administrative rights and privileges.
Recommendations for securing terminal sessions between a remote client and a domain
controller include the following:

Install the latest service pack on domain controllers.

Service Pack 2 (SP2) for Windows 2000 Server enhances security by hiding domain
controller configuration information from a potential attacker. Service Pack 3 (SP3)
provides encryption for Terminal Service client-server communications. For more
information, see article 324380, "MS02-051: Cryptographic Flaw in RDP Protocol
Can Cause Information Disclosure" in the Microsoft Knowledge Base at
http://go.microsoft.com/fwlink/?LinkId=4441.

Install the latest version of Remote Desktop Connection on administrative

workstations.

If you are using the Windows 2000 32-bit Terminal Services client, you should
upgrade to the Windows Server 2003 Remote Desktop Connection. This upgrade is
compatible with Windows 2000 Professional.

Coordinate remote administrative tasks with other administrators.

If you are remotely administering domain controllers with Terminal Services, ensure
that only one administrator is managing a specific domain controller at the same time.
This ensures that administrators do not run potentially destructive tasks at the same
time. For example, two administrators might try to reconfigure the disk subsystem and
undermine each other's work, or even worse, destroy data. Use the Terminal Services
Manager tool or the query user command-line utility to check for the presence of
other administrators.

Configure the remote desktop session to disconnect when the connection is broken.
This is the default setting, and it is especially important if you perform system updates
over unreliable network connections. If a session is interrupted as a result of a
network problem, the session goes into a disconnected state and continues executing
the processes that were running before the interruption occurred. If the session is
configured to reset when the connection breaks, all processes that are running in that
session stop.

Avoid tasks that require reboots.

Some tasks (for example, system upgrades and domain controller promotion) require
reboots at their completion. These tasks work correctly from within a remote desktop
session, but something as simple as a floppy disk in the drive or a bad boot sector on
the disk can prevent the server from restarting. Therefore, you should not remotely
reboot mission-critical servers unless you have the ability to physically intervene at
the server if a problem occurs.

Avoiding the Delegation of Security-Sensitive Operations

There are some forest-level and domain-level operations that should not be delegated away
from the trusted service administrator accounts that they are assigned to by default.
Delegation of these operations could lead to an elevation-of-privilege or denial-of-service
attack, launched by the user that is delegated the task, that could impair the functionality of
the entire forest or domain. Control of such operations should be retained solely within the
service administrator groups. The following sections list security-sensitive operations that
should not be delegated.
Restricting the Delegation of Sensitive Forest-Level Operations

The operations in Table 42 should only be performed by a member of the forest-level service
administrator groups (Enterprise Admins or Schema Admins), and they should not be
delegated to anyone else. Delegating these operations can lead to an elevation-of-privilege
attack by a malicious user.
Table 42 Forest-Level Operations That Typically Should Not Be Delegated

Operation

Reason Why the Operation Should Not Be Delegated

Installing the
Enterprise
Certification
Authority (CA)

This is a very crucial security operation. Any user with the authority to
set up the CA has the authority needed to issue certificates to individuals
that can result in elevated privileges. The authority to perform this action
must remain with the most trusted service administrator account in your
organization.

Modifying Forest
LDAP Policy
Settings

Some LDAP policies control the performance of domain controllers.

These policies are applied across the forest. Therefore, they can affect
every domain controller. If improper settings are distributed, they can
result in denial of service.

Modifying the
Schema

Modifications to the schema have forest-wide impact. Improper

modifications can result in the failure of existing applications or possible
directory corruption. The ability to modify schema also makes it possible
to modify the default security descriptors of classes that are used to
protect new objects that are created in the directory. By making changes
to default security descriptors, a person can gain the ability to create
security principals with elevated privileges.

Managing ForestLevel Operations

Master Roles

A person with this ability has the authority to seize operations master
roles. If done improperly, this operation can result in a directory that is
unusable. Improperly seizing the domain naming operations master can
result in a situation in which domains with duplicate names may be
created in the forest. After they are discovered, the process of repairing
them may result in trusts with other domains in the forest being rendered
invalid, and portions of the forest may need to be rebuilt. If the schema
operations master role is improperly seized, it can result in the existence
of multiple schemas, which in turn can lead to islands of domain
controllers that are associated with each copy of the schema.

Managing Site
Topology

A person who has been delegated control over management of the site
topology can launch a denial-of-service attack against every domain in
the forest. This can be accomplished by breaking all inbound replication
connections (that is, no inbound replication).

This can result in elevation of privilege. A user with this ability can
create a private domain that he or she can specify as trusted and then
Managing crossRef modify the SID history of an account in the private domain to introduce
objects
security identifiers (SIDs) that represent the account as a domain
administrator in the main domain, which gives that person elevated
privileges.

Restricting the Delegation of Sensitive Domain-Level Operations

To enhance security, we recommend that the operations in Table 43 only be performed by

members of the domain-level service administrator groups (Domain Admins, Server
Operators, or Backup Operators). They should not be delegated to anyone else.
Table 43 Domain-Level Operations That Should Not Be Delegated
Operation

Reason Why the Operation Should Not Be Delegated

The account that is delegated this authority has the ability to add and
remove domains in the forest. It has the ability to add and remove domain
controllers from the domain. This means it has control over adding and
Installation and
removing nodes of the distributed directory service and the associated
Removal of Active
security infrastructure. To do this, the account is given access to password
Directory
and account information in those domains that can be used for offline
password-cracking attacks. It also has the ability to delete entire domains,
which is an extreme example of a denial-of-service attack.

Software
Installation on
Domain
Controllers

To do this, the user must have local administrator access to the domain
controller. With this type of access, the user can gain direct access to the
directory database file, with the ability to copy it for an offline attack. The
user also has the necessary permissions to install software updates and add
services to the operating system. These may include rogue agents that
filter passwords or debuggers to monitor the Local Security Authority
(LSA) process for sensitive information.

Managing
Outbound Trusts

Users who have the authority to create outbound trusts to external

domains or to manipulate trusts with non-Windows Kerberos realms have
the authority needed to establish trust with a dummy target forest of their
creation in which they are administrators, such as domain administrator or
enterprise administrator, of the root domain. In the dummy target forest,
they can manipulate their group membership in the directory to introduce
group SIDs that represent a privileged entity in the source forest. Creating
an external trust (unless proper SID filtering has been enabled) can result
in elevation of privileges in the source forest.

Managing
Replication

Anyone with these rights has the ability to direct replication to an outside
source, where data from the directory can be collected and then taken
offline for a password-cracking attack. In a given domain, if the people
who are delegated this right have full control over any computer object in
the domain, they can inject arbitrary changes into the domain by creating a
fake replication source. They also have the ability to launch denial-ofservice attacks by removing replication links and preventing replication
from taking place.

Managing
Domain-Level

The domain controller with the relative ID (RID) operations master role
controls the domain RID pool as well as the allocation of RIDs to the

Operations Master domain controllers. Improper seizure of this role can result in duplicate
Roles
RIDs being allocated. As a result, new objects will be given invalid SIDs.
A user with this ability can control all access to the domain controller.
Modifying Domain
Policy configuration is generally fairly static, and once it is initially set,
Controller Security
this is an infrequent operation. There is no real need to delegate this
Policies
operation.
Domain security policies affect all domain users, member servers, and
workstations that are members of the domain. The person with this ability
Modifying Domain can apply security policies to the entire domain. This can be used to
Security Policies spread a weak password policy, which in turn can lead to broken
passwords. This is an infrequent operation, and there is no real need to
delegate it.
Users with these rights have the ability to overwrite files on the system
Backup and
and use tools that copy files off the system. This can lead to the
Restore Operations installation of rogue agents or the removal of files for offline password
cracking.
Establishing Secure Data Administrative Practices

Data administrators manage data that is stored in the directory but that is not related to
directory service configuration or the operation of Active Directory itself. Data administrators
manage local resources, such as print and file shares on local servers, and they also manage
the group and user accounts for their own part of the organization.
Delegation of data administration is accomplished by creating groups, granting the
appropriate user rights to those groups, and applying Group Policy settings to the members of
those groups. After these steps are complete, delegation is a matter of adding user accounts to
the groups that are created. The critical part of this operation is granting proper access and
applying the proper policies to maximize security, while still allowing your administrators to
perform their delegated functions.
Delegating Data Management

Because the creation of data administrator accounts and of the specific functions that are
delegated to them is driven by the needs of individual organizations, it is difficult to list
specific recommendations for creating and managing individual accounts. However, this
section provides a list of considerations to keep in mind while delegating control to your data
administrator accounts.
Restricting Access Group Policy to Trusted Individuals

Group Policy should only be created and applied by completely trusted individuals. These
individuals should be familiar with your organization's security policies, and they should
have demonstrated their willingness to enforce those policies.

Users with accounts that have the ability to create or modify Group Policy settings can
elevate the privileges of another user account through those policies. For example, if these
users modify a GPO that has been applied to a group of administrative accounts, they may be
able to configure a logon script that runs the next time one of the administrators logs on.
The logon script may contain a script that adds their user account to the Administrators group.
Because the script is launched during the administrator's logon process, it runs in the security
context of the administrator. In this case, it acts as if the administrator is adding a user to the
group. After this process is complete, the user has administrative access.
Taking Ownership of a Data Object

If your data administrators will be given the ability to create objects, make sure that you
understand the scope of that ability. When a user creates an object, he or she also becomes the
owner of that object by virtue of being its creator, and this person is called the Creator
Owner. In the discretionary access control model that is used by Windows 2000, the owner of
an object has Full Control of that object, including the ability to change the ACL of that
object.
By implication, the owner of an object also has Full Control on any child objects that may be
added under that object. The owner has the ability to block ACL inheritance from parent
objects and to block service administrators' access to that object.
If a situation arises in which access to an object has been blocked so that even the service
administrators cannot access it, a member of the Administrators group must take ownership
of the object to regain control. Members of the Administrators group always have the right to
take ownership of an object, and as the owner they can modify the security descriptor of the
object.
Reserving Ownership of Partition Root Objects for Service Administrators

Ensure that the Administrators or Domain Admins groups in each domain own the domain
root object for that domain partition. Because the owners of these partition root objects have
the ability to change the security settings of all other objects in that partition through
inheritable ACEs, it is vitally important to ensure that the partition root object is owned by a
highly trusted administrative group. By default, Active Directory partitions are set up so that
the partition root objects are owned by the corresponding administrative groups. This means
that the members of the Schema Admins group have ownership of the Schema directory
partition and members of the Enterprise Admins group have ownership of the Configuration
directory partition.
Preventing Concurrent Group Membership Changes

When planning your account management operations, institute operational practices ensuring
that changes to group memberships within a delegated scope - for example, within an OU are performed by a single data administrator within that OU or that they are tightly
coordinated between a few data administrators for that OU. This means that you should try to
limit the group administration to a single account - or as few accounts as possible - in each
administrative entity (domain or OU).

Managing group membership changes this way is necessary because of the way that
Windows 2000 replicates and handles conflicts in group membership information among
domain controllers. When the membership of a group changes, the entire list of members
(which is stored as a single attribute in the group object) replicates as a whole. If a conflict is
detected between two concurrent changes to the group membership originating at two
separate domain controllers, one change wins and the other loses, causing one change to be
made to the entire group membership.
Losing group membership changes can be a problem if you have more than one administrator
who is capable of making changes to the group membership. For example, consider a group
of administrators (Admin1, Admin2, and Admin3) who can modify group membership:
1. Admin1 is terminated from the organization.
2. Admin2, in an effort to protect company resources, immediately removes Admin1
from the Administrators group.
3. At the same time, Admin3 modifies the membership of the Administrators group to
add a new member.
4. Admin2 finishes removing Admin1 and closes the group.
5. The new membership list of the Administrators group then replicates to all domain
controllers in the domain.
6. Admin3 finishes adding a new member and closes the Administrators group.
Replication will then start replicating the membership list to all domain controllers. The
problem is that the membership list that contains the newly added member still lists Admin1
as a member. This membership list overwrites the changes made by Admin2, because the
replication of this version of the membership list starts later than the update to remove
Admin1. The result is that Admin1 is still a member of the Administrators group, with access
to company resources.
Establishing Other Secure Practices for Delegating Administration

When manipulating ACLs on objects in the directory, you should be mindful of certain
considerations so that you can avoid problems with unpredictable or confusing access control
behavior.
Avoiding Use of the DNPROTECT Tool

Building Enterprise Active Directory Services - Notes from the Field (Microsoft Press)
suggests a utility (DNProtect.exe) to secure objects in the directory. When this tool sets a bit
on a directory object, the object can only be changed on a domain controller that is a member
of the same domain as the object's owner.
Normally, when a user attempts to access an object, the user's access token is evaluated
against the ACL on the object to determine if the requested access is allowed. If the bit has
been set by DNProtect.exe, the operating system verifies that the user requesting access is a

member of the same domain as the object's owner before evaluating the ACL on the object. If
the user making the change is not a member of the same domain, access is denied.
While this tool may provide some security for directory partitions that are widely replicated
in the forest across multiple domains, it also introduces an element of confusion into the
security model in your environment. It is possible to end up in a situation in which a user is
listed on an object's ACL as having access but access is denied when the user attempts to
access the object. Use of the DNPROTECT tool is not supported in Windows 2000.
Avoiding the Use of Domain Local Groups for Controlling Read Access to Global
Catalog Data

Do not use domain local groups to control Read permissions on object attributes that are
replicated to the global catalog. Using domain local groups to control Read access to object
attributes that replicate to the global catalog can result in unpredictable access control
behavior for searches. Results can vary, depending on which global catalog services the
search requests, as illustrated by the following example.
Suppose that a local group, called LocGrp1 and defined in domain Dom1, is granted Read
access to an object that replicates to the global catalog. A user that is a member of LocGrp1
initiates a search for that object. When a user initiates a search for an object in the global
catalog, DC Locator requests and obtains the address of a global catalog from DNS. The
address of the global catalog that is returned can be one of many global catalog s in the forest,
not necessarily a global catalog in domain Dom1. If the user binds to a global catalog in
domain Dom1, Read access is granted to the user, because the user's authorization data (that
is, list of groups of which the user is a member) that is evaluated on that global catalog
includes the local group LocGrp1.
However, if the user binds to a global catalog in a different domain (Dom2), the user's
authorization data that is evaluated on that global catalog does not include the group
LocGrp1. Therefore, the user would not be granted access to the object. Because the user has
no control over which global catalog is selected, the results of the search are unpredictable.
Recommendations: Establishing Secure Administrative Practices

The following checklists summarize the recommendations made in this chapter.

Recommendations for Establishing Secure Service Administrative Practices

The following table provides a checklist of recommendations for enhancing the security of
your service administrator user and group accounts.

Check Limiting the Exposure of Service Administrator Accounts

Limit the number of service administrator accounts.

Use separate administrator and user accounts for administrative users.

Hide the domain Administrator account.
Check Managing Service Administrators in a Controlled Subtree
Create a controlled subtree to manage service administrator accounts and
administrative workstations.
Check Protecting the Service Administrator Accounts
Hide the membership of the service administrator groups.
Check Managing Group Memberships for Service Administrator Accounts
Assign trustworthy personnel.
Do not include accounts from outside the forest as members of service administrator
groups.
Assign members in the Schema Admins group temporarily.
Do not use the Backup Operators group for anything other than domain controller
backup functions.
Do not use the Account Operators group to delegate account management.
Check Controlling the Administrative Logon Process
Require smart cards for administrative logon.
Use shared logons for sensitive administrative accounts.
Check Securing Service Administrators Workstations
Restrict service administrator's logon to administrative workstations.
Prohibit cached credentials from unlocking administrative workstations.
Avoid running applications in administrative contexts.
Use antivirus software on administrative workstations.
Secure LDAP traffic between administrative workstations and domain controllers.
Check Avoiding the Delegation of Security-Sensitive Operations

Do not delegate the forest-level operations described in Table 42.

Do not delegate the domain-level operations described in Table 43.
Recommendations for Establishing Secure Data Administrative Practices

The following table provides a checklist of recommendations for enhancing the security of
your data administrative practices.

Check Delegating Data Management

Only allow trusted individuals to access Group Policy.
Understand the ramifications of Creator Owner.
Ensure that service administrators own partition root objects.
Prevent concurrent group membership changes.
Check Establishing Other Secure Practices for Delegating Administration
Avoid the use of the DNPROTECT tool.
Avoid the use of domain local groups for controlling Read access to global catalog
data.
Top of page
Chapter 6: Securing DNS

Active Directory uses Domain Name System (DNS) to locate servers that host various
directory partitions. This facilitates replication and client access to the information that is
stored in the directory partitions. Because DNS is an integral part of the architecture that is
used to access Active Directory, it is important to implement DNS as securely as possible to
help prevent unauthorized users from exploiting it as a means of gaining access to the
directory. Whether their intent is malicious or innocent, any users who gain access to the
DNS infrastructure with anything other than the Read permission can make changes that may
result in the failure of the directory or in unauthorized access to information in the directory.
The process of protecting DNS begins during deployment. Awareness of the ways that DNS
can be exploited can help drive decisions that are made during deployment. After
deployment, the next step is properly delegating administrative responsibilities to implement
those deployment decisions.
Note:
This discussion assumes the use of Active Directory-integrated DNS zones. Microsoft

recommends this practice, because integrating DNS zones into Active Directory simplifies
the process of securing the DNS infrastructure.
When Active Directory-integrated zones are used, zone-specific data is stored in containers
inside the directory, while configuration data is stored in the registry. Information that is
related to DNS servers, such as server configuration settings like restricting NS record
registration, is stored in the registry. Data that pertains to a single DNS zone that is hosted on
the server is stored in the MicrosoftDNS container in the directory.
Deploying Secure DNS

In a distributed environment, such as Active Directory, multiple servers work together to

make the directory available to all users on the network. Advantages of the distributed model
include elimination of single points of failure, shared resources for more efficient operation,
and an administrative model that can be customized to match existing organizations.
When a distributed model is used, an infrastructure must be provided so that the servers and
clients can locate one another in the environment. In the case of Active Directory, this
infrastructure is DNS. Because DNS is used to locate resources within the directory
environment, it becomes a point of interest for unauthorized users attempting to access the
system.
Unauthorized users can attempt to use DNS to gain access to the directory environment in a
variety of ways. One type of attack involves adding invalid entries to DNS zones so that the
DNS servers respond to client requests with misleading data. Another type of attack involves
responding to DNS client requests, which are intended for a valid DNS server with invalid
information, under the guise of the legitimate DNS server. These types of attacks can have the
results described in Table 44.
Table 44 Results of Attacks Made Through DNS
Result
Clients are directed
to unauthorized
domain controllers.

Description
When a client sends a DNS query looking for the address of a domain
controller, a compromised DNS server can be instructed to return the
address of an unauthorized domain controller. Then, with the use of
other non-DNS-related attacks, the client can pass on secure information
to the unauthorized domain controller.

When a DNS query receives a response with invalid addresses, the

DNS queries receive result is that clients and servers are unable to locate one another. If
responses with
clients cannot locate servers, they cannot access the directory. If domain
invalid addresses.
controllers cannot locate other domain controllers, the directory stops
functioning.
You can increase protection for your DNS infrastructure at two levels. First, take steps to
protect the DNS server and the integrity of its responses to client requests. Second, improve
security for data that is stored on the server so that, if the server is compromised, this you can
prevent unauthorized changes to the zone data.

Protecting DNS Servers

When a DNS server is attacked, the goal of the attacker is to assume control of the
information that is returned in response to DNS client queries. This way, clients can be
misdirected to unauthorized locations without their knowledge. After the clients start
communicating with these unauthorized locations, attempts can be made to gain access to
information that is stored on the client computers. Spoofing and cache pollution are examples
of this type of attack.
Not all attacks are about gaining access to information. Denial-of-service attacks use DNS
information to provide invalid addresses in response to client queries so that computers
cannot locate one another. The recommendations in the following sections can help you
protect your DNS servers from these attacks.
Implementing Internet Protocol Security Between DNS Clients and Servers

Internet Protocol security (IPSec) encrypts all traffic over a network connection. Encryption
minimizes the risk that data that is sent between the DNS clients and the DNS servers can be
scanned for sensitive information or tampered with by anyone attempting to collect
information by monitoring traffic on the network. When IPSec is enabled, both ends of a
connection are validated before communication begins. This way, a client can be certain that
the DNS server with which it is communicating is a valid server. Also, all communication
over the connection is encrypted; therefore, the client can assume that it has not been
tampered with. This prevents spoofing attacks, which are false responses to DNS client
queries by unauthorized sources that act like a DNS server.
IPSec is not enabled by default. Many organizations choose not to enable IPSec across their
entire network, because it may have an impact on the performance of the network.
For more information about IPSec, see the "Internet Protocol Security (IPSec)" link on the
Web Resources page at http://go.microsoft.com/fwlink/?LinkId=17304.
Protecting the DNS Cache on Domain Controllers

It is possible to add unauthorized entries directly into the cache on a DNS server so that
clients can be misdirected to unauthorized locations. This is referred to as cache pollution. In
Windows 2000, you can use the properties dialog box for a DNS server to enable the Secure
cache against pollution option. This protects the cache from outside interference. By default,
this option is not enabled.
Monitoring Network Activity

Denial-of-service attacks through DNS come in two forms. First, an attacker can cause the
server to respond with invalid addresses so that clients and servers cannot locate resources
that they need to function. (For more information, see "Protecting DNS Data" later in this
guide). Second, an attacker can flood a DNS server with so many client requests that it cannot
keep up with legitimate requests. Watch for unusually high amounts of traffic, and look for
anomalies, such as high volume from a single location or high volume for a single type of
traffic.

Closing All Unused Firewall Ports

Firewalls are a common way to protect servers from outside attack. Firewalls limit the
available ports that can be used to communicate between points on your network. DNS
servers use User Datagram Protocol (UDP) port 53 to communicate with one another. Open
port 53 on firewalls when a firewall is located between the following:

DNS servers that perform zone transfers

DNS servers that delegate zones and the servers that are authoritative for the zones

DNS clients and their DNS servers

DNS forwarders and servers that are higher in the DNS namespace hierarchy

Protecting DNS Data

If an attacker can gain access to the DNS server itself, the attacker may attempt to alter data
that is stored in the DNS zone files. The recommendations in the following sections can help
keep your zone data secure from a direct attack.
Using Secure Dynamic Update

One type of DNS attack involves entering invalid data into the zone files. This is done for
two reasons. First, the attacker can add records that contain invalid IP addresses that result in
misdirection of clients for denial of service or in misdirection to unauthorized servers.
Second, dummy records can be registered in an attempted denial-of-service attack. Possible
goals of this type of attack are to:

Exhaust the server's disk space by generating a huge zone file, filled with dummy
records.

Create a huge number of entries (more than 50,000) in the zone container in the
directory to cause slow replication.

In a DNS environment that uses dynamic update, the DNS server processes any DNS
registration request if the request applies to the zone for which the DNS server is
authoritative. To prevent a rogue user from registering bad records, use secure dynamic
update. Using secure dynamic update guarantees that registration requests are processed only
if they are sent from valid clients in the forest. This makes it more difficult for a rogue user to
launch this type of attack. The rogue user has to first gain access to a workstation that is a
member of the forest.
Ensuring That Third-Party DNS Servers Support Secure Dynamic Update

If your environment uses a third-party DNS solution, and you want to continue to use it with
Active Directory, make sure that you are using a version that is current enough that it
supports secure dynamic update. If your DNS provider does not support this option, update to
a current DNS version that does support secure dynamic update, if possible. As an alternative,
you can disable any dynamic update functionality and manually add the necessary service

(SRV) records to support Active Directory. Continuing to use dynamic update without using
secure dynamic update leaves the integrity of your DNS data at risk.
Ensuring That Only Trusted Individuals Are Granted DNS Administrator Privileges

Members of the DNS Admins group have control over the configuration of the DNS
environment. This means that they can disrupt the functionality of the directory service by
using denial-of-service attacks or by misdirecting clients to rogue servers. This puts them in
the same category as the service administrator accounts mentioned in "Establishing Secure
Administrative Practices" earlier in this guide. Use the same care in determining who is
granted membership in the DNS Admins group. Choose only individuals who are aware of
your operational policies and who have demonstrated their willingness to enforce those
policies. Also, grant access only to the portion of the DNS infrastructure for which each
individual is responsible.
Setting ACLs on the DNS Data

Access control lists (ACLs) can be set on the zone containers to limit access by users who
attempt to modify the zone containers with management tools, such as the DNS or ADSI Edit
snap-ins. By default, Administrators, Domain Admins, Enterprise Admins, and DNS Admins
have Full Control access to all components of DNS. Everyone else has Read access.
Using Forwarders Instead of Secondary Zones

If you plan on deploying secondary zones in your DNS infrastructure, consider using
forwarders instead. Secondary zone data is not stored in the directory; it is stored in a textbased zone file, which makes the data more vulnerable to attack. It is possible to protect that
data using NTFS permissions; however, eliminating the existence of the zone file altogether
removes the need to protect the data. Using forwarders is another way to distribute the load
on the DNS servers; however, forwarders do not require zones files to be stored on every
server. They simply forward DNS requests to servers that have the zone data. Using
forwarders reduces the surface area of your DNS deployment to potential threats.
The downside of using forwarders is an increase in traffic on your network and a reduction in
the fault tolerance of your DNS infrastructure. Forwarders do not maintain their own copy of
the database. When they receive a client query, forwarders first check their own DNS cache
to see if the query has been processed before and if the result is in memory. If the result is not
in memory, a query is sent to the forwarders' primary DNS server to be processed. Because
forwarders must always forward new queries, rather than processing them in a local database,
forwarders end up generating more traffic on the network. The reduction in fault tolerance
occurs because the use of forwarders means that there are fewer copies of the database
available in case a DNS server fails. When a primary or secondary DNS server fails, it means
that there is one less DNS server available to process client requests. If you are using
forwarders, and the primary DNS server used by the forwarders fails, the primary DNS server
and all the forwarders become unavailable.
Using Separate Internal and External Namespaces

If your organization will have an Internet presence, you should create a namespace for use on
the Internet and a different namespace for use on your intranet. DNS was designed to

distribute information in response to queries from clients. It was not designed to provide
secure access to the information it distributes. Because of this, DNS environments are
vulnerable to attacks that cause information disclosure.
As security becomes a higher and higher priority for network operations, features have been
added to DNS to make it a more secure environment. However, these features are geared
more toward preventing the registration of invalid information than preventing information
disclosure. A DNS server responds to any DNS client queries that are applicable to the zone
for which the DNS server is authoritative. It does not perform any kind of security check to
make sure that a valid user or client is making the query. If you use the same namespace for
your Internet presence and your intranet, clients on the Internet can send queries to your DNS
servers in an attempt to learn the names of resources on your intranet.
Most organizations have an internal DNS infrastructure for name resolution of internal
resources and a separate external DNS infrastructure that gives them a presence on the
Internet. This is referred to as a split namespace. This infers a set of DNS servers for the
internal namespace and a separate set of servers for the external namespace. A split
namespace ensures that users who query for the external name cannot access or get
information about an internal resource.
For more information about configuring DNS, see Best Practice Active Directory Design for
Managing Windows Networks and Best Practice Active Directory Deployment for Managing
Windows Networks. To download these guides, see the Active Directory link on the Web
Resources page at http://go.microsoft.com/fwlink/?LinkId=291.
Non-Active Directory-Integrated DNS Security

This guide focuses on using Active Directory-integrated zones, which is the recommended
practice for DNS deployment. Although details about file-based DNS deployments (nonActive Directory-integrated deployments) are not presented here, setting NTFS file
permissions on zone files is important enough to mention. DNS database files are stored in a
plaintext format. Any user who can gain access to the disk drive where these files are stored
can open these files with a text editor, such as Notepad, and make changes. You can use
NTFS file permissions to prevent this type of access, although you should make sure that any
changes do not prevent normal system access.
Recommendations: Securing DNS

The following tables summarize the recommended steps for increasing the security of a DNS
environment that is used to support Active Directory.
Recommendations for Deploying Secure DNS

The following table provides a checklist of recommendations for making the DNS
environment used by Active Directory more secure.

Check Protecting DNS Servers

Use Active Directory-integrated DNS zones.

Implement IPSec between DNS clients and servers.
Protect the DNS cache on domain controllers.
Monitor network activity.
Close all unused firewall ports.
Check Protecting DNS Data
Use secure dynamic update.
Ensure that third-party DNS servers support secure dynamic update.
Ensure that only trusted individuals are granted DNS administrator privileges.
Set ACLs on DNS data.
Use forwarders instead of secondary zones.
Use separate internal and external namespaces.
Recommendations for Non-Active Directory-Integrated DNS Security

The following table provides a checklist of recommendations for making your DNS
environment more secure when you are not using Active Directory-integrated zones.
Check Enhancing Non-Active Directory-Integrated DNS Security
Set NTFS file permissions on zone files.
Top of page
Appendix: Procedures

This appendix contains the procedures needed to perform the security updates that are
recommended in this guide. In some instances, a link to another document is provided, rather
than a procedure.
Allowing Logon Access to Administrator Workstations

Limit the locations where the service administrator accounts can log on by allowing logon
locally to Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and
Account Operators only on administrative workstations. Administrative workstations are the
computer objects in the Administrative Workstations organizational unit (OU).

Requirements

Credentials: Domain Admins

Tools: Active Directory Users and Computers

To allow logon access to the Administrative Workstations OU

1. Log on with Domain Admins credentials, and then open Active Directory Users and
Computers.
2. In the console tree, right-click Administrative Workstations, and then click
Properties.
3. On the Group Policy tab, click New.
4. Type Service Administrator Policies, and then click Edit.
5. Expand the policy tree to Computer Configuration\Windows Settings\Security
Settings\Local Policies\User Rights.
6. In the details pane, double-click Logon locally.
7. Select Define these policy settings, and then click Add.
8. Add Everyone to the list, and then click OK.
9. In the details pane, double-click Deny logon locally.
10. Click Define these policy settings.
11. Remove any users from the list, and then click OK.
Changing the Security Descriptor on AdminSDHolder

The security descriptor on AdminSDHolder serves two purposes. First, it controls access to
the AdminSDHolder object itself. Second, it acts as the master security descriptor that is
periodically applied to the service administrator accounts and their members to ensure that
they remain protected.
Requirements

Credentials: Domain Admins

Tools: Active Directory Users and Computers

To change the security descriptor on AdminSDHolder

1. Log on with Domain Admins credentials, and then open Active Directory Users and
Computers.
2. On the View menu, click Advanced Features.
3. In the console tree, click the System node.

4. In the details pane, right-click AdminSDHolder, and then click Properties.

5. On the Security tab, modify the security descriptor by changing the settings as
specified in Table 39.
Creating a Decoy Administrator Account

This procedure adds an additional layer of protection when hiding the default Administrator
account. An attacker planning a password attack on the Administrator account can be fooled
into attacking an account with no special privileges.
Requirements

Credentials: Domain Admins

Tools: Active Directory Users and Computers

To create a decoy Administrator account

1. Log on with Domain Admins credentials, and then open Active Directory Users and
Computers.
2. In the console tree, right-click the Users node, click New, and then click User.
3. Create a New User with the following information:
1. In First name and User logon name, type Administrator.
2. Type and confirm a password.
Your new account will appear in the Users container.
4. In the details pane, right-click Administrator, and then click Properties.
5. On the General tab, in the Description box, type Built-in account for administering
the computer/domain.
Creating a .reg File

To create a scripting solution that changes a registry setting on a computer, you can use the
registry editor to add or modify a registry setting and then export the setting to a .reg file. You
can use the .reg file in scripts to apply the setting to other computers.
Caution:
Do not edit the registry unless you have no alternative. The registry editor bypasses standard
safeguards, allowing settings that can damage your system, or even require you to reinstall
Windows. If you must edit the registry, back it up first and see the Registry Reference in the
Microsoft Windows 2000 Server Resource Kit at .

Requirements

Credentials: Administrators
Tools: Regedit.exe

To export a registry setting to a .reg file

1. Click Start, click Run, type regedit, and then click OK.
2. In the console tree, navigate to the registry entry that you want to export to the file.
3. Add or modify the registry entry that you want to export to the .reg file.
4. With the registry entry selected, on the Registry menu, click Export Registry File.
5. In the Save in box, navigate to the location for the .reg file.
6. In the File name box, type a name for the .reg file (Registration Files type).
7. Under Export range, click Selected branch, and then click Save.
Creating a Reserve File

This procedure reserves disk space by creating a file on the same disk volume as the Active
Directory database. The reserve file size should be 250 megabytes (MB) or 1 percent of the
size of the logical disk volume where the Active Directory database is stored, whichever is
larger.
Requirements

Credentials: Domain Admins

Tools: Fsutil.exe

To create a reserve file on your domain controller

1. Log on to a client computer running Windows XP Professional.
2. Connect to the remote administrative share for the disk volume where the Active
Directory database is stored, for example, C$ or D$.
3. Create the reserve file on the same disk volume as the Active Directory database by
using the following command from any Windows XP Professional client:
4. fsutil file createnew reserve_file_name reserve_file_size

Ensure that the reserve file name you specify resides on the same disk volume as the
Active Directory database files. The reserve file size should be 250 MB or 1 percent
of the size of the logical disk volume where the Active Directory database is stored,
whichever is larger.
5. Grant Administrators Full Control on the reserve file.

Denying Logon Access to the Domain

Limit the locations where the service administrator accounts can log on by denying logon
locally to Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and
Account Operators at the domain level. This will prohibit administrators from logging on to
any computers in the domain. Be sure also to implement the procedure "Allowing Logon
Access to Administrator Workstations" to restore logon capability to administrators when
they are logging on to administrator workstations.
Requirements

Credentials: Domain Admins

Tools: Active Directory Users and Computers
Caution:
Do not use this procedure without also following the procedure in "Allowing Logon
Access to Administrator Workstations." Failure to do so may result in your service
administrators being unable to log on to any workstations or member servers in the
domain.

To deny logon access at the domain-level to service administrators

1. Log on with Domain Admins credentials, and then open Active Directory Users and
Computers.
2. Expand the console tree, right-click domain_name , and then click Properties.
3. On the Group Policy tab, click Default Domain Policy, and then click Edit.
4. Expand the policy tree to Computer Configuration\Windows Settings\Security
Settings\Local Policies\User Rights.
5. In the details pane, double-click Deny logon locally.
6. Select Define these policy settings, and then click Add.
7. Add all service administrator accounts (Administrators, Schema Admins, Enterprise
Admins, Domain Admins, Server Operators, Backup Operators, and Account
Operators) to the list.
Enabling Auditing on Active Directory Database Objects

This procedure configures auditing on actions that are performed against Active Directory
objects. The actions to be audited are specified in Table 19 through Table 30.
Requirements

Credentials: Domain Admins

Tools: ADSI Edit administrative tool console (in Windows 2000 Service Pack 3 (SP3)
Support Tools)

To enable auditing on Active Directory database objects

1. Log on to a domain controller in the root domain using an account with Domain
Admins credentials, and then open ADSI Edit.
To open ADSI Edit, run mmc, click File, click Add/Remove Snap-ins, select ADSI
Edit, and then click Add
2. In the console tree, right-click ADSI Edit, and then click Connect to.
3. In the Connection dialog box, in Naming Context, select naming_context (where
naming_context is the directory partition of interest), and then click OK.
4. Expand the console tree, right-click container_object (where container_object is the
domain or domain controller OU where auditing will be enabled), and then click
Properties.
5. On the Security tab of the Properties dialog box, click Advanced.
6. On the Auditing tab of the Access Control Settings dialog box, click Add.
Create auditing settings to match the settings in Table 19 through Table 30.
Enabling Monitoring for Anonymous Access

Enabling monitoring for anonymous access is set through SACLs on the Active Directory
object CN=Server, CN=System, domain, DC=.... The SACLs ensure that a security audit log
event is generated whenever an application or service attempts to list or read domain data in
Active Directory with anonymous access. The most common instances are applications such
as Routing and Remote Access Service (RRAS) running on Windows NT 4.0 domain
controllers or on member servers in the context of Local System.
Note:
In addition to setting these SACLs, the Audit directory service access audit policy must be
configured to audit successful access to the directory. For more information about enabling
the Audit directory service access audit policy, see "Establishing Domain Controller Audit
Policy Settings earlier in this guide.
Requirements

Credentials: Domain Admins

Tools: ADSI Edit (in Windows 2000 Server SP3 Support Tools)

To enable monitoring for anonymous access

1. Log on to a domain controller in the root domain using an account with Domain
Admins credentials, and then open ADSI Edit.
To access ADSI Edit, run mmc, click File, click Add/Remove Snap-ins, select ADSI
Edit, and then click Add.

2. In the console tree, right-click ADSI Edit, and then click Connect to.
3. In the Connection dialog box, in Naming Context, select Domain NC, and then
click OK.
4. In the console tree, browse to the domain_name /System node, and then click
System.
5. In the details pane, right-click Server, and then click Properties.
6. On the Security tab, click Advanced.
7. On the Auditing tab, set the SACLs, based on the information in Table 45.
Table 45 SACL Settings for
CN=Server,CN=System,DC=Domain,DC=...ForestRootDomain
Type

Name

Access

Success Anonymous Logon Read property

Apply To
This object only

Success Anonymous Logon Enumerate Entire SAM Domain This object only
Enabling SID Filtering

SID filtering is applied to an external trust between a trusting domain and a trusted domain to
"quarantine" the trusted domain. This feature removes any security identifiers (SIDs) from
the trusted domain's authorization data that do not reference the trusted domain.
Requirements

Credentials: Domain Admins for the trusting domain

Tools: Netdom.exe (in Windows 2000 Server SP3 Support Tools)
Note:
This procedure assumes that an external trust already exists between the trusting and
trusted domains.

To enable SID filtering

1. Log on to a domain controller in the trusting domain using an account with Domain
Admins credentials.
2. At a command line, type:
3. netdom trust trustingDomainName /domain:trustedDomainName
/filtersids:yes /userd:username [/passwordd:userpassword]

If you do not specify a password in the command, you will be prompted for one.

Linking a New Policy to the Domain Controller OU-Level GPOs

This procedure accomplishes two things. First, the new Group Policy is added to the list of
Group Policy objects (GPOs) that are applied at the Domain Controllers OU level. Second,
the new GPO is moved to the top of the list of GPOs to ensure that its policy settings are not
overridden by other GPOs.
Requirements

Credentials: Domain Admins

Tools: Active Directory Users and Computers
Important:
Policy setting changes to user rights or auditing must be made on the default GPO
rather than added to the list of GPOs.

To link a domain controller Group Policy object to the default GPO

1. Log on with Domain Admins credentials, and then open Active Directory Users and
Computers.
2. In the console tree, right-click Domain Controllers, and then click Properties.
3. On the Group Policy tab, click Add.
4. On the All tab in the Add a Group Policy Object Link dialog box, select the new
GPO, and then click OK.
5. Move the new GPO to the top of the list of domain controller GPOs to ensure that its
settings take precedence.
6. Restart the computer, or run Secedit/refreshpolicy machine_policy to update the
Domain Controllers OU Group Policy settings.
Monitoring for Anonymous Access

In a previous procedure, you enabled security monitoring for anonymous access by setting
SACLs. These SACLs are set on the objects that are accessed anonymously by applications
and services on other domain controllers, member servers, or workstations in the domain.
Note:
To complete this procedure you need software that is capable of aggregating the Security
event logs on all domain controllers into a single log. In addition, you need software that can
query the Security event log based on the criteria in this procedure.
To make the analysis of the aggregated Security event logs easier, export the aggregated
Security event logs to a database, such as Microsoft Access. Collect the event logs for about
30 days to ensure that all applications have attempted anonymous access, paying special
attention to applications and services running on Windows NT 4.0 in the security context of
Local System.

Requirements

Credentials: Domain Admins

Tools: unspecified database product

To monitor for anonymous access

1. Collect Security event logs for 30 days on all domain controllers.
2. Aggregate the event logs from each domain controller into a database.
3. Identify the anonymous access events in the aggregated event logs by querying the
Security event log for any events with the Event ID 565 (directory service access
events) and the text "anonymous" (case insensitive) in the event.
4. Identify the logon IDs that generated the anonymous access (for the events that meet
the criteria in the previous step).
The output of this query gives you the list of the logon IDs that generated the
anonymous access.
5. Identify the logon and logoff events that are associated with the logon IDs identified
in the previous step by querying the results of the events in the previous step for event
IDs 528 (logon events) or 540 (logoff events).
6. Identify the domain controllers, member servers, or workstations where the logon and
logoff events, identified in the previous step, originated.
7. Identify the applications or services running on the domain controllers, member
servers, or workstations where the anonymous access originated.
Examples of the applications or services that require anonymous access include
Routing and Remote Access Service running on Windows NT 4.0, SQL Server
running on Windows NT 4.0 (with Integrated or Mixed SQL logon), and print servers
running Windows NT 4.0.
Renaming the Default Administrator Account

This procedure eliminates any information that can alert attackers that this account has
elevated privileges. Although an attacker still needs the password to the account, hiding the
default Administrator account adds an additional layer of protection against password attacks
seeking elevation of privilege.
Requirements

Credentials: Domain Admins

Tools: Active Directory Users and Computers

To rename the default Administrator account

1. Log on with Domain Admins credentials, and then open Active Directory Users and
Computers.

2. In the console tree, click Users.

By default, the Administrator account is in the Users container. However, if you
have already created a Service Admin subtree, it may have been moved to the Users
and Groups OU in the new subtree.
3. In the details pane, right-click Administrator, and then click Properties.
4. On the General tab, change Description to resemble other user accounts.
Eliminate anything indicating that this is the Administrator account. In First name
and Last name, type a fake name.
5. On the Account tab in the User logon name dialog box, type a new name.
Again, type a name that cannot be identified as the Administrator account.
Note:
This only changes the default Administrator account's logon name and the account
details that someone can see if they manage to enumerate a list of accounts on your
system. This does not affect the Administrator account that is used to boot into
Directory Service Restore Mode.
Securing Scripts with Script Signing

Two alternatives exist for creating signed scripts. For anyone who is interested in developing
their own script host, the Windows Product Software Development Kit (SDK) contains a set
of tools for signing scripts (Signcode.exe and Chktrust.exe). When writing your own script
host, call Win32 API WinVerifyTrust. This API verifies the trust on a .vbs or .js file.
Alternatively, Windows Script Host (WSH) 5.6 ships with a signer object to create and verify
signed scripts. The following JScript code creates a signed file:
var Signer = new ActiveXObject("Scripting.Signer");
var File = "c:\\myfile.vbs";
var Cert = "Jane Q. Programmer";
var Store = "my";
Signer.SignFile(File, Cert, Store);

The following sample, in this case as Microsoft Visual Basic, Scripting Edition
(VBScript) code, verifies the signing on a file:
Dim Signer, File, ShowUI, FileOK
Set Signer = CreateObject("Scripting.Signer")
File = "c:\newfile.wsf"
ShowUI = True
FileOK = Signer.VerifyFile(File, ShowUI)
If FileOK Then
WScript.Echo File & " is trusted."
Else
WScript.Echo File & " is NOT trusted."
End If

Updating the Default Group Policy on the Domain and the Domain
Controllers OU

This procedure modifies either the default domain-level Group Policy or the default Domain
Controllers OU-level Group Policy.
Requirements

Credentials: Domain Admins

Tools: Active Directory Users and Computers
Important:
Policy setting changes to user rights or auditing must be made on the default GPO
rather than added to the list of GPOs.
Table 46 Policy Settings Applied to the Default GPO
Where Policy Is Applied
Domain root

Domain Controllers OU

Policy

Recommended Policy Settings

Password

See Table 14

Account Lockout

See Table 15

Kerberos

See Table 16

User Rights Assignment See Table 17

Audit

See Table 18

To link a domain controller GPO to the default GPO

1. Log on with Domain Admins credentials, and then open Active Directory Users and
Computers.
2. In the console tree, right-click the container where the policy will be applied, as
specified in Table 46, and then click Properties.
3. On the Group Policy tab, select the default GPO, and then click Edit.
4. In the policy tree, click the appropriate policy, as specified in Table 46.
5. In the details pane, double-click the policy setting of interest.
6. In the policy setting dialog box, type the recommended value.
7. Restart the computer, or run Secedit/refreshpolicy machine_policy to update the
Domain Controllers OU Group Policy settings.

Best Practice Guide for Securing Active

Directory Installations and Day-to-Day
Operations: Part II
3 out of 12 rated this helpful - Rate this topic

Part II of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day
Operations contains recommendations for managing domain controllers in a secure manner,
detecting attacks, defending against known and unknown threats, and recovering from
attacks. This guide provides guidelines for Active Directory administration, monitoring, and
recovery that are designed to maintain a secure operating environment.

On This Page

Introduction
Chapter 1 - Maintaining Secure Active Directory Operations
Chapter 2 - Monitoring the Active Directory Infrastructure
Chapter 3 - Recovering from Active Directory Attacks
Appendix A: Overloading the PDC Emulator
Appendix B: Procedures
Introduction

Organizations require a network operating system (NOS) that provides secure access to
network data by authorized users and rejects access by unauthorized users. For a Microsoft
Windows 2000 network operating system, the Active Directory directory service provides
many key components needed for authenticating users and for generating authorization data
for controlling access to network resources.
A breach in Active Directory security can result in the loss of network resource access by
legitimate clients or in the disclosure of potentially sensitive information. Such information
disclosure can occur for data that is stored on network resources or from the Active Directory
database itself. To avoid these situations, organizations need more extensive information and
support to ensure enhanced security for their NOS environments. This guide addresses this
need for organizations that have new, as well as existing, Active Directory deployments.
A comprehensive plan for Active Directory security requires action in five areas:

Protection of domain controllers against known threats

Administrative policies and practices to maintain security

Detection of attacks that have not been identified or mitigated previously

Defense against Active Directory attacks

Recovery from Active Directory attacks

The Best Practice Guide for Securing Active Directory Installations and Day-to-Day
Operations comprises two parts. Part I of the guide contains recommendations for protecting
domain controllers from potential attacks of known origin and recommendations for
establishing secure administrative policies and procedures. Part II of the guide, which is
presented here, contains recommendations for managing domain controllers in a secure
manner, detecting attacks, defending against known and unknown threats, and recovering
from attacks.
Scope of This Guide

Although NOS security relies on secure operations for all components in the operating
system, the scope of this guide is limited to recommendations for operating, monitoring, and
restoring Active Directory domain controllers and workstations used for Active Directory
administration. Other security topics, such as secure network connectivity and secure clients,
are not addressed in this guide.

Part II of this guide provides guidelines for Active Directory administration, monitoring, and
recovery that are designed to maintain a secure operating environment. These guidelines,
which can be applied to both new and existing Active Directory infrastructures, are organized
into the following chapters:

Maintaining Secure Active Directory Operations

Monitoring the Active Directory Infrastructure

Recovering from Active Directory Attacks

The recommendations in this guide take into consideration how an organizations domain
controllers are deployed. Domain controllers can be deployed in datacenters for enterprise
intranets, in branch offices, and in datacenters for extranets. In some cases, the guidelines
vary in accordance with special circumstances that are encountered in each environment.
Audience
This guide is intended primarily for IT planners, architects, and managers who are
responsible for establishing Active Directory deployment and operations practices. As a
result, this guide emphasizes the decision-making process rather than procedures.
How to Use This Guide
The information in this guide is presented as if the readers organization is planning its Active
Directory deployment and operations. However, this information can be equally beneficial to
an organization that is reviewing its current Active Directory security practices.
Proceed through the Active Directory security maintenance process as presented in this guide.
Each phase of the Active Directory security maintenance process, such as maintaining
domain controller and administrative workstation security, is contained in its own chapter.
Each chapter topic begins with a discussion of how these security recommendations enhance
security, and also discusses their cost in terms of complexity and performance. If a
recommendation is impractical for a specific deployment strategy, then that limitation is
indicated. If alternate recommendations exist for a given Active Directory deployment, then
this alternative is presented. Finally, the recommendations in each chapter are summarized in
a checklist at the end of the chapter.
You can proceed to the next chapter after completing the checklist of recommendations at the
end of the previous chapter.
Process for Securing Active Directory Installations and Operations

This guide focuses solely on the deployment and operation recommendations for creating a
secure Active Directory system. Figure 1 depicts the process flow for the recommendations in
this guide.

Figure 1: Process Flow for Securing Windows 2000 Active Directory

Parts I and II in the flowchart correspond to Parts I and II of this guide.

Part I of the process is designed to create a secure domain controller environment. To review
Part I of this guide, see Best Practice Guide for Securing Active Directory Installations and
Day-to-Day Operations: Part I at http://www.microsoft.com/downloads/release.asp?
ReleaseID=44459.
Part II of the process is designed to help maintain a secure Active Directory infrastructure.
This includes a list of day-to-day security operations to perform, specific events and
resources to monitor, administrative activities to audit, and how to detect and respond to an
attack. Finally, in the case of a security attack damaging some portion of the Active Directory
infrastructure, Part II provides recommendations for system recovery.
Top of page
Chapter 1 - Maintaining Secure Active Directory Operations

Once an organization has deployed their Windows 2000 domain controllers in accordance
with the security recommendations laid out in Part I of this guide, it is essential that this level

of domain controller security be maintained or even enhanced over time. Whether or not the
environment will remain secure is determined in large part by the organizations IT
operations practices.
Part I of this guide provides recommendations for deploying Active Directory securely, such
as building and configuring domain controllers. Part II provides recommendations for
maintaining Active Directory securely with such practices such as periodically auditing
domain controller configurations to ensure that unauthorized changes have not occurred.
Note: This chapter contains recommendations for periodic audits of domain controller
configurations, administrative group memberships, and administrative privileges. The term
audit here refers generally to processes that regularly track security practices and
configurations and not to events that are logged in the security event log. This ensures that
security practices are being followed and that the intended security configurations remain in
place.
Each organization should develop policies for domain controller administration to provide a
basis for secure domain controller operations. A set of written and enforced policies will
ensures that domain controller administrators:

Clearly understand the security policies and security code of conduct of the
organization.
Can trust that the same level of security exists elsewhere in the organization.
Can respond in a timely manner with the best solution for a problem if a security
breach or incident occurs.

Important: Recommendations and procedures in this document assume that you are running
Windows 2000 Server Service Pack 3 (SP3) or later for servers and Windows 2000
Professional Service Pack XX or later for Administrative workstations.
Designating Servers as High Security Server
Although security is an important consideration for all components of an organizations
network, for some servers, designated as high security servers, security is of particular
importance. The high security designation stems from the high security privileges that are
associated with processes running on these servers. Designate any server in your organization
as a high-security server when it:

Runs a service in the context of a service administrator-level account.

Is trusted for delegation.

When a server is trusted for delegation, the server has the capability, when servicing a
client request, of requesting services from another server under the clients security context.
Since the requesting client could have arbitrarily high security privileges, the server can
therefore assume arbitrarily high security privileges. Therefore, all servers that are trusted
for delegation within the forest should be designated as high-security servers.

Based on these criteria, in addition to domain controllers there may be other high-security
servers in your network which will require special day-to-day operations to remain secure.
Protect all high-security servers by following these general guidelines for secure server
operations.

Practice regular, secure domain controller maintenance.

Stay current on all security patches and hotfixes.

Manage forest-wide configuration settings for Active Directory.

Manage security of service administrator accounts.

This chapter provides specific recommendations for maintaining the security of domain
controllers, other high-security servers, and administrative workstations.
Maintaining Domain Controller and Administrative Workstation Security

When your organization attains secure domain controller and administrative workstation
configurations by implementing the recommendations presented in Part I of this guide, you
begin operations. In a production environment, administrators perform day-to-day and,
occasionally special maintenance on domain controllers and administrative workstations.
How these tasks are performed directly affects the level of domain controller and
administrative workstation security that your organization can maintain.
Written policies and practices should exist for all domain controller maintenance operations,
including:

Domain controller backup and restore.

Domain controller and administrative workstation hardware retirement.

Domain controller and administrative workstation virus scans.

Establishing Domain Controller Backup and Restore Strategies

Administrators schedule regular system state backups on domain controllers to recover from
the loss of Active Directory data and the loss of a domain controller. Depending upon its
location, the failure of a domain controller can cause a serious disruption in service. As part
of secure management and recovery operations, domain controller backups must be
performed regularly and securely. System state backups on domain controllers differ from
typical server backups and restores in its complexity because:

Incremental backups are not possible.

Not all domain controllers should be backed up.

Backups from one domain controller cannot be used to restore a different domain
controller.

Restores are either authoritative or non-authoritative.

Domain controllers are high-security servers, requiring special handling.

Due to the high-level security requirements, a secure backup and restore policy includes
security practices that are not required for a typical server backup. A secure domain controller
backup and restore strategy should include the following key practices:

Avoid the use of a common, enterprise-wide account for backup.

Limit domain controller backup hardware to locations with hardware and media
security.

Schedule regular domain controller backups, and destroy out-of-date backup media.

Protect Backup Operators accounts.

Practice restoring domain controllers from backup media periodically.

Implement an enterprise-wide, published backup and restore policy that specifies which
domain controllers should be backed up, who has permission to perform this function, how
frequently domain controllers will be backed up, and how the backup media should be
handled.
Dedicating a Backup Agent Service Account for Domain Controllers
The service account that is used to back up domain controllers must be a service
administrator, and therefore highly privileged. To maintain a high level of security, backup
agent service accounts used for backing up domain controllers should be different from the
service accounts that are used for other server backups.
When a domain controller is promoted, a special built-in group, Backup Operators, is created
in Active Directory. This group possesses the privileges necessary to backup and restore files
on all domain controllers in the domain and hence its members are service administrators. As
a general recommendation, membership in groups with service administrator privileges
should be highly restricted. Users that are responsible for backing up data on application
servers only (and not domain controllers) should therefore not be made a member of the
Backup Operators group in Active Directory.
To back up a domain controller, the backup agent service running on the domain controller
must run in the security context of an account with Backup Operator privileges (service
administrator-level privileges). If the same backup agent service account is used for backups
on both domain controllers as well as other application servers, then the application servers
could potentially be compromised to gain access to this highly-privileged account.
An intruder, who gains access to such an application server with a backup agent service and
compromises the backup agent service account, can gain access to administrative credentials.
Therefore, a backup agent service account with service administrator credentials should only
be used to perform backups for domain controllers. To maintain this separation, require that
different backup agent service accounts for application servers and for domain controllers.

Figure 2: Distinction Between Backup Agent Service Accounts on

Domain Controllers and Application Servers

Limiting Backup Services and Media Storage to Secure Locations

Provide domain controller backup media with the same level of physical security as the
domain controllers themselves. Because the backup media contains all the information in the
Active Directory database, theft of the backup presents the same risks as theft of a domain
controller or a disk drive from a domain controller. An attacker could restore the information
elsewhere and access Active Directory data.
To prevent individuals from gaining unauthorized access to backup media:

Remove media from the backup hardware drive as soon as the backup process
completes.
Store backup media that you use on site in a secure location where access is audited.

Store archival backup media securely off site.

Establish processes and procedures that require the signatures of authorized

administrators when any archival backup media is brought back on site.

Choosing a Backup Strategy for Branch Offices

Implementing a domain controller backup strategy is straightforward for organizations with
domain controllers located in a few secure locations. In such organizations, you can
administer domain controller backups in a secure manner relatively easily.
In contrast, domain controller backups tend to be performed infrequently, if at all, in locations
with the following characteristics:

Limited facilities by way of its IT infrastructure or administrative staff.

Limited ability to securely store the media on or off site.

A location with limited IT facilities might be a smaller, regional datacenter or branch office.
For the purposes of this guide, locations with limited facilities are hereafter referred to as
branch offices.
Infrequent backups at branch offices occur for several reasons:

Purchasing and maintaining a backup system can be costly.

Training and maintaining on-site administrators increases overhead costs.

Limiting the locations where domain controller backup media must be protected
enhances security.

Because most branch offices are resource constrained, and Active Directory backups
are very disk-intensive operations, backups may need to wait until weekends or other
less busy periods.

Table 1 lists three alternatives for secure backup and restore practices at branch offices.
Table 1 Possible Backup and Restore Practices for Regional Datacenter and Branch
Offices
Option

Advantages
Easy to secure

No domain controller backups at

Least administrative
branch offices
overhead

Disadvantages
Higher risk of data loss
Long delays possible when
restoring a domain controller in
the branch office

Relatively easy to secure

Backups at all branch offices
using remote backup systems
(off-line media) in secure data
centers

Reduced risk of delays in

More administrative overhead
restoring domain controller
in branch office
Low risk of data loss
Most administrative overhead
Backups at all branch offices
Least downtime when a
using local backup to disks (ondomain controller fails in
Difficult to secure.
line media)
branch office.
Some organizations may choose to eliminate regional datacenter and branch office domain
controller backups altogether. Foregoing this process eliminates the cost and complexity of
backups, as listed in Table 1. The disadvantages are that the failure of a domain controller in
these locations exposes their users to the possibility of substantial downtime while a new
domain controller is built and promoted.
Tape-backup infrastructures duplicating those in enterprise datacenters can be deployed at
regional datacenters if the organization has a complex site topology, a large number of sites to
back up, and insufficient connectivity between branch office sites and the enterprise
datacenter.

Developing a Secure Remote Backup Process

If your organization chooses to backup branch office domain controllers to a centralized
backup infrastructure, two secure strategies are possible. These are:

Directly backing up domain controllers to a central location, or

Temporarily backing up domain controllers to a secure, local disk share that can be
downloaded later by a backup system in a central location.

If you plan to download data from domain controllers in branch offices or small datacenters
directly to the backup devices in a secure location, determine if there is adequate network
bandwidth and off-peak time to perform all the backups that you have planned. Backing up a
domain controller is a disk-intensive operation that should be performed during off-peak
hours or over the weekend. Backing up a large number of domain controllers to a single
backup infrastructure can require more time than can be easily scheduled within off-peak
times.
An alternative strategy is to write domain controller data from branch offices or small
datacenters to local, secure disk storage first. This step avoids the need to deploy costly tapebackup infrastructure to field locations. It also increases security, because without distributed
backup tapes, there is less likelihood of the compromise of a singe tape. Subsequently, the
local backup to disks in branch offices can be downloaded to off-line media backup systems
in enterprise data centers.
All field domain controllers should have a file share with the same designation. This share
will contain only the most recently backed up copy of the system state of the domain
controller. Should the domain controller operating system fail, this copy can be used to
quickly restore the machine. To make this method secure, configure backup share
permissions so that only domain administrators can access this shared drive.
Ensuring That the Required Backup Media Is Available When Needed
For each backup, verify that the backup runs to completion. Your organizations backup
software determines how backup success is verified. For example, the NTBACKUP utility
logs event ID 8019 upon the successful completion of a backup. Your organizations
monitoring software, such as Microsoft Operations Manager (MOM) 2000, can be
configured to monitor for backup success or failure.
Note: Verify that your organization backs up your domain controllers with a frequency that is
less than the Active Directory tombstone lifetime. To ensure this, you can recycle backup
media after it exceeds 75 percent of the tombstone lifetime.
A check should be performed weekly in each domain to ensure that:

At least two domain controllers have been successfully backed up that week.
If backups are not successfully performed, then the problem should be escalated and
resolved as a high priority.

Backup media that is created has been clearly labeled with the name of the domain
controller and the date the backup is created and then stored securely.

Include the name and roles of the domain controller in the label of the backup media to
facilitate easy identification later. One suggested format for labeling the backup media that
captures important information about the domain controller is:
FQCN.Build.OMRole.[GC].[MD5].TSL.YYMMDD.BKF, where:

FQCN is the fully qualified computer name.

Build is the build number of the operating system.

OMRole indicates the operations master role(s) held.

GC indicates that this is a global catalog.

MD5 indicates that a message digest5 digital signature was added (optional).

TSL is the terminal service license (Optional).

Managing Backup Operators Accounts

Active Directory contains a built-in group named Backup Operators. Members of this group
are considered service administrators, because the groups members have the privilege to
restore files, including the system files, on domain controllers. Membership in the Backup
Operators group in Active Directory should be limited to those individuals who back up and
restore domain controllers.
All member servers also contain a built-in group called Backup Operators that is local to each
server. Individuals who are responsible for backing up applications on a member server
should be made members of the local Backup Operators group on that server as opposed
to the Backup Operators group in Active Directory.
On a dedicated domain controller, you can reduce the number of members in the Backup
Operators group. When a domain controller is used for running other applications, as it might
be in a branch office, individuals who are responsible for backing up applications on the
domain controller must also be trusted as service administrators, because they will have the
privileges necessary to restore files, including the system files, on domain controllers.
By default, the Backup Operators group is empty. Its membership can be modified by
members of the Administrators, Domain Administrators, and Enterprise Administrators
groups. The Backup Operators group is not protected by the special default security
descriptor settings on the AdminSDHolder object that are applied to other service
administrator accounts. To protect the Backup Operators group in Active Directory, apply the
same permissions that protect other service administrator accounts. These permissions are
listed in Table 2,
Table 2 Security Descriptor to Protect the Backup Operators Group in Active Directory

Type

Name

Permission
List Contents

Apply To

Read All Properties

Write All Properties
Delete
Read Permissions
Allow Administrators

Modify Permissions

This Object Only

Modify Owner
All Validated Writes
All Extended Rights
Create All Child Objects
Delete All Child Objects
List Contents
Allow Authenticated Users

Read All Properties

This Object Only

Read Permissions
List Contents
Read All Properties
Write All Properties
Read Permissions
Modify Permissions
Allow Domain Admins

Modify Owner

This Object Only

All Validated Writes

All Extended Rights
Create All Child Objects
Delete All Child Objects
List Contents
Allow Enterprise Admins

This Object Only

Read All Properties

Write All Properties
Read Permissions
Modify Permissions
Modify Owner
All Validated Writes
All Extended Rights
Create All Child Objects
Delete All Child Objects
Allow Everyone

Allow PreWindows 2000 Compatible Access

Change Password
List Contents
Read All Properties

This Object Only

Special

Read Permissions
Allow SYSTEM

Full Control

This Object Only

Practicing Active Directory Recovery Procedures

Backup media can be used to restore Active Directory data on a functioning domain
controller (data restore) or to recover one or more nonfunctioning domain controllers
(recovery).
Using backup media to recover an entire domain controller that has failed or been corrupted
is a seldom-used practice. The most common method for recovering a single, failed domain
controller is to promote a member server to a domain controller and then replicate the Active
Directory data from another domain controller that is available online. However, if there are
no available domain controllers that are free of corruption, you may need to resort to domain
controller recovery from backup media. Because recovery procedures are performed
infrequently, unknown problems may exist in your domain controller recovery practices,
including the following:

Failed backup media

Incomplete or erroneous recovery procedures

Lack of familiarity with procedures on the part of individuals who are responsible for
domain controller recovery

To help avoid these problems, consider implementing the following recommendations:

Verify the quality of your backup media by periodically performing a data restore on a
domain controller.
Ensure that your administrators are familiar with forest recovery procedures before
they are needed by periodically performing a forest recovery.

Verifying That Backup Media Is in Good Condition

To help ensure that a restore from backup media will succeed, validate the quality of the
backup media on a regular basis. Your organization should establish a practice of verifying
the backup media quality with a frequency that is less than the Active Directory tombstone
lifetime. Because backup media should be discarded before one tombstone lifetime has
elapsed, this practice ensures that at least one useful backup exists at all times.
An Active Directory data restore includes the following steps:

Use a test domain controller in a lab setting, isolated from the production forest.
Follow the procedure for data restore from selected backup media.

Verify that the data has been properly restored.

Tag the verified backup media with the date of verification.

To review the procedure for restoring the Active Directory data on a domain controller, see
Performing an Authoritative Restore of Directory Objects in Chapter 3 of this guide.
Practicing Forest Recovery Procedures
To ensure that your organization can successfully recover one or all domain controllers from
backup media, implement the following practices:

Maintain a record of Active Directory data owners.

Prepare an enterprise business recovery plan for the forest.

Prepare a set of procedures for forest recovery.

Practice at least annually restoring from backup media to ensure the quality of the
media.

Practice an Active Directory forest recovery by performing the following tasks:

1. Promote an extra domain controller in each domain in the forest, as shown in Figure
3.
2. Isolate the new domain controllers from the production forest to create a scaled-down
replica of your forest.
3. Add client computers and member servers to the isolated forest to represent the actual
forest.

4. Practice your prepared forest recovery procedure in the scaled-down forest.

Figure 3: Isolating a Server from Each Domain to Practice Forest

Recovery

To review the procedure for restoring the Active Directory forest, see Best Practices: Active
Directory Forest Recovery at
http://www.microsoft.com/windows2000/technologies/directory/AD/redir-bp_forests.asp.
Managing the Life Cycle of Domain Controller Hardware
An organization may regularly dispose of or recycle a significant number of servers,
workstations and backup media. Domain controllers, administrative workstations and domain
controller backup media contain sensitive information that should be secured. To protect
against the recovery of sensitive information in recycled devices, you should have a written
policy that specifies how domain controllers, administrative workstations, and their
associated backup media are to be handled during the recycling process.
This policy should specify, if possible, the recommendations in Table 3.
Table 3 Recommendations for Disposing of Domain Controllers, Administrative
Workstations, and Backup Media
Hardware Type
Hardware devices (computers,
hard drives)

Recommendation
Must be managed to ensure that all data has been destroyed
and is not recoverable before leaving the organization

Media (tapes, hard drives, SANs, Must be erased or degaussed with an approved utility before
optical disks, DVD-RAM)
being reused
Other Media (CDs, microfiche) Must be physically destroyed or degaussed

Running Antivirus Software on Domain Controllers and Administrative Workstations

On domain controllers, administrative workstations, and other high security server continue
to:

Run virus scans.

Obtain regular virus signature updates from your antivirus software vendor.

Before initiating regular antivirus scanning, be aware that some antivirus software can
interfere with the proper operation of domain controllers by:

Interfering with directory database and log file access by the Extensible Storage
Engine (ESE).
Interfering with File Replication service (FRS) database and log file access by ESE

Causing excessive replication by FRS.

The issues with domain controllers running antivirus software are addressed by the
recommendations provided in Part I of this guide see Running Antivirus Software on
Domain Controllers and Administrative Workstations., in Best Practice Guide for Securing
Active Directory Installations and Day-to-Day Operations: Part I at
http://www.microsoft.com/downloads/release.asp?ReleaseID=44459.
Part 1 of this guide recommends that the SYSVOL folder be excluded from virus scanning.
However, excluding SYSVOL increases the risk of a virus attack on a domain controller
because viruses tend to attach to files that are executed such as binaries or scripts. The
SYSVOL folder contains important executables such as logon and startup scripts.
As a counter-measure, implement script signing to protect the integrity of scripts running on
domain controllers and administrative workstations. For information on implementing script
signing see Running Antivirus Software on Domain Controllers and Administrative
Workstations., in Best Practice Guide for Securing Active Directory Installations and Dayto-Day Operations: Part I at http://www.microsoft.com/downloads/release.asp?
ReleaseID=44459.
Note: As a best practice, enforce script signing at least on domain controllers and
administrative workstations. As a general recommendation, enforce script signing all
computers on the network. Operating systems that support script signing are Windows 2000
family of operating systems, Windows XP, and the Windows Server 2003 family.
Staying Current with Security Hotfixes and Service Packs

Throughout a domain controllers life cycle, attackers may attempt to find and exploit
security weaknesses in the operating system. The same is also true of other high-security
servers designated in your network. Security bulletins, service packs, and hotfixes are
periodically released to counter these threats. It is critical to remain up to date on these fixes
on all high-security servers.

Microsoft security bulletins include a rating system to indicate the severity of the problem
addressed by the security updates. Table 4 lists the ratings for security updates and provides a
description of each rating.
Table 4 Severity Ratings for Security Bulletins and Associated Hotfixes
Rating

Definition
A vulnerability whose exploitation can allow the propagation of an Internet worm
without user action

Critical

A vulnerability whose exploitation can result in compromise of the confidentiality,

Important integrity, or availability of users data or of the integrity or availability of
processing resources
Moderate

A vulnerability whose exploitation is mitigated to a significant degree by factors

such as default configuration, auditing, or difficulty of exploitation

Low

A vulnerability whose exploitation is extremely difficult or whose impact is

minimal

Before you can manage the updates that will be required, you need to control what you
currently have in your production environment. Key information that is required to maintain a
managed network includes:

Accurate and up to date inventories of applications and operating systems

Baselines for software applications and hardware configurations

Periodic reviews of inventories and software baselines should be planned as changes are
introduced to the production environment.
Selecting a Security Update Strategy
In a small organization with Internet access from each server or workstation, a local
administrator may handle updates directly. In this case, Windows Update Service downloads
updates directly to each computer and notifies a local administrator on that computer that an
update is available. When an administrator does not centrally manage server updates or if the
administrator cannot ensure and enforce operating system versions, the network is considered
to be unmanaged.
For an unmanaged environment, a local administrator is responsible for keeping the local
computer up to date. Figure 4 illustrates this simple arrangement. In some cases, a large
organization might also use this strategy to update member workstations but manage servers
centrally.

Figure 4: Strategy for Distributing and Installing Security Updates in a

Simple Organization

In a large organization, an automatic method is required to ensure that all of the high-security
servers and administrative workstations are current with regard to security updates. Figure 4
illustrates one recommended design for managing updates on domain controllers and
administrative workstations.

Figure 5: Strategy for Testing, Distributing, and Installing Security

Updates in a Managed Environment

With this update strategy, security updates are downloaded automatically to a designated
computer that is connected to the Internet and isolated from the production environment.
Each update is checked for compatibility with the organizations critical applications in a test
lab that is designed to mirror the normal production environment. If the applications function
normally in the test lab, the update is copied to the update distribution server. A domain
administrator configures the distribution server to push the update out to domain controllers
and administrative workstations.
To optimize the update process for an organization, a number of variations on these two
strategies are possible. The following section discusses the advantages and disadvantages of
each method for automating updates.

Selecting Notification, Deployment, and Auditing Methods

Establish practices for handling update notification, installing, and auditing security updates
to domain controllers, other high-security servers and administrative workstations. Consider
automating the distribution and installation of security updates in your organization by one of
a variety of methods, including the following:

Microsoft Security Notification Service Newsletter

Windows Update Service

Software Update Services

Management software, such as System Management Server

The following topics describe the features of each of these methods in more detail.
Microsoft Security Notification Service Newsletter
The Microsoft Security Notification Service newsletter is a free, subscription-based service
that alerts administrators to new security updates. Register for this free service at:
http://www.microsoft.com/info/PICWhyRegister.htm.
An administrator must be responsible for reviewing any security updates and determining if
the updates will be installed on domain controllers, other high-security servers and
administrative workstations. When using this notification method, select a separate method
for distributing and installing the updates.
Windows Update Service
With Windows Update Service, any computer that is connected to the Internet can
automatically detect and download new operating system updates. You can configure
Windows Update Service to either notify you of a pending update or automatically install the
update. Any computer running Windows 2000 SP3 or later already has Windows Update
Service installed.
Windows Update Service can be configured to automatically install a critical update or to
notify an IT administrator that an update is available. You can configure Windows Update to
install updates automatically, with or without confirmation, based on the security rating of the
update, as listed in Table 4.
The possible limitations of using Windows Update Service as a means of applying service
packs and hotfixes to domain controllers and high-security servers include the following:

For security reasons, an organizations domain controllers and other high-security

servers may not have Internet access.
Automatically installing security updates bypasses the recommendation that all
software be run in a test environment before installation in the production
environment.

Selecting notification instead of automatic updates does not ensure that the service
pack or hotfix is actually installed on all domain controllers and other high-security
servers.

Software Update Services

Microsoft Software Update Services (SUS) provides a solution to the problem of managing
and distributing critical Windows patches that resolve known security vulnerabilities. SUS
takes advantage of the technology used by Windows Update Service to enable enterprisewide, centralized software update management. This software updates Windows 2000
Service Pack 2 or later), Windows XP and Windows Server 2003. It requires that Internet
Information Services (IIS) be enabled on the server running SUS.
One advantage of SUS is that the domain controllers and high-security servers using SUS
updates do not require Internet access to receive the updates. SUS can be configured to
automatically install critical updates or to notify an IT administrator that update are available.
Table 4 lists the security ratings used by Windows Update Service and SUS.
The two possible strategies for managing updates on enterprise servers are referred to as
managed servers and managed datacenter servers, respectively.
Managed Servers
When a new update has been successfully downloaded by the server managing automatic
updates, SUS logs an event that indicates that an update is ready to install. When the
Automatic Updates policy is enabled, SUS performs a scheduled installation, at a specified
day and time, on all high-security servers. Automatic Updates then adds an icon to the
notification area and displays a balloon to the first local administrator who logs on to a server
stating that new updates are ready to install. The local administrator can choose not to install
at this time. However, the Automatic Updates icon remains in the notification area so that the
local administrator can install the updates any time before the scheduled installation time. If
the installation has not occurred by the next scheduled installation time, Automatic Updates
begins a countdown. If no local administrator stops the countdown, the installation proceeds
automatically.
Managed Datacenter Servers
When a new update has been successfully downloaded by the server that manages automatic
updates, SUS logs an event that indicates that an update is ready to install. In this case, the
local administrator must manually install the update. An IT administrator remotely checks the
system events on the server and sees an event stating that an update is ready to install. The IT
administrator determines when the next available system maintenance window occurs and
executes a change notification plan. On the day and time of the scheduled maintenance, a
local administrator logs on to the domain controller and manually installs the critical update.
Automatic Updates
Automatic Updates is the client component for SUS as well as the Windows Update Service.
IT administrators can configure Automatic Updates on domain controllers and high-security
servers with either group policy or registry settings. To make these configuration changes, see

How to Configure Automatic Updates by Using group policy or Registry Settings at

http://support.microsoft.com/default.aspx?scid=kb;EN-US;328010&sd=tech.
Note: When you configure Automatic Updates by using the policy registry keys, the policy
overrides the preferences that are set by the local administrator. If an administrator removes
the registry keys at a later date, the preferences that were set originally are used once again.
Systems Management Server
Most management software packages, such as Microsoft Systems Management Server
(SMS), can also be configured to automatically apply service packs and hotfixes.
SUS focuses on obtaining critical updates for Windows 2000 and Windows XP inside your
corporate firewall as quickly as possible. It is not intended to serve as a replacement for an
enterprise software distribution solution, such as SMS.
SMS can provide complete software management, including the distribution of security
updates that solve operating system security and virus issues. To enhance SMS solutions for
enterprise server management, security-patch improvements exist for Systems Management
Server 2.0.
Table 5 provides a process for evaluating your options for managing security updates and
determining which option to implement, based on your current IT practices.
Table 5 Strategies for Implementing a Security Update Solution
If You are currently

Security Update Management Strategy

Using a solution that is successfully

distributing security updates

Continue to use your current solution.

Using SMS and need a patchmanagement solution

Implement the SMS security patch extensions

contained in Systems Management Server 2.0.

Not using SMS and need a patchmanagement solution

Consider SMS, SUS, or third-party solutions to

determine which one best meets your needs.

Deploying Security Hotfixes and Service Packs

Establish practices that address obtaining, testing, and installing hotfixes and service packs by
performing the following tasks:
1. Obtain a notification and download the most current security updates using one of the
methods listed in Table 6.
Table 6 Methods of Handling Security Update Notification and Download

Notification and
Download

Process for Notification and Download of Updates

Microsoft Security
Notification Service with
Systems Management
Server

Receive email notifications of updates. An administrator

must review the updates and determine if immediate
distribution is required or if the update can wait until the
next scheduled operating system update.

Windows Update Service

with Automatic Update

Automatically download the update and then notify a local

administrator that the update is available for installation.

Software Update Service

with Automatic Update

Automatically download the update to the SUS server and

then notify an administrator that it is available for testing
and distribution to client computers.

You can configure Automatic Update, the client component used by both Windows
Update Service and SUS, to send a notification, to download, or to download and
install security patches. If your organization uses SMS to manage network servers,
SMS can also be used to distribute security updates.
2. Evaluate the threat of the security weakness to your network environment.
3. Arrange to install the update immediately if the threat is great.
4. Test the security updates on domain controllers in a test environment.
5. Before deploying the security updates to the production environment, install and test
the security update in a test lab running your organizations critical applications and
operating systems. The test domain controller and administrative workstation should
be configured identically to those in your production environment.
6. Distribute and deploy security updates to domain controllers in your production
environment using one of the methods provided in Table 7.
Table 7 Methods for Distributing and Deploying Security Updates
Deployment
Method

Deploys Updates By
Configuring Windows Update to do one of the following:

Inform an administrator who is interactively logged onto the Web

Windows
server that updates are available and then install the updates.
Update Service
Automatically installing the updates.
SUS

Automatically distributing the update from an SUS server to domain

controllers and administrative workstations (at a minimum). SUS can
be configured to automatically install the update on computers based

on some characteristic such as site, OU, or group membership.

SMS

Automatically distributing the update to domain controllers and

administrative workstations (at a minimum) using SMS.

Check domain controller operating systems weekly to ensure that the most current
service pack and hotfix upgrades have been applied to all domain controllers and
administrative workstations. Table 8 describes methods for determining which service
pack and hotfix upgrades have been applied to domain controllers and administrative
workstations.
Table 8 Verifying Update Installations Based on Update Method
Audit
Method

To Verify the Update Installation

Manual

List all service packs and security updates that have been applied to this
computer with the Add or Remove Programs setting in the Control
Panel.

SUS

Review SUS reports to determine which domain controllers and

administrative workstations have received the update.

SMS

Create an SMS software audit through a software agent that lists domain
controllers and administrative workstations that have received the update.

Managing Forest-wide Configuration Settings

Users, including anonymous users, can initiate LDAP queries of Active Directory, such as
deep subtree searches. Inefficient LDAP queries can consume substantial domain controller
resources, such as CPU capacity. This represents a potential denial-of -service threat with
regard to Active Directory availability.
Reducing the MaxQueryDuration setting lowers the amount of time that a query runs before a
domain controller considers the query to have timed out, and returns the error
timeLimitExceeded. This increases domain controller resistance to denial-of-service attacks
that exploit inefficient LDAP queries.
The MaxQueryDuration setting can be modified with the NTDSUTIL tool through the LDAP
Policies menu:

To check the current setting, see: Viewing the MaxQueryDuration Setting with
NTDSUTIL, in Appendix B.

To modify the current setting, see Modifying Policy Settings with Ntdsutil, in
Appendix B.

Active Directory is configured with a default value for MaxQueryDuration of 120 (seconds).
Setting this value to 30 (seconds) reduces the possibility of an LDAP query causing a denialof-service attack.
Note: Be aware that in rare instances an application may require the longer time limit. If an
application fails unexpectedly after the MaxQueryDuration setting has changed, try
increasing this value or modifying the application.
Managing Service Administrator Account Security

The members of the service administrator groups represent the most powerful accounts in
your forest and in each individual domain. To minimize security risks, follow the
recommendations below to enforce strong oversight of administrative accounts.
Performing Periodic Audit Checks on Service Administrators
Service administrators control the configuration and functioning of the directory service.
Therefore, this responsibility should be given only to reliable, trusted individuals who
demonstrate responsible ownership and who fully understand the operation of the directory.
Service administrators should also be completely familiar with your organizations policies
regarding security and operations, and they should have demonstrated their willingness to
enforce policies. All individuals who are granted a service administrator account should
follow these practices:

Reserve the service administrator account for tasks that require elevated privileges.
Connect only to the corporate network with this account.

Do not add this account to any local group on any host.

Do not run any services under this account.

Do not configure any system to logon automatically with this account.

Notify Accounts to change or remove this account if your job responsibilities

change.

Do not use service administrator account privileges to obtain information or make

modifications outside your job responsibilities.

Checking Service Administrator Trustworthiness

The following are some recommended practices for managing the membership of the service
administrator groups:

Members of the service administrator groups should undergo background checks

before being granted service administrator account privileges.
Quarterly audits of all individuals with service administrator credentials should be
performed to ensure that they still have legitimate needs for this access.

These audits should evaluate the least privileges required by service administrators to
perform their jobs, in a manner consistent with your organizational practices. In some cases,
the user may no longer need any service administrator privileges. In other cases your
organizations delegation model for Active Directory may have changed, triggering a
reevaluation of least privileges.
Checking Service Administrator Group Memberships
Having a large number of individuals in your organization with service administrator rights
leaves the organization with a heightened vulnerability to rogue administrator attacks.
Review the memberships of all service administrative groups on a weekly basis to:

Review and justify any new members.

Remove any individuals that no longer need service administrative access.

Remove all Schema Admins group members if you are not currently modifying the
schema.

Remove any members that are from a different forest

Checking That Administrator Rights Are Properly Delegated

Review your organizations delegation model quarterly and consider refining the model to
minimize the:

Number of service administrators

Privileges required to perform these jobs

Members of the Backup Operators group can log on locally to domain controllers, archive
files to backup media, and overwrite system files through restore operations. The only
members of this group should be those individuals who perform domain controller backup
and restore operations. To reduce the number of individuals who have these rights, do not
make individuals who are responsible only for member server backup and restore operations,
such as Microsoft SQL Server operators, members of the Backup Operators group.
Avoid using the Account Operators group for strictly delegating a data administration task,
such as account management. Because the default directory permissions give this group the
ability to modify the membership of other service administrator groups, such as Server
Operators, a member of the Account Operators group can elevate his or her privileges to
become a service administrator.
By default, there are no members of the Account Operators group. Membership in this group
should be left empty.
Managing Administrative Passwords and the Logon Process
As recommended, you should specify in your organizations security practices that highly
secure passwords be used especially for service administrator accounts. Recommendations

for implementations and strategies for managing administrative passwords and authentication
are discussed in greater detail below.
Requiring Smart Cards for Administrative Logon
Require your service administrators to use smart cards, if possible, for their interactive
logons. Besides forcing the administrative users to have physical possession of the cards to
log on, smart cards also ensure the use of cryptographically strong passwords on the user
accounts that are randomly generated. This helps protect against the theft of weak passwords
to gain administrative access. To implement this strategy, you must have a public key
infrastructure (PKI) available to authenticate the smart cards.
Require the use of smart cards for administrative logon by setting the smart card option on
the administrative accounts. For the procedures to perform these tasks, see the Appendix in
Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations:
Part I at:
http://www.microsoft.com/windows2000/technologies/directory/AD/AD_SecurityPt1.asp
For more information on using smart cards authentication, see The Smart Card Deployment
Cookbook at:
http://www.microsoft.com/technet/security/guidance/smrtcard/smrtcdcb/default.asp
Sharing Logons for Sensitive Administrative Accounts
For each account that is a member of the Enterprise Admins and Domain Admins groups in
the forest root domain, assign two users to share that account, so that both users must be
present for a successful logon with that account.
Shared administrative accounts can be implemented through either of the following methods.
If you are using:

Password-based credentials for administrative accounts, then split the password

between the two administrators.
Smart card-based credentials for administrative accounts, then split the physical
possession of the smart card and knowledge of the personal identification number
(PIN) for the smart card between the two administrators.

For more information on sharing administrative accounts, see Controlling the Administrative
Logon Process in Best Practice Guide for Securing Active Directory Installations and Dayto-Day Operations: Part I at:
http://www.microsoft.com/windows2000/technologies/directory/AD/AD_SecurityPt1.asp.
Managing DS Restore Mode Administrator Passwords
The DS Restore mode password is set during the DCPROMO process and is only used during
certain maintenance operations, such as directory database compression and Active Directory
restore operation. Therefore, DS Restore mode passwords should be centrally stored and
managed.

Like all service administrator passwords on domain controllers, these DS Restore mode
passwords should be handled securely, following these recommendations:

Require strong, complex, 14-character passwords.

Ensure that a minimum number of trustworthy administrators can access to these
passwords.

If a user is granted temporary service administrator privilege, to compress the

directory database, for example, change the password immediately.

Coordinate password information with the individual or team responsible for maintaining the
password list before promoting a new domain controller. This helps to ensure that the
password is available to service administrators and to no one else.
Maintaining Up to Date Baseline Information

Baseline information performs two distinct roles in maintaining Active Directory security:
analyzing trends in values such as the directory size and providing a periodic snapshot of the
configuration of the Active Directory infrastructure. In some cases, information recorded in a
previous baseline snapshot can provide the fastest and easiest means of restoring this
information to the directory.
Maintain up to date baseline information by completing the following tasks:
1. Create a baseline database of Active Directory infrastructure information.
2. Detect and verify infrastructure changes
3. Update Baseline information
Creating a Baseline Database of Active Directory Information
Table 9 lists the Active Directory infrastructure information that should be included in the
baseline that is maintained and kept as up to date as possible.
Table 9 Information to Include In Active Directory Security Baseline
Active Directory Infrastructure
Component

Audit policies

Information to Record About Each Component

List of policies that are enabled.

For each policy, if success, failure, or both are

enabled for auditing.

GPOs

List of GPOs
List of containers and OUs that have GPOs assigned.

Assignment of GPOs

For each container or OU, the specific GPOs that are

assigned.

List of trusts.
Existing trust relationships

Type of trust (two-way or one-way)

Names of trusting and trusted domains

Domain Controllers OU

Service Administrators OU

List of domain controllers.

List of administrative workstations.
List of service administrator accounts.
List of service administrator account group memberships.

Operations Master role holders

List of domain controllers that currently hold the

operations master roles.
List of sites.
Configuration settings for each site.
List of subnets within each site.
Configuration settings for each subnet.

Replication topology

List of manually created connections.

Configuration settings for each manually created
connection.
List of site links.
Configuration settings for each site link.
Number of objects of each class in the database.

Database characteristics

Size of the database file (.DIT)

Current operating system.
Current service packs.

Service packs and hotfixes for

domain controllers and
administrative workstations

Current hotfixes.
Current version of virus scan database.
Current version of the virus scan software.
Collect initial system state status.

System state for domain

controllers and administrative
workstations

List of files that are expected to change as a normal part of

activity.
List of registry settings that are expected to change as a

normal part of activity.

Current backup media exists

List of domain controllers with current backups

Verify directory backup media

Determine that backup media restores AD successfully

Review the needs of these individuals for the legitimate

Audits of individuals with service
need for administrative access, and ensure they have the
administrator credentials
least privileges necessary to perform their function.
Detecting Active Directory Infrastructure Changes
Changes to the Active Directory infrastructure are identified by either a security log event,
such as an addition to a service account group membership, or by an information change in
the report generated for an infrastructure component.
As a part of your organizations ongoing operations, update the baseline information for the
components in Table 9 anytime you make an infrastructure change. This will ensure your
baseline documentation reflects the current standards within your organization. For example,
if you create a new trust, immediately update your baseline documentation to reflect the
addition of the new trust.
For infrastructure changes that do not generate events, reports should be generated on a
specified interval. Use these reports to compare the actual configuration of Active Directory
against the baseline you created previously.
Updating the Baseline Information
Once a change in the infrastructure information is detected, its validity as an authorized
change should be ascertained as soon as possible. If the information has changed, the change
must either be authorized, causing the baseline information to be updated or the change is
unauthorized, causing the change to be rolled back to its previous state.
Based on the Active Directory infrastructure component, any changes might be detected on
an ongoing basis or on a specified schedule selected for generating status reports, such as
daily, weekly, or monthly. Specifying ongoing updates indicates that a baseline update should
occur as soon as possible after an event is appears in the event log,
Table 10 lists the Active Directory infrastructure components and the corresponding
recommendations for establishing a:

Method of detecting changes in specific infrastructure information

Schedule for updating specific baseline information

Schedule for reviewing specific baseline information

Table 10 How Infrastructure Changes Are Detected, the Frequency of
Recommended Baseline Updates, and the Frequency of Baseline Reviews

Active Directory Infrastructure

Component

Detection by

Update
Baseline

Review
Baseline

Audit policies

Event log

ongoing

Quarterly

GPOs

Event log

ongoing

Quarterly

Assignment of GPOs

Event log

ongoing

Monthly

Existing trust relationships

Event log

ongoing

Quarterly

Domain Controllers OU

Event log

ongoing

Monthly

Service Administrators OU

Event log

ongoing

Monthly

Operations Master role holders

Event log

ongoing

Monthly

Replication topology

Event log

ongoing

Monthly

Database characteristics

Automatic
report

Daily

None

Service packs and hotfixes for domain

controllers and administrative workstations

Automatic
report

Weekly

None

System state for domain controllers and

administrative workstations

Automatic
report

Daily

None

Current backup media exists

Manual
report

Weekly

None

Directory backup media can restore domain Manual

controllers
report

Quarterly

None

Audits of individuals with service

administrator credentials

Quarterly

Quarterly

Manual
report

Recommendations: Maintaining Secure Active Directory Operations

Follow the security recommendations presented in this chapter to help maintain a high level
of security for Active Directory operations. In most instances, these recommendations apply
to intranet datacenter, extranet datacenter, and branch office scenarios. However, some of the
recommendations depend on the particular scenario. When the recommendations are scenario
specific, notes are included to direct you to the section where the recommendation is
discussed.
Maintaining Domain Controller and Administrative Workstation Security

The following table provides a checklist of recommendations for maintaining domain

controller and administrative workstation security.
Establishing Domain Controller Backup and Restore Strategies
Publish backup policies that specify which domain controllers are backed up, who backups
domain controllers, how frequently they are backed up, and how backup media is handled.
Create a separate backup account for domain controllers requiring service administrative
privileges
Store domain controller backup media in a secure location.

Consider backing up branch office domain controllers from media stored locally on disk.

Check backup media weekly for suitability.

Protect the Backup Operators group with special security descriptor settings.

Regularly verify that domain controller backup media is good by performing a data restore.

Practice performing a forest recovery yearly.

Managing the Life Cycle of Domain Controller Hardware
Follow recommendations for recycling domain controller hardware and media.
Running Antivirus Software on Domain Controllers and Administrative Workstation
Run regular virus scans on domain controllers and administrative workstations.

Exclude certain Active Directory database and log files from virus scanning.

Exclude the SYSVOL directory tree from virus scanning.

Requiring script signing on domain controllers and administrative workstations.

Staying Current with Security Hotfixes and Service Packs

The following table provides a checklist of recommendations for staying current with security
hotfixes and service packs.
Selecting a Security Update Strategy
If you have a small organization that allows Internet access to servers consider
implementing WUS.
If you currently have a solution that distributes security updates continue using the current
solution.
If you currently have SMS and need a patch-management solution implement SMS patch
extension.
If you do not have SMS implement SMS, SUS, or a third-party solution for patch
management.
Deploying Security Hotfixes and Service Packs
Select a method for security hotfix notification, distribution, and auditing.
Check operating systems weekly to ensure that current service pack and hotfix upgrades
have been applied
Managing Forest-wide Configuration Settings
The following table provides a checklist of recommendations for managing forest-wide
configuration settings.
Managing Forest-Wide Configuration Settings
Reduce the MaxQueryDuration value to 30 seconds with the NTDSUTIL tool.
If applications running on the computer no longer work, try increasing the
MaxQueryDuration value
Managing Service Administrator Account Security

The following table provides a checklist of recommendations for managing service

administrator account security.
Performing Periodic Audit Checks on Service Administrators
Ensure that service administrators are familiar with your organizations security policies.

Perform periodic background checks of service administrator trustworthiness.

Periodically check service administrator group memberships

Periodically check for the proper delegation of service administrator rights.

Managing Administrative Passwords and the Logon Process
Require smart cards on service administrator-level accounts

Implement a split password for the most sensitive administrator accounts.

Maintain a list of DS Restore mode passwords in a secure location.

Limit the number of administrators that have access to DS Restore mode passwords.
Maintaining Up to Date Baseline Information
The following table provides a checklist of recommendations for documenting baselin
information.
Maintaining a Database of Baseline Information
Document baseline information about Domain controllers and administrative workstations.
Update the baseline information listed in Table 9 at the frequency also provided in Table
10.
Top of page

Chapter 2 - Monitoring the Active Directory Infrastructure

The monitoring (or health-checking) process gathers information about the security state of
the Active Directory directory service infrastructure, which includes the directory database,
domain controllers, and administrative workstations for service administrators. To monitor
your Active Directory infrastructure, perform the following tasks
1. Collect information in real time or at specified time intervals.
2. Compare this data with previous data or against a threshold value.
3. Respond to a security alert as directed in your organizations practices.
4. Summarize security monitoring in one or more regularly scheduled reports.
Small organizations can manually handle security monitoring for Active Directory, but a large
organization requires special monitoring software to collect and interpret this status. The
complexity of Active Directory in a large organization makes manually collecting and
reviewing security status practically impossible. In addition, a large organization has
numerous domain controllers and administrative workstations, which can best be supported
by compiling status in a common database. After the information is centralized, you can
review the security status of Active Directory as a whole.
Note: To provide comprehensive monitoring of Active Directory, all domain controllers and
administrative workstations must be monitored. Any unmonitored computer represents a
weakness in ensuring that Active Directory stays secure.
The monitoring described here is for the purpose of detecting security-sensitive
configurations and not for the purpose of detecting intrusions. To detect intrusions, you need
to provide additional auditing and monitoring.
The types of monitoring to perform to detect security-sensitive configurations include the
following:

Event notification
With event notification, you define thresholds for changes in the directory service,
domain controller configuration, or other Active Directory infrastructure
characteristics. When one of these characteristics changes enough to exceed the
threshold, an event notification is generated, indicating a potential security breach.
For example, you can configure Active Directory and Microsoft Windows 2000
Server to generate an entry in the security event log when changes are made to the site
or subnet configuration in Active Directory. This software collects your monitoring
information, including event log entries and performance counters, and then reports
the events to operations console.

Trend analysis

With trend analysis, you collect information as a number of data points that are only
meaningful when they are examined over a period of time. Drastic changes in trends
can indicate a potential security breach.
For example, you can collect status on available disk space every 15 minutes and
determine if there is a steady increase in disk space usage. Over a period of time, you
can analyze the trend in use of disk space to determine if a domain controller is under
a potential disk space attack.
Monitor your Active Directory infrastructure by performing the following tasks:
1. Monitor changes to Active Directory.
2. Monitor changes in domain controller status.
3. Monitor changes in system state and executables.
Monitoring Changes to Active Directory

Active Directory is an integral component in a domains security mechanism. A big part of

securing Active Directory installations is monitoring security-sensitive changes to Active
Directory containers and objects. The security auditing recommendations presented in
Establishing Secure Domain Controller Policy Settings in Securing Active Directory
Installations and Day-to-Day Operations: Part I establishes audit settings for securitysensitive administration tasks and must be in place for you to monitor changes to Active
Directory.
Note: Ensure that you detect changes in the Active Directory containers and objects within
one hour after the change occurs.
Throughout this section, security-sensitive entries in the event logs are described. Because
each Active Directory infrastructure contains unique information, any information that is
unique has been converted to a variable. Table 11 lists the variables that are used in every
table in this section. In addition to these variables, there are event-specific variables that are
described in the discussion of an event.
Table 11 Variables Used In Monitoring Active Directory Events
Variable

Description

<username>

Unless otherwise noted, this variable indicates the user who performed the
operation.

<computername>

Unless otherwise noted, this variable indicates the domain controller where
the operation was performed.

<domain>

This variable indicates the domain where the operation was performed. For
example DC=corp,DC=contoso,DC=com

Monitor changes to Active Directory containers and objects by performing the following
tasks:
1. Monitor forest-level changes.
2. Monitor domain-level changes.
3. Monitor changes in the Service Administrators OU.
4. Monitor changes to the disk space consumed by Active Directory objects.
Monitoring Forest-Level Changes
Forest-level changes in Active Directory have the broadest scope of any administrative
operations, and as such they represent a large security attack surface. Forest-wide
configuration changes include the following:

Changes in the schema

Promotion or demotion of domain controllers, especially global catalog servers

Changes in replication topology, including changes in sites and subnets

Changes in policies for Lightweight Directory Access Protocol (LDAP)

Changes in the dSHeuristics attribute

Changes in forest-wide operations master roles

Detecting Changes in the Schema

The Active Directory schema defines the structure of the directory service database. All
object classes and attributes are defined in the Active Directory schema. Unauthorized
changes in the schema pose a security threat, because an attacker can create, deactivate, or
modify object class and attribute definitions. You cannot delete an object class or attribute,
you can only deactivate an object class or attribute. Modifying an object class or attribute in
the schema can disrupt Active Directory and cause denial of service for all computers and
users that depend on Active Directory.
Detection
You can detect when a schema class or attribute is created, deleted, or modified by scanning
the aggregated security event logs from all domain controllers for the event criteria that are
specified in Table 12. The event fields that are common to all event actions (creations,
deactivation, or modifications) are show in the first section of Table 12. The additional event
fields for identifying each type of event action is shown in the remaining sections of Table 12.
The following variables are used in Table 12:

<objecttype> can have one of following values:

attributeSchema - indicates that the event references a schema attribute.

classSchema - indicates that the event references a schema class.

<attributeclassname> indicates the name of the class or attribute that is modified.

<propertychanged> indicates the name of the property that is modified.

Table 12 Detecting Creations, Deletions, or Modifications in the Schema

Event field

Relevant values
Common Fields For All Schema Events

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Schema Object Creation Event
Object Server: DS
Object Type: <objecttype>

Description:

Object Name: CN=Schema,CN=Configuration,DC=<domain>

Accesses: Create Child
Additional Fields For Schema Object Deactivation Event
Object Server: DS
Object Type: <objecttype>
Object Name:
CN=<attributeclassname>,CN=Schema,CN=Configuration,DC=<domain>

Description:
Accesses: Write Property
Properties: Write Property
?isDefunct

Additional Fields For Schema Object Modification Event

Object Server: DS
Object Type: <objecttype>
Object Name:
CN=<attributeclassname>,CN=Schema,CN=Configuration,DC=<domain>
Description:
Accesses: Write Property
Properties: Write Property
?<propertychanged>
Response
For creation and deactivation events, there is no method for determining the schema class or
attribute that is created or deactivated. You need to compare existing classes and attributes
with your documented list of valid classes and attributes, discussed in Maintaining Up to
Date Baseline Information in Chapter 1, in this document.
The unauthorized modification of the Active Directory schema requires you to manually
restore changes to the schema when the unauthorized schema modifications do not prevent
service administrators from logging on. When service administrators are unable to log on,
you must do a complete recovery of the forest. For more information about how to perform a
recovery of the entire forest, see Recovering from Catastrophic Forest-wide Corruption in
Chapter 3 of this guide.
Identifying When Domain Controllers Are Promoted or Demoted
The unauthorized promotion or demotion of domain controllers to and from the Active
Directory infrastructure represents a serious compromise of Active Directory. An attacker can
introduce a new, rogue domain controller to disrupt normal operations or to obtain a copy of
the Active Directory database for the purposes of discovering passwords and other secure
information that is stored in Active Directory. In addition, an attacker might remove a domain
controller for the purposes of discovering the passwords of service administrator accounts.
Important: Give global catalog servers a higher priority in monitoring, because global
catalog servers contain a complete copy of the Active Directory database, and as such they
represent a large attack surface.
Detection
You can detect when a domain controller is promoted or demoted by scanning the aggregated
security audit event logs from all domain controllers for the event criteria that are specified in
Table 13. The event fields that are common to all event actions (promotions, or demotions)
are show in the first section of Table 13. The unique event fields for identifying each type of
event action is shown in the remaining sections of Table 13.

Table 13 Detecting the Promotion or Demotion of a Domain Controller

Event field

Relevant values
Common Fields For Domain Controller Promotion or Demotion Events

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Domain Controller Promotion Events
Object Server: DS
Object Type: Computer

Description:

Object Name: OU=Domain Controllers,DC=<domain>

Accesses: Create Child
Additional Fields For Domain Controller Demotion Events
Object Server: DS
Object Type: Computer

Description:

Object Name: OU=Domain Controllers,DC=<domain>

Accesses: Delete Child

For domain controller promotions and demotions, you can identify the domain controller that
is promoted or demoted by looking for the event listed in Table 14. The event listed in Table
14 occurs very close in the time, and on the same domain controller, to the event in Table 13
happened. <newdomaincontroller> is the name of the newly promoted or demoted domain
controller.
Table 14 Identifying the Domain Controller That Is Promoted or Demoted
Event field

Relevant values

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Object Server: DS
Object Type: Computer

Description: Object Name: CN=<newdomaincontroller>,OU=Domain

Controllers,DC=<domain>
Accesses: Write Property
Response
The unauthorized promotion or demotion of a domain controller requires you to take further
steps to ensure that the security of Active Directory is not further compromised. For more
information on how to respond to the unauthorized promotion or demotion of a domain
controller, see Recovering from the Physical Breach of a Domain Controller in Chapter 3
of this guide
Detecting Changes in the Replication Topology
Changes in replication topology include the addition or removal of Active Directory sites,
subnets, and site links. An attacker can change the replication topology to:

Disrupt the replication of Active Directory.

The sites and subnet to which domain controllers belong determine the Active
Directory replication topology. An attacker can change the sites to which domain
controllers belong and convince domain controllers, which are connected by slowspeed network segments, that they are in the same site and have high-speed network
connectivity. This can potentially saturate the network utilization of the slow-speed
network segments and prevent domain controllers from receiving timely updates.

Degrade performance by directing client traffic over slow-speed network segments or

overloading a targeted number of domain controllers.
Client computers determine the domain controller to use for servicing Active
Directory queries based on the subnets to which the domain controllers and the clients
belong. An attacker can change the sites and subnets to which the domain controllers

belong and convince the clients that a domain controller across a slow-speed network
segment is the appropriate domain controller to use.
An attacker can also change the sites and subnets to convince a large number of clients that
the same domain controller is the appropriate domain controller to use and saturate the
domain controller with client requests.
Detection
You can detect when sites, subnets, site links, and connections are created, deleted, or
modified by scanning the aggregated security audit event logs from all domain controllers for
the event criteria that are specified in Table 15 for sites, Table 16 for subnets, Table 17 for site
links, and Table 18 for connections. The event fields that are common to all event actions
(creation, deletion, or modification) of sites, subnets, site links, and connections are show in
the first section of Table 15, Table 16, Table 17, and Table 18. The unique event fields for
identifying each type of event action is shown in the remaining sections of Table 15, Table
16, Table 17, and Table 18.
<sitename> is the name of the site that is modified. <subnetname> in Table 16 is the name of
the subnet that is modified. <transporttype> in Table 17 is the type of transport for the site
link and can either be IP or SMPT. <sitelinkname> in Table 17 is the name of the site link that
is being modified. <connectionname> in Table 18 is the name of the connection that is being
modified. <servername> is the name of the server that contains the connection.
<modifiedproperties> is name of the properties that are modified.
Table 15 Detecting the Creation, Deletion, or Modification of Sites
Event field

Relevant values
Common Fields For Site Creation, Deletion, or Modification Events

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Site Creation Events
Object Server: DS

Description:
Object Type: Computer

Object Name: CN=Sites,CN=Configuration,DC=<domain>

Accesses: Create Child
Additional Fields For Site Deletion Events
Object Server: DS
Object Type: site
Description:

Object Name: CN=Sites,CN=Configuration,DC=<domain>

Accesses: Delete Child
Additional Fields For Site Modification Events
Object Server: DS
Object Type: site
Object Name: CN=<sitename>,Sites,CN=Configuration,DC=<domain>

Description:

Accesses: Write Property

Properties: Write Property
< modifiedproperties >

Table 16 Detecting the Creation, Deletion, or Modification of Subnets

Event field

Relevant values
Common Fields For Subnet Creation, Deletion, or Modification Events

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Subnet Creation Events

Object Server: DS
Object Type: %{00000000-0000-0000-0000-000000000000}
Object Name: CN=Subnets,CN=Sites,CN=Configuration,DC=<domain>
Description:

Accesses: Create Child

Properties: Create Child
subnet
Additional Fields For Subnet Deletion Events
Object Server: DS
Object Type: Subnet

Description:

Object Name: CN=Subnets,CN=Sites,CN=Configuration,DC=<domain>

Accesses: Delete Child
Additional Fields For Subnet Modification Events
Object Server: DS
Object Type: Subnet
Object Name: CN=<subnetname>,CN=Subnets,CN=Sites,CN=Configuration,
DC=<domain>

Description:
Accesses: Write Property
Properties: Write Property
< modifiedproperties >
Table 17 Detecting the Creation, Deletion, or Modification of Site Links
Event field

Relevant values
Common Fields For Site Link Creation, Deletion, or Modification Events

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Site Link Creation Events
Object Server: DS
Object Type: siteLink

Description: Object Name: CN=<transporttype>,CN=Inter-Site Transports,CN=Sites,

CN=Configuration,DC=<domain>
Accesses: Create Child
Additional Fields For Site Link Deletion Events
Object Server: DS
Object Type: siteLink
Description: Object Name: CN=<transporttype>,CN=Inter-Site Transports,CN=Sites,
CN=Configuration,DC=<domain>
Accesses: Delete Child
Additional Fields For Site Link Modification Events
Object Server: DS
Object Type: siteLink
Object Name: CN=<sitelinkname>,CN=<transporttype>,CN=Inter-Site
Transports, CN=Sites, CN=Configuration,DC=<domain>
Description:
Accesses: Write Property
Properties: Write Property
< modifiedproperties >
Table 18 Detecting the Creation, Deletion, or Modification of Connections
Event field

Relevant values
Common Fields For Connection Creation, Deletion, or Modification Events

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Connection Creation Events
Object Server: DS
Object Type: nTDSConnection

Description:

Object Name: CN=NTDS

Settings,CN=<servername>,CN=Servers,CN=<sitename>,
CN=Sites,CN=Configuration,DC=<domain>
Accesses: Create Child
Additional Fields For Connection Deletion Events
Object Server: DS
Object Type: nTDSConnection

Description:

Object Name: CN=NTDS

Settings,CN=<servername>,CN=Servers,CN=<sitename>,
CN=Sites,CN=Configuration,DC=<domain>
Accesses: Delete Child
Additional Fields For Connection Modification Events
Object Server: DS
Object Type: nTDSConnection
Object Name: CN=<connectionname>,CN=NTDS Settings,CN=<servername>,
CN=Servers,CN=<sitename>,CN=Sites,CN=Configuration,DC=<domain>

Description:
Accesses: Write Property
Properties: Write Property
< modifiedproperties >
Response

The unauthorized modification of replication topology requires you to perform an

authoritative restore of the forest configuration from a known good backup. To restore the
replication topology, you need to restore CN=Sites, CN=Configuration,
DC=<ForestRootDomain> in the configuration directory partition. For more information
about how perform an authoritative restore of the replication topology, see Recovering from
Data Tampering by Restoring Active Directory Data in Chapter 3 of this guide.
You can also restore the replication topology manually. In Maintaining Up to Date Baseline
Information in Chapter 1, of this guide, you documented the replication topology. Use this
documentation to manually restore the configuration of the replication topology.
Detecting Changes in LDAP Policies
LDAP policies impose limits on LDAP queries that prevent specific operations from
adversely affecting the performance of domain controllers, making it easier for domain
controllers to resist denial-of-service attacks. LDAP policies are implemented through the use
of objects of the queryPolicy class. You can create these objects can be created in the Query
Policies container, which is a child of the directory service container in the configuration
naming context.
Detection
You can detect modifications to LDAP policies by scanning the aggregated security event
logs from all domain controllers for the event criteria that are specified in Table 19.
Table 19 Detecting the Modification of LDAP Policies
Event field

Relevant values

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Object Server: DS

Description:
Object Type: queryPolicy
Object Name: CN=Default Query Policy,CN=Query-Policies,CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration, DC=<domain>

Accesses: Write Property

Properties: Write Property
lDAPAdminLimits
Response
The unauthorized modification of LDAP policies requires you to perform an authoritative
restore of the policies from a known good backup. To restore LDAP policies, you need to
restore the object CN=Default Query Policy, CN=Directory Service, CN=Windows NT,
CN=Configuration, DC=<ForestRootDomain>in the configuration directory partition. For
more information about how perform an authoritative restore of the LDAP policies, see
Recovering from Data Tampering by Restoring Active Directory Data in Chapter 3 of this
guide.
Detecting Changes in the dSHeuristics Attribute
The dSHeuristics attribute affects the behavior of various characteristics of the directory
service, such as the ability to enable List Object functionality or the suppression of first/last
name functionality in Ambiguous Name Resolution (ANR). dSHeuristics can affect the
performance of domain controllers, and it can also make domain controllers resistant to
denial-of-service attacks. Unauthorized changes to the dSHeuristics attribute can indicate an
attempt to breach Active Directory security.
Detection
You can detect modification to the dSHeuristics attribute by scanning the aggregated security
event logs from all domain controllers for event entries that have the fields listed in Table 20.
Table 20 Detecting the Modification to dSHeuristics
Event field

Relevant values

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Object Server: DS

Description:

Object Type: nTDSService

Object Name: CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration, DC=<domain>
Accesses: Write Property
Properties: Write Property
dSHeuristics
Response
The unauthorized modification of dSHueristics attribute requires you to perform an
authoritative restore of the dSHueristics from a known good backup. To restore the
dSHueristics attribute, you need to restore object CN=Directory Service, CN=Windows NT,
CN=Services, CN=Configuration, DC=<ForestRootDomain> in the configuration directory
partition. For more information about how perform an authoritative restore of the
dSHueristics attribute, see Recovering from Data Tampering by Restoring Active Directory
Data in Chapter 3 of this guide.
Detecting Changes in Forest-wide Operations Master Roles
Changes in forest-wide operations master roles (also known as flexible single master
operations, or FSMO) are important to security because they affect the entire forest. Forestwide operations master roles include the following:

Schema master

Domain naming master

Because forest-wide operations master roles are assigned to specific computers, any
unauthorized change in the operations master roles can be an indication of a breach in Active
Directory security.
Detection
You can detect changes in forest-wide operations master roles by scanning the aggregated
security audit event logs from all domain controllers for the event criteria that are specified in
Table 21. The event fields that are common to all event actions (changes in schema master or
domain naming master roles) are show in the first section of Table 21. The additional event
fields for identifying the individual forest-wide operations master roles is shown in the
remaining sections of Table 21. In the case of changes in forest-wide operations master roles,
<computername> is the name of the domain controller which currently holds the operations
master role.
Table 21 Detecting Changes in the Forest-wide Operations Master Roles

Event field

Relevant values
Common Fields For Changes in Forest-wide Operations Master Roles

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Changes in Schema Master Role
Object Server: DS
Object Type: dMD
Object Name: CN=Schema,CN=Configuration,DC=<domain>

Description:

Accesses: Control Access

Properties: Control Access
Change Schema Master
Additional Fields For Changes in Domain Naming Master Role
Object Server: DS
Object Type: crossRefContainer
Object Name: CN= Partitions,CN=Configuration,DC=<domain>

Description:

Accesses: Control Access

Properties: Control Access
Change Domain Master

Response
When you detect unauthorized changes in forest-wide operations master roles, immediately
transfer back, or if necessary seize, the forest-wide operations master roles to the
configuration that you have documented. Documenting forest-wide operations master roles is

discussed in Documenting and Updating Baseline Information in Chapter 1. For more

information about transferring or seizing operations master roles, see Transferring
Operations Master Roles and Seizing Operations Master Roles in the Microsoft Windows
2000 Active Directory Operations Guide at:
http://www.microsoft.com/windows2000/techinfo/administration/activedirectory/adops.asp.
Monitoring Domain-Level Changes
Changes in Active Directory domains affect all users, workstations, member servers, and
domain controllers in the domains, and as such they represent a large security attack surface.
These domain-wide configuration changes include the following:

Changes in domain-wide operations master roles

Changes in trusts

Changes in permissions for Administrators and Domain Admins through modification

of AdminSDHolder

Changes in the GPOs for the Domain container and the Domain Controllers OU.

Changes in the GPO assignments for the Domain container and the Domain
Controllers OU.

Changes in the membership of built-in groups, such as Administrators and Backup

Operators

Changes to the audit policy settings for the domain.

Detecting Changes in Domain-wide Operations Master Roles

Changes in domain-wide operation master roles are critical to security because they affect the
entire domain. Domain-wide operation master roles include the following:

Relative ID (RID) master

Primary domain controller (PDC) emulator master

Infrastructure master

Because domain-wide operations master roles are assigned to specific computers, any
unauthorized change in the operations master roles indicates a breach in Active Directory
security.
Detection
You can detect changes in domain-wide operations master roles by scanning the aggregated
security audit event logs from all domain controllers for the event criteria that are specified in
Table 22. The event fields that are common to all event actions (changes in RID master, PDC
emulator master, or infrastructure master roles) are show in the first section of Table 22. The
additional event fields for identifying the individual domain-wide operations master roles is
shown in the remaining sections of Table 22. In the case of changes in domain-wide

operations master roles, <computername> is the name of the domain controller which
currently holds the operations master role.
Table 22 Detecting Changes in the Domain-wide Operations Master Roles
Event field

Relevant values
Common Fields For Changes in Domain-wide Operations Master Roles

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Changes in RID Master Role
Object Server: DS
Object Type: rIDManager
Object Name: CN= RID Manager $,CN=Configuration,DC=<domain>

Description:

Accesses: Control Access

Properties: Control Access
Change RID Master
Additional Fields For Changes in PDC Emulator Master Role
Object Server: DS
Object Type: domainDNS
Object Name: DC=<domain>

Description:

Accesses: Control Access

Properties: Control Access
Change PDC

Additional Fields For Changes in Infrastructure Master Role

Object Server: DS
Object Type: infrastructureUpdate
Object Name: CN= Infrastructure,DC=<domain>
Description:

Accesses: Control Access

Properties: Control Access
Change Infrastructure Master

Response
When you detect changes in domain-wide operations master roles, immediately restore the
domain-wide operations master roles to their original configuration. Documenting your
domain-wide operations master roles is discussed in Documenting and Updating Baseline
Information in Chapter 1. For more information about transferring or seizing operations
master roles, see Transferring Operations Master Roles and Seizing Operations Master
Roles in the Microsoft Windows 2000 Active Directory Operations Guide at:
http://www.microsoft.com/windows2000/techinfo/administration/activedirectory/adops.asp.
Detecting Changes in Trusts
Any changes in domain trusts can cause domain-wide disruptions in Active Directory. User
access to resources in one domain may depend on a trust to another domain where the users
account resides. Breaking the trust between these domains prevents users in one domain from
accessing resources in the other domain. The addition of an authorized trust can indicate a
breach in Active Directory security.
Detection
You can detect changes in domain trusts by scanning the aggregated security audit event logs
from all domain controllers for the event criteria that are specified in Table 23. The event
fields that are common to all event actions (creation or removal of a trust) are show in the
first section of Table 23. The additional event fields for identifying fields that uniquely
identify a creation or removal of a trust are shown in the remaining sections of Table 23.
<trusting/trusteddomain> in Table 23 is the name of the trusted or trusting domain created or
removed.
Table 23 Detecting Changes in Domain Trusts
Event field

Relevant values
Common Fields For Changes in Domain Trusts

Source

Security

Category

Policy Change

Type

Success

User

<username>

Computer

<computername>
Additional Fields For Creating A Domain Trust

Event ID

610

Description: Domain Name: <trusting/trusteddomain>

Additional Fields For Removing a Domain Trust
Event IDI

611

Description: Domain Name: <trusting/trusteddomain>

Response
If you detect unauthorized changes to domain trusts, restore the original trust relationships
between the affected domain and other domains. To restore the original trust relationships,
you would consult to your organizations documentation for authorized trust relationships in
Documenting and Updating Baseline Information in Chapter 1. Use this documentation to
rebuild the trusts manually. For more information about how to configure domain trusts, see
Creating External Trusts in the Microsoft Windows 2000 Active Directory Operations
Guide at:
http://www.microsoft.com/windows2000/techinfo/administration/activedirectory/adops.asp
Detecting Changes in AdminSDHolder
Active Directory contains a mechanism to protect user accounts and groups that are members
of service administrator groups. Every hour, the domain controller that holds the PDC
emulator operations master role in the domain checks that the DACLs of these user accounts
are identical to the permission list of a special AdminSDHolder object. The PDC emulator
modifies any differing permission list, so that it is again identical to the permission list of
AdminSDHolder.
Because any changes in the permission list for the AdminSDHolder object are applied to the
members of the service administrator groups, changes to the AdminSDHolder object
represent a significant security risk.
Detection

You can detect modification to the security descriptor of the AdminSDHolder object by
scanning the aggregated security event logs from all domain controllers for event entries that
have the fields listed in Table 24.
Table 24 Detecting the Modification to AdminSDHolder Object
Event field

Relevant values

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Object Server: DS
Object Type: container

Description:

Object Name: CN= AdminSDHolder,CN=System,DC=<domain>

Accesses: Write DAC

Response
If you detect unauthorized changes to the AdminSDHolder object, restore the
AdminsSDHolder object. To restore the AdminSDHolder object, you need to restore
CN=AdminSDHolder, CN=System, DC=<DomainName>in the domain directory partition.
For more information about how perform an authoritative restore of the AdminSDHolder
object, see Recovering from Data Tampering by Restoring Active Directory Data in
Chapter 3 of this guide.
Detecting Changes in Group Policy Security Settings
The information for creating or modifying Group Policy objects (GPOs) to configure the
security settings on domains and domain controllers is presented in Establishing Secure
Domain Controller Policy Settings in Chapter 4, in Part I. These security settings affect the
entire domain and all domain controllers in the domain. Any unauthorized changes to these
security settings could compromise the security of the domain. For example, an attacker
might change the number of failed attempts before an account is locked in a group policy to
make determining passwords easier.
Detection

You can detect changes in GPOs by scanning the aggregated security audit event logs from
all domain controllers for the event criteria that are specified in Table 25. The event fields
that are common to all event actions (creation, deletion, or modification) are show in the first
section of Table 25. The additional event fields for identifying the individual actions are
shown in the remaining sections of Table 25. <modificationaccess> in Table 25 can be any
type of access that modifies the GPO, such as Write Property. In the modification event,
<guid> is the GUID for the GPO that is modified.
Table 25 Detecting Changes in the GPOs
Event field

Relevant values
Common Fields For Changes in GPOs

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Creation of GPOs
Object Server: DS
Object Type: groupPolicyContainer

Description:

Object Name: CN=Policies,CN=System,DC=<domain>

Accesses: Create Child
Additional Fields For Deletion of GPOs
Object Server: DS
Object Type: groupPolicyContainer

Description:

Object Name: CN=Policies,CN=System,DC=<domain>

Accesses: Delete Child
Additional Fields For Modification of GPOs
Object Server: DS

Description:

Object Type: groupPolicyContainer

Object Name: CN=<guid>,CN=Policies,CN=System,DC=<domain>
Accesses: <modificationaccess>
You can determine the friendly name of the GPO that was modified by from the <guid> in the
description. The friendly name is the name that you see in a console such as Active Directory
Users and Computers. For more information about converting the <guid> of a GPO to the
friendly name of the GPO, see Converting the GUID of a GPO to a Friendly Name in
Appendix B: Deployment Procedures in this document.
Response
If you detect unauthorized changes to the GPOs, restore the security settings to their previous
configuration. To restore the group policy security settings, you need to restore the
CN=Policies, CN=System, DC=<domain> in the domain directory partition. For more
information about how perform an authoritative restore of the group policy security settings,
see Recovering from Data Tampering by Restoring Active Directory Data in Chapter 3 of
this guide.
You can also restore the GPOs manually. In Maintaining Up to Date Baseline Information
in Chapter 1, in this document, you documented the GPOs. Use this documentation to
manually restore the configuration of the GPOs.
Detecting Changes in GPO Assignments for the Domain Container and Domain
Controllers OU
In addition to monitoring for changes in the GPOs, monitor for changes in the assignment of
the GPO to a container within Active Directory. A change in the GPO assignment affects only
the container where the assignment is made. AGPO can be assigned to one or more
containers.
In Establishing Secure Domain Controller Policy Settings in Chapter 4, in Part I of this
guide, GPOs were created and assigned to the Domain and to the Domain Controllers OU.
Monitor for changes to the GPO assignments on both the Domain container and Domain
Controllers OU.
Detection
You can detect changes in GPO assignments on the Domain container and the Domain
Controllers OU by scanning the aggregated security audit event logs from all domain
controllers for the event criteria that are specified in Table 26. The event fields that are
common to all event actions (modifications to GPO assignments on the Domain container or
the Domain Controllers OU) are show in the first section of Table 26. The additional event
fields for identifying the Domain container or Domain Controllers OU are shown in the
remaining sections of Table 26.
Table 26 Detecting Changes in the GPO Assignments

Event field

Relevant values
Common Fields For Changes in GPO Assignments

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Modification of GPO Assignments to Domain
Container
Object Server: DS
Object Type: domainDNS
Object Name: DC=<domain>

Description:

Accesses: Write Property

Properties: Write Property
gPLink
gPOptions
Additional Fields For Modification of GPO Assignments to Domain
Controllers OU
Object Server: DS
Object Type: organizationalUnit
Object Name: OU=DomainControllers,DC=<domain>

Description:

Accesses: Write Property

Properties: Write Property
gPLink
gPOptions

Response
If you detect unauthorized changes to the GPO assignments in the controlled OU subtree,
restore the security settings to their previous configuration. To restore the GPO assignments
for the Domain container, you need to restore DC=<domain> in the domain directory
partition. To restore the GPO assignments for the Domain Controllers OU, you need to
restore OU=Domain Controllers,DC=<domain> in the domain directory partition. For more
information about how perform an authoritative restore of GPO assignments, see
Recovering from Data Tampering by Restoring Active Directory Data in Chapter 3, in this
document.
You can also restore the GPO assignments for the Domain container and the Domain
Controllers OU manually. In Maintaining Up to Date Baseline Information in Chapter 1, in
this document, you documented the GPO assignments for the Domain container and the
Domain Controllers OU. Use this documentation to manually restore the configuration of the
GPO assignments.
In addition, any unauthorized changes in the GPO assignments for the Domain container or
the Domain Controllers OU can indicate the existence of a rogue administrator account. For
more information about how to recover from a rogue administrator attack, see Recovering
from a Rogue Administrator Attack in Chapter 3 of this guide.
Detecting Changes in the Membership of Built-in Groups
The information for creating an organizational unit (OU) subtree for controlling the group
policy settings and administration of the service administrators and administrative
workstations is in Establishing Secure Service Administrator Practices in Chapter 4, in Part
I of this guide. However, the built-in service administrator groups, such as Administrators and
Backup Operators, cannot be moved to the controlled OU subtree. You need to detect any
changes in the group membership of these built-in groups. Any unauthorized changes to these
groups can compromise the security of the domain.
Detection
You can detect changes in the membership of the built-in groups by scanning the aggregated
security event logs from all domain controllers for the event criteria that are specified in
Table 27. <accountaddedremoved> is the name of the account that was added or removed
from one of the built-in groups. <group> is the name of the built-in group that was modified.
Table 27 Detecting Changes in the Membership of Built-in Groups
Event field

Relevant values

Source

Security

Category

Account Management

Type

Success

Event ID

636

User

<username>

Computer

<computername>
Member Name: <accountaddedremoved>

Description:

Target Domain: Builtin

Target Account ID: BUILTIN\<group>

Response
If you detect unauthorized changes in the group membership of built-in groups, immediately
restore the built-in group membership to the original list of members. Documenting your
built-in group membership is discussed in Documenting and Updating Baseline
Information in Chapter 1. For more information about changing group membership, see
Manage groups in Windows 2000 Server Help.
In addition, any unauthorized changes in the group membership of the built-in groups can
indicate the creation of a rogue administrator account. For more information about how to
recover from a rogue administrator attack, see Recovering from a Rogue Administrator
Attack in Chapter 3 of this guide.
Detecting Changes in the Audit Policy Settings for the Domain Controllers OU
The audit policy settings for the Domain Controllers OU affect your notification of securityrelated events. As a result, any change in the audit policy can affect the notifications you
receive and can also be an indication of a rogue administrator. The audit policies for receiving
notification of security-related events that affect the administration of Active Directory were
discussed in Establishing Domain Controller Audit Policy Settings in Chapter 4, in Part I.
Review the audit policy settings described there and use them as a baseline for your audit
policy settings.
Detection
You can detect changes in the audit policy settings for the domain by scanning the aggregated
security event logs from all domain controllers for the event criteria that are specified in
Table 28. You can identify the new Audit policy settings, <newpolicysettings>, by looking at
the Description event field.
Table 28 Detecting Changes in the Audit Policy Settings
Event field
Source

Relevant values
Security

Category

Account Management

Type

Success

Event ID

612

User

NT AUTHORITY\SYSTEM

Computer

<computername>
Audit Policy Change:

Description:

New Policy: <newpolicysettings>

The following is an example of how the new audit policy settings, <newpolicysettings>, are
displayed in the Description event field of event 612. A plus sign (+) indicates that the
corresponding success or failure of the event category is audited. A minus sign (-) indicates
the corresponding success or failure of the event category is not audited.
Audit Policy Change:
New Policy:
Success
Failure
+
Logon/Logoff
Object Access
+
+
Privilege Use
+
Account Management
+
Policy Change
+
System
Detailed Tracking
+
Directory Service Access
+
Account Logon

Note: When the Audit policy change policy is enabled for either success or failure in the
Default Domain Policy or Default Domain Controllers Policy group policy objects (GPO), a
success event, event 617, is logged in the Windows 2000 Security log regardless of whether
or not a policy change occurred. For more information about this behavior, see Microsoft
Knowledge Base Article - 272460 Information About Event 617 in the Security Event Log
at http://support.microsoft.com/?kbid=272460.
Response
If you detect unauthorized changes in the audit policy settings for the domain, immediately
restore the audit policies to their original settings. In Maintaining Up to Date Baseline
Information in Chapter 1, in this document, you documented the audit policy settings. Use
this documentation to manually restore the configuration of the audit policy settings.
In addition, any unauthorized changes in the audit policy settings can indicate the creation of
a rogue administrator account. For more information about how to recover from a rogue
administrator attack, see Recovering from a Rogue Administrator Attack in Chapter 3 of
this guide.

Monitoring Changes in the Service Administrators OU

The information for creating the Service Administrators OU is in Establishing Secure
Service Administration Practices in Chapter 5, in Part I, illustrated in Figure 6. Any changes
to the objects in the Service Administrators OU might indicate a possible security attack.

Figure 6: Placement of Service Administrators OU in a Domain

Monitor for the following changes in the Service Administrators OU:

Changes in service administrator accounts

Changes in GPOs for the controlled OU subtree

Changes in GPO assignments for the controlled OU subtree

Detecting Changes in Service Administrator Accounts

Any unauthorized changes to the service accounts in the Service Administrators OU can
indicate a potential attack, including the possible creation of a rogue service administrator
account. These changes include:

The creation, deletion, and modification of service administrator user and group
accounts in the Users and Groups OU.
The addition and deletion of computers in the Administrative Workstations OU.

Detection
Table 29 includes a section for the event fields that are common to all event actions (addition,
deletion, and modification) for the service administrator accounts stored in the Users and
Groups OU. The additional event fields for identifying types of action are shown in the
remaining sections of Table 29. <objecttype> in Table 29 can be either user or group,
depending on the object being created, deleted, or modified. <user/groupname> is the name
of the user or group that is modified. <changedattribute> is the attribute of the user or group
that is modified. <propertysetname> is the name of the property set of which the changed
attribute is a member.
Table 29 Detecting Changes to the Users and Groups OU

Event field

Relevant values
Common Fields For Changes to the Users and Groups OU

Source

Security

Category

Account Management

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Creations in the Users and Groups OU
Object Server: DS
Object Type: <objecttype>

Description: Object Name: OU=Users and Groups,OU=Service

Administrators,DC=<domain>
Accesses: Create Child
Additional Fields For Deletions in the Users and Groups OU
Object Server: DS
Object Type: <objecttype>
Description: Object Name: OU=Users and Groups,OU=Service
Administrators,DC=<domain>
Accesses: Delete Child
Additional Fields For Modifications to the Accounts in the Users and
Groups OU
Object Server: DS
Description:
Object Type: <objecttype>
Object Name: CN=<user/groupname>,OU=Users and Groups,
OU=Service Administrators, DC=<domain>
Accesses: Write Property

Properties: Write Property

<propertysetname>
<changedattribute>
To find the name of the account added or deleted in Table 29, look for events listed in Table
30. Table 30 includes a section for the event fields that are common to all event actions
(addition and deletion) for the service administrator accounts stored in the Users and Groups
OU. The additional event fields for identifying types of action are shown in the remaining
sections of Table 30. newusername> in Table 30 is the name of the account that is created.
<targetusername> in Table 30 is the name of the account that is removed.
Table 30 Identifying the Accounts Created or Deleted
Event field

Relevant values
Common Fields For Creations or Deletions in the Users and Groups OU

Source

Security

Category

Account Management

Type

Success

User

<username>

Computer

<computername>
Additional Fields For Creations in the Users and Groups OU

Event ID

624

Description: New Account Name: <newusername>

Additional Fields For Deletions in the Users and Groups OU
Event ID

630

Description: Target Account Name: <targetusername>

Table 31 includes a section for the event fields that are common to all event actions (addition
and deletions) for the Administrator Workstations OU. The additional event fields for
identifying types of action are shown in the remaining sections of Table 31. The Object Type
in Table 31 should only be computer. If an object type other than computer is created in the
Administrator Workstations OU, treat the object as a rogue object.

Table 31 Detecting Changes to the Administrator Workstations OU

Event field

Relevant values
Common Fields For Changes to the Administrator Workstations OU

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Additions to the Administrator Workstations OU
Object Server: DS
Object Type: computer

Description: Object Name: OU=Administrator Workstations,OU=Service

Administrators,DC=<domain>
Accesses: Create Child
Additional Fields For Deletions to the Administrator Workstations OU
Object Server: DS
Object Type: computer
Description: Object Name: OU=Administrator Workstations,OU=Service
Administrators,DC=<domain>
Accesses: Delete Child
Response
If you detect unauthorized changes in the service administrator accounts, immediately restore
the list of service administrators and group membership lists to the original list of members.
Documenting your service administrator accounts is discussed in Documenting and
Updating Baseline Information in Chapter 1.
In addition, any unauthorized changes in the service administrator accounts can indicate the
creation of a rogue administrator account. For more information about how to recover from a

rogue administrator attack, see Recovering from a Rogue Administrator Attack in Chapter
3 of this guide.
Detecting Changes in GPOs for the Service Administrators OU
The information for creating or modifying GPOs to configure the security settings on service
administrators and administrative workstations is presented in Establishing Secure Service
Administration Practices in Chapter 5, in Part I. These security settings affect the entire
controlled OU. Any unauthorized changes to these security settings could compromise the
security of the domain, because the service administrator accounts and secured workstations
are stored in this controlled OU.
Detection
You can detect changes in GPOs by scanning the aggregated security audit event logs from
all domain controllers for the event criteria that are specified in Table 32. The event fields
that are common to all event actions (creation, deletion, or modification) are show in the first
section of Table 32. The additional event fields for identifying the individual actions are
shown in the remaining sections of Table 32. <modificationaccess> in Table 32 can be any
type of access that modifies the GPO, such as Write Property. In the modification event,
<guid> is the GUID for the GPO that is modified.
Table 32 Detecting Changes in the GPOs
Event field

Relevant values
Common Fields For Changes in GPOs

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Additional Fields For Creation of GPOs
Object Server: DS
Object Type: groupPolicyContainer

Description:

Object Name: CN=Policies,CN=System,DC=<domain>

Accesses: Create Child

Additional Fields For Deletion of GPOs

Object Server: DS
Object Type: groupPolicyContainer
Description:

Object Name: CN=Policies,CN=System,DC=<domain>

Accesses: Delete Child
Additional Fields For Modification of GPOs
Object Server: DS
Object Type: groupPolicyContainer

Description:

Object Name: CN=<guid>,CN=Policies,CN=System,DC=<domain>

Accesses: <modificationaccess>

You can determine the friendly name of the GPO that was modified by from the <guid> in the
description. The friendly name is the name that you see in a console such as Active Directory
Users and Computers. For more information about converting the <guid> of a GPO to the
friendly name of the GPO, see Converting the GUID of a GPO to a Friendly Name in
Appendix B: Deployment Procedures in this document.
Response
If you detect unauthorized changes to the GPOs, restore the security settings to their previous
configuration. To restore the group policy security settings, you need to restore the
CN=Policies, CN=System, DC=<domain> in the domain directory partition. For more
information about how perform an authoritative restore of the group policy security settings,
see Recovering from Data Tampering by Restoring Active Directory Data in Chapter 3 of
this guide.
You can also restore the GPOs manually. In Maintaining Up to Date Baseline Information
in Chapter 1, in this document, you documented the GPOs. Use this documentation to
manually restore the configuration of the GPOs.
Detecting Changes in GPO Assignments for the Service Administrators OU
In addition to monitoring for changes in the GPOs, monitor for changes in the assignment of
the GPO to the Service Administrators OU. A change in the GPO assignment can indicate that
an attacker is attempting to weaken security-related group policy settings. Any unauthorized
changes to the GPO assignment in the Service Administrator OU can indicate a potential
attack and the possible existence of a rogue service administrator account.
Detection

You can detect changes in GPO assignments on the Service Administrators OU by scanning
the aggregated security audit event logs from all domain controllers for the event criteria that
are specified in Table 33.
Table 33 Detecting Changes in the GPO Assignments on the Service Administrators
Controlled OU
Event field

Relevant values

Source

Security

Category

Directory Service Access

Type

Success

Event ID

565

User

<username>

Computer

<computername>
Object Server: DS
Object Type: domainDNS
Object Name: OU=Service Administrators,DC=<domain>

Description:

Accesses: Write Property

Properties: Write Property
gPLink
gPOptions

Response
If you detect unauthorized changes to the GPO assignments in the Service Administrators
OU, restore the security settings to their previous configuration. To restore the GPO
assignments for the Service Administrators OU, you need to restore the OU=Service
Administrators, DC=<domain> in the domain directory partition. For more information about
how perform an authoritative restore of GPO assignments in the Service Administrator OU,
see Recovering from Data Tampering by Restoring Active Directory Data in Chapter 3, in
this document.
You can also restore the GPO assignments for the Service Administrator OU manually. In
Maintaining Up to Date Baseline Information in Chapter 1, in this document, you
documented the GPO assignments for the Service Administrators OU. Use this
documentation to manually restore the configuration of the GPO assignments.

In addition, any unauthorized changes in the GPO assignments for the Service Administrators
OU can indicate the existence of a rogue administrator account. For more information about
how to recover from a rogue administrator attack, see Recovering from a Rogue
Administrator Attack in Chapter 3 of this guide.
Monitoring for Disk Space Consumed by Active Directory Objects
One of many potential types of attacks is the creation of rogue objects or the modification of
existing objects in Active Directory and the resulting consumption of available disk space.
When the available disk space is exhausted, the Active Directory database is unable to be
enlarged for legitimate objects.
The types of Active Directory objects attacks that can be performed include the creation of:

A sufficiently large number of normal-sized objects, so that the objects consume the
available disk space, also known as a rogue object flood attack.
New objects or modification of existing objects, so that a limited number of
extraordinarily large-sized objects consume the available disk space, also known as a
large-sized object attack.

Monitoring for a Rogue Object Flood Attack

In this situation, the attacker creates an inordinately large number of normal-sized objects
over a period of time. The attacker can create the objects over a long or short period of time.
If you monitor objects over a long period of time, it can be difficult to determine which
objects are the rogue objects.
Detection
Detect a rogue object flood attack by performing the following tasks:
1. Create the ObjCountByClass.vbs script.
For more information about the ObjCountByClass.vbs script source and how to create
the script, see Monitoring the Number of Objects In a Domain in Appendix B:
Deployment Procedures in this document.
Note: This script requires Windows 2000 with Service Pack 3 or later and Windows
Scripting Host version 5.6 or later.
2. For each domain in the forest, run ObjCountByClass.vbs daily to collect the number
of each objects of each object class type in the domain.
You must run the ObjCountByClass.vbs script in the cscript environment from a
command line (or a batch file) by entering the following command:
cscript ObjCountByClass.vbs

Note: The ObjCountByClass.vbs script must be run in the cscript environment

because the Windows Scripting Host (WSH) environment does not support the
necessary objects.
3. Collect the data files created by ObjCountByClass.vbs into a database or spreadsheet
to enable trend analysis of object type counts in the domain.
The ObjCountByClass.vbs script creates a status file in comma-separated value (CSV)
format, named ObjectClassCount-date-time.csv, where date is the date the status file was
created and time is the time that the status file was created. You can import the status file into
Microsoft Excel or Microsoft Access for tracking historical trends and performing forensic
analysis.
Generate an alert when an inordinate number of objects, for a specific object type, are created
over a period of time.
Response
As an immediate response, delete the reserve file on the affected domain controllers to create
free disk space so that normal operation can be restored immediately. As a long-term
response, identify the rogue objects in Active Directory and then remove them. For more
information about how to respond and recover from a rogue object flood attack, see
Recovering from a Rogue Object Flood Attack in Chapter 3 of this guide.
Monitoring for a Large-sized Object Attack
In this situation, the attacker creates a limited number of objects, but each object is
extraordinarily large in size. These attacks tend to happen over a relatively short period of
time. Because the objects are large in size, only a few objects are required to consume the
available disk space.
Detection
Detect a large-sized object attack that consumes disk space by performing the following
tasks:
1. For each domain controller in the forest, create alerts in Performance Logs and Alerts
that detect when only 10 percent of free disk space is available on the disk volume
that contains the Active Directory database.
For more information about creating alerts to monitor available disk space, see
Monitoring Changes in Domain Controller Status later in this chapter.
2. For each domain in the forest, run ObjCountByClass.vbs daily to collect the number
of each objects of each object class type in the domain.
You must run the ObjCountByClass.vbs script in the cscript environment from a
command line (or a batch file) by entering the following command line and then
pressing ENTER:

cscript ObjCountByClass.vbs

When the size of the database is increasing significantly, but the number of objects is not
increasing proportional to the growth, then a limited number of large-sized objects are
consuming the database, and subsequently the available disk space.
Response
As an immediate response, delete the reserve file on the affected domain controllers to create
free disk space so that normal operation can be restored immediately. As a long-term
response, identify the rogue objects in Active Directory and then remove them. For more
information on how to respond and recover from a large-sized object attack, see Recovering
from an Object Growth Attack in Chapter 3 of this guide.
Monitoring Changes in Domain Controller Status

In addition to monitoring changes in Active Directory, monitor the domain controllers in your
Active Directory infrastructure. The overall health of Active Directory is only as good as the
cumulative health of the domain controllers in your organization.
The domain controllers deployment recommendations presented in Establishing Secure
Domain Controller Policy Settings in Securing Active Directory Installations and Day-toDay Operations: Part I help to ensure that the domain controllers are deployed in a secure
manner. Monitoring security-sensitive changes to the domain controller status helps to ensure
that the domain controllers stay secure.
Monitor changes to the domain controller status by performing the following tasks:
1. Monitor domain controller availability to ensure that domain controllers are active
and have not been restarted.
2. Monitor changes in domain controller performance counters for system resources.
Monitoring Domain Controller Availability
One of the primary reasons for ensuring that domain controllers are secure is to help
guarantee domain controller uptime. From a security perspective, availability can be affected
when an attacker removes a domain controller or performs denial-of-service attacks on a
domain controller. When a domain controller is unavailable, the security implication is that
the domain controller might be physically breached.
Detect when a domain controller is unavailable by performing the following tasks:
1. Monitor domain controllers to determine if the domain controllers are active.
2. Monitor the event log for domain controller restarts.
Monitoring Domain Controllers for Active Status
One of the best ways to verify that a domain controller is online and servicing client requests
is to send an LDAP query to the domain controller. By performing this query, you can
determine:

The active or inactive status of the domain controller, if the domain controller
responds.
The current utilization of the domain controller, by how quickly the domain controller
responds.

Detection
Most monitoring software provides the ability to periodically interrogate a computer and
determine if the computer is active and servicing requests. For example, Microsoft
Operations Manager has an Active Directory Management Pack that periodically queries a
domain controller to determine if the domain controller is online and servicing client
requests.
You can also determine if a domain controller is online and servicing client requests by
executing the following LDAP query:
'**************************************************************************
'* File:
DSPing.vbs
*
'* Created:
March 2003
*
'* Version:
1.0
*
'*
*
'* Description:
Diagnostic utility that attempts to connect to the
*
'*
rootDSE entry of an AD domain controller to return
*
'*
the DnsHostName property. The purpose is to provide
*
'*
an equivalent utility to ping that checks for the
*
'*
availability of the directory service on an Active
*
'*
Directory domain controller.
*
'*
*
'* Compatibility: This script requires WSH 5.6, CScript, ADSI
*
'*
and access to Active Directory
*
'**************************************************************************
Option Explicit
'Define any constants used in this script
Const LDAP_SERVER_DOWN = &h8007203a
'Declare global variables
Dim objArgs,strServerName,strMessage
'Use Named Arguments collection for the command line argument.
'The WSHArguments Object is included in WSH version 5.6 and later
Set objArgs = WScript.Arguments.Named
strServerName = objArgs.Item("dc")
If WScript.Arguments.Named.Count < 1 Then
Call Usage()
WScript.Quit
ElseIf Not Wscript.Arguments.Named.Exists("dc") Then
Call Usage()
WScript.Quit
Else
strMessage = PingDS(strServerName)
WScript.Echo strMessage
End If
'**********************************************************************
'* Routine: Usage
'**********************************************************************
Sub Usage()
WScript.Echo "Usage: dsping /dc:target_name" & VbCrLf & _
"For target_name, specify the ip address or name (NetBIOS name or
FQDN)" & VbCrLf & _

"of an Active Directory domain controller."

End Sub
'**********************************************************************
'* Function: PingDS
'**********************************************************************
Function PingDS(ServerName)
Dim objRootDSE, strDNSHostName
On Error Resume Next
Set objRootDSE = GetObject("LDAP://" & serverName & "/rootDSE")
If err.number = LDAP_SERVER_DOWN Then
PingDS = ServerName & " did not reply."
Else
On Error GoTo 0
strDNSHostName = "LDAP://" & objRootDSE.Get("DnsHostName")
PingDS = "DnsHostName: " & strDNSHostName & " replied."
End If
End Function

Note: This script requires Windows 2000 with Service Pack 3 or later and Windows Scripting
Host version 5.6 or later.
Check the availability of your domain controllers every 15 minutes to ensure that a domain
controller has not been physically breached.
Response
A domain controller that fails to respond to queries can indicate that the domain controller
has been physically breached. For more information on how to respond to a physically
breached domain controller, see Recovering from the Physical Breach of a Domain
Controller in Chapter 3 of this guide.
A domain controller that does not respond to queries within a given period of time can
indicate the domain controller is under some type of denial-of-service attack. These attacks
can include attacks performed by a rogue administrator or rogue object flood attacks.
For more information about how to recover from a rogue administrator attack, see
Recovering from a Rogue Administrator Attack in Chapter 3 of this guide. For more
information about how to recover from a rogue object flood attack, see Recovering from a
Rogue Object Flood Attack in Chapter 3 of this guide.
Monitoring for Domain Controller Restarts
The unauthorized restart of a domain controller can indicate that a domain controller has been
physically breached. When the SYSKEY password is not stored on the domain controller, the
unauthorized restart of a domain controller can also indicate the presence of a rogue service
administrator because the SYSKEY password is only given to service administrators.
Detection
You can detect domain controller restarts by scanning the aggregated system event logs from
all domain controllers for the event criteria that are specified in Table 34.
Table 34 Criteria for Detecting Domain Controller Restarts

Event field

Relevant values

Source

Security

Category

System Event

Type

Success

Event ID

512

User

NT AUTHORITY\SYSTEM

Computer

<computername>

Description: Windows NT is starting up.

Response
The unauthorized restart of a domain controller can indicate that the domain controller has
been physically breached and that a rogue administrator might exist. For more information on
how to respond to a physically breached domain controller, see Recovering from the
Physical Breach of a Domain Controller in Chapter 3 of this guide. For more information
about how to recover from a rogue administrator attack, see Recovering from a Rogue
Administrator Attack in Chapter 3 of this guide.
Monitoring Changes in Domain Controller Performance Counters
You can also monitor changes in Windows 2000 performance counters on a domain controller
to determine its general health. Because the focus of many attacks is to negatively affect the
health of the domain controller, examining these performance counters can give you an
indication that the domain controller is under attack.
The domain controller health indicators can also be indicative of non-security-related issues
as well. Resolving these issues, regardless of whether the intent was malicious or not, is the
same. With security-related changes to health indicators, the reason behind the change in
domain controller health indicators is malicious intent. If you suspect malicious intent, you
need to determine if a rouge user instigated the attack.
Table 35 lists the Windows 2000 system resource performance counters that you should
monitor, the threshold values that indicate a domain controller health problem, and the
rationale for the threshold values.
Table 35 Windows 2000 System Resource Performance Counters for Security-related
Monitoring
Performance
Counter

Indication of Health
Problem

Rationale

Object:
Processor
Greater than 80%
Counter: %
utilization on all
Processor Time
processors

Greater than 80% processor utilization indicates that

the processor is over-utilized and the domain
controller might be under a denial-of-service attack.

Instance: _Total
Object:
LogicalDisk
Counter: %
Free Space
Instance: all
instances
Object: Memory

Less than 25% of the

When less than 25% of the total disk space is
total disk space of each
available on the disk that contains the database, a
drive on the domain
rogue object flood attack might be occurring.
controller

When less than 10% of the physical memory is

Counter:
Less than 10% of the
available, this indicates that the memory is overAvailable Bytes physical memory in the
utilized and the domain controller might be under a
domain controller
denial-of-service attack.
Instance: N/A
Object: Memory
A significant increase in pages/sec in conjunction
Counter:
with low Memory object and Available Bytes
Pages/sec
Increase of any kind
counter indicates that the memory is over-utilized
and that the domain controller might be under a
denial-of-service attack.
Instance: N/A
Table 36 lists the LDAP performance counters that you should monitor, the threshold values
that indicate a domain controller health problem, and the rationale for the threshold values.
Table 36 LDAP Performance Counters for Security-related Monitoring
Performance
Counter
Object: NTDS
Counter: LDAP
Bind Time
Instance: N/A
Object: NTDS
Counter: LDAP
Successful
Binds/sec
Instance: N/A

Indication of Health
Problem

Trend of increase in
length of time.

Rationale
A significant increase in the length of time to
perform an LDAP bind can indicates that the
domain controller is over utilized and might be
under a denial-of-service attack.

A significant decrease in the number of successful

Trend of decrease in
LDAP binds can indicate that the domain
number of successful
controller is over utilized and might be under a
LDAP binds.
denial-of-service attack.

Monitoring Changes in System State and Executables

You should monitor changes in the system state and in the executable files on domain
controllers and administrative workstations to help detect when an attempt to compromise a
domain controller or administrative workstation occurs. Compromising one of these
computers can represent a first step in further compromising the security of the Active
Directory infrastructure.
Monitor changes to the domain controllers and administrative workstations, because these are
the computers where service administrators log on and perform administrative functions.
Because service administrators frequently log on to these computers, attackers focus their
attention on these computers.
The System state, which is stored locally on each domain controller or administrative
workstation, includes:

Configuration for the operating system and critical applications.

Registry and other configuration files.

If attackers modify the system state, they can render a domain controller unusable to the point
of disrupting normal Active Directory operation and preventing users from using Active
Directory. Or, the attacker can modify the system state to introduce a rogue application that
can compromise the security of the domain controller or administrative workstation.
Attackers can also place executable files, such as viruses or Trojan horse programs, on the
domain controllers and administrative workstations. These executables can be files that:

Are in addition to the existing executables.

With this type of attack, the attacker places new executables on the computer and then
modifies the system state to run the rogue application. The next time the computer
restarts, the rogue application is run and the security of Active Directory or the
operating system is compromised.

Replace existing executables.

With this type of attack, attackers replace existing executables on the computer with a
rogue application. The next time a service administrator or the operating system
attempts to run the valid, replaced application, the rogue application is run and the
security of Active Directory or the operating system is compromised.

The monitoring of changes in the system state and executable files on domain controllers and
administrative workstations is accomplished by having system state monitoring software.
This section describes the characteristics of system state monitoring software. You can
purchase software that does this type of monitoring, such as Microsoft System Management
Server 2000 or other similar non-Microsoft software. You can also create your own software
to perform system state monitoring.

Monitor changes in the system state and executable files on domain controllers and
administrative workstations by performing the following tasks:
1. Identify how the software that monitors changes in the system state and executables
on domain controllers and administrative workstations operate.
2. Create a baseline reference for the operating system and system state.
3. Monitor changes in the baseline reference.
Identifying the Characteristics of System State and Executable Monitoring Software
Monitor the domain controllers and administrative workstations for changes in the system
state and executables as close to real time as possible. The sooner you detect a change in the
system state or executables, the more you can limit the extent to which Active Directory is
compromised.
The following are the characteristics of what the system state monitoring software should
perform so that it can detect changes in the system state and executables:

Creates a point-in-time list of the system state configuration settings and software
inventory of the executables.
The point-in-time snapshot of the computer provides a baseline for the software to use
in determining when any changes in the system state or executables occur.

Periodically compares the current system state configuration settings and list of
executables to the point-in-time list and inventory.
The software compares the current system state and list of executables with the
baseline to determine if:
o
o

Any changes to the system state occur, such as additions, removals, or updates
to the registry.
New executables are placed on the computer.

Changes in the size, date time stamp, owner, and other attributes of any
existing executables.

Any previously existing executable has been removed.

Creating an Operating System Baseline Reference

Immediately after you install your domain controller and administrative workstation, create a
baseline reference of the system state. Before you create the baseline for a domain controller
or an administrative workstation, ensure that you:

Install the domain controller and administrative workstation in a secure configuration.

To install the domain controller, use the recommendations in Deploying Secure Domain
Controllers in Chapter 2 ofSecuring Active Directory Installations and Day-to-Day

Operations: Part . Install an administrative workstation by using the recommendations in

Securing Service Administrator Workstations in Chapter 4 in Securing Active Directory
Installations and Day-to-Day Operation: Part I.

Install any recent service packs and hotfixes as recommended in Staying Current
with Security Hotfixes and Service Packs in Chapter 1, in this document.

Run a virus scan on all disk volumes as recommended in Running Antivirus

Software on Domain Controllers and Administrative Workstations in Chapter 1 in
this document.

If the configuration of the domain controller or administrative workstation is not stabilized

before you create the baseline, the monitoring software reports any updates as changes in the
system state and executables. These legitimate changes may be misinterpreted as attempts to
compromise the integrity of Active Directory. So, if you must perform updates after creating
the baseline, notify operation staff of the scope of the updates and the computers that are
going to be updated.
Monitoring Changes in the Baseline Reference
The primary decision with regard to monitoring changes in the baseline reference for domain
controllers and administrative workstations is how often to monitor for changes. Monitor as
frequently as possible to ensure that you can limit the window in which the Active Directory
infrastructure is compromised. However, the monitoring of changes consumes system
resources, such as an increase in disk activity or processor utilization, on the computer being
scanned.
Follow these recommendations when monitoring for changes in the baseline reference:

Monitor for changes in the baseline reference for domain controllers and
administrative workstations weekly at a minimum.
Determine the tradeoff between the frequency of monitoring for changes and the
consumption of system resources by the monitoring process when scanning for
changes in the system state and the executables.

Perform baseline comparisons during periods of time when the domain controllers
and administrative workstations are minimally used.
Because the monitoring process consumes system resources, scan for changes in the
system state and the executables during periods of time when system resource use is
minimal.

Exclude or ignore changes that are a normal part of the operating systems function.
Many system state settings and files change as a normal part of the operating systems
function. For example, the paging file, Active Directory database files, log files, and
some registry entries change as a normal part of the day-to-day operation of domain
controllers. There are similar changes on administrative workstations.

Most system state monitoring software are configured by default to exclude the system state
settings and files for the operating system. In addition, you can determine if other files need
to be excluded by observing the system state settings and files that change and then excluding
the files that you determine are a legitimate changes in the system state. You can ignore these
files to ensure that only actual security breaches are reported.
Important: You can ignore files that are modified by the operating system, because they are
not executables. Consider any modification of an executable to be a compromise in security
for a domain controller or an administrative workstation.
Recommendations: Monitoring the Active Directory Infrastructure

Following the security recommendations described earlier in this chapter helps to minimize
the security risks involved in monitoring the Active Directory infrastructure. Of course, as
previously mentioned, you should consider the recommendations described in other chapters
when considering how best to enhance your comprehensive Active Directory security.
In most instances, these recommendations are intended for intranet datacenter, extranet
datacenter, and branch office scenarios. However, some of the recommendations depend on
the particular scenario. When the recommendations are scenario specific, references are
included to direct you to the sections of this guide where the recommendations are discussed.
Monitoring Changes to Active Directory
The following table provides a checklist of recommendations for monitoring forest-level and
domain-level changes to Active Directory and monitoring changes in service administrator
accounts, administrative workstations, and disk space.
Monitoring Forest-level Changes
Detect changes in the Active Directory schema.

Identify when domain controllers are added or removed.

Detect changes in replication topology.

Detect changes in LDAP policies.

Detect changes in dSHeuristics.

Detect changes in forest-wide operations master roles.

Monitoring Domain-level Changes

Detect changes in domain-wide operations master roles.

Detect changes in trusts.

Detect changes in AdminSDHolder.

Detect changes in GPOs for the Domain container and the Domain Controllers OU.
Detect changes in GPO assignments for the Domain container and the Domain Controllers
OU.
Detect changes in the membership of the built-in groups.

Detect changes in the audit policy settings for the domain.

Monitoring Service Administrator and Administrative Workstation Changes
Detect changes in service administrator accounts.

Detect changes in GPOs for the Service Administrators controlled subtree.

Detect changes in GPO assignments for the Service Administrators controlled subtree.
Monitoring for Disk Space Consumed by Active Directory Objects
Monitor for an inordinately large number of normal-sized objects.

Monitor for a limited number of extraordinarily large-sized objects.

Monitoring Domain Controller Status
The following table provides a checklist of recommendations for monitoring the status of
individual domain controllers.

Monitoring Domain Controller Availability

Monitor domain controllers for active status.

Monitor domain controllers for restarts.

Monitoring Changes in Domain Controller Performance Counters
Detect changes in domain controller system resources.

Detect changes in LDAP responsiveness.

Monitoring Changes in System State and Executables
The following table provides a checklist of recommendations for monitoring changes in the
system state and executables of domain controllers and administrative workstations.
Identifying the Characteristics of System State and Executable Monitoring Software
Identify the characteristics of the software that monitors changes in the system state and
executables on domain controllers and administrative workstations.
Creating an Operating System Baseline Reference
Create a baseline of the system state and executables for the operating system to be used
for future comparison.
Monitoring Changes in the Baseline Reference
Monitor changes in the current system state and executables by comparing them to the
baseline reference.
Top of page
Chapter 3 - Recovering from Active Directory Attacks

Chapter 2 of this document provides recommendations for monitoring your network and
identifying abnormal activity that might indicate that Active Directory is under attack. This
chapter provides recommendations for returning the Active Directory directory service and
database to its pre-attack state, if possible. Recommendations for locating the attacker and
neutralizing the attack are outside of the scope of this guide.

If you can confirm an attack on Active Directory has occurred, ascertain immediately if there
have been any unauthorized modifications to Active Directory or its database. If so, begin the
recovery process to:

Reestablish the prescribed Active Directory security configuration.

Restore the normal directory service and configuration.

Restore Active Directory database content.

Note: This chapter assumes that an attack has occurred in the past. Do not attempt to recover
Active Directory if it is still under attack. Instead, focus on stopping the attack.
This chapter describes recovery recommendations for several types of attacks. In many cases,
the recovery process is slow, and it might be several days before Active Directory functions
normally again. If necessary, make modifications to these recommendations based on the
needs of your environment. However, use caution when doing so; relaxing these security
recommendations might leave your network open to attack again.
This chapter provides guidance for recovering from Active Directory attacks in the following
situations:

Physical breach of a domain controller

Rogue administrator attack

Catastrophic forest-wide corruption

Data tampering attack

Rogue object flood attack

Rogue object growth attack

Recovering from the Physical Breach of a Domain Controller

If an unauthorized person gains access to the Active Directory data stored on a domain
controller, that domain controller is considered to be physically breached. A domain
controller is physically breached when an unauthorized person has been able to:

Gain physical access to a domain controller.

Steal, copy, or access Active Directory database files.

Access the backup media for a domain controller.

When a domain controller has been physically breached, assume that all information that is
stored on the domain controller, including the Active Directory database, is now available to
the attacker. In such a situation, your organization should implement a plan for minimizing
the security damage caused by the breach.
Recover from the physical breach of a domain controller by performing the following tasks:

1. Create a new backup of Active Directory.

2. Remove the account for the breached domain controller from Active Directory.
3. Reset all service administrator account passwords.
4. Reset the KRBTGT password twice.
5. Change all user account passwords.
6. Review memberships in all service administrator groups.
7. Review installed software on all domain controllers and service administrator
workstations.
8. Review all group policy settings and logon scripts.
9. Find and remove rogue user accounts.
10. Create new backups.
Create a new backup of Active Directory
During the recovery process, you will be making many changes to Active Directory. Create a
backup of Active Directory to ensure that, if necessary, you have a recent backup from which
to restore.
Removing the Account for the Breached Domain Controller from Active Directory
As long as the computer account for the breached domain controller remains in Active
Directory, that computer can continue to function as a domain controller on your network and
it can continue to perpetrate changes to Active Directory. Remove the computer account for
the breached domain controller from Active Directory as soon as possible after the breach has
been discovered.
Force the immediate removal of the breached domain controller using the NTDSutil.exe tool,
which is in Support Tools on your Windows 2000 CD. For information on how to remove a
domain controller from Active Directory, see Removing an Active Directory Domain
Controller in the Appendix B.
If you are responding to a rogue service administrator attack, you must remove the rogue
service administrator account from Active Directory. To remove the account, simply find the
account in Active Directory Users and Computers, right-click the account, and click Delete.
Resetting All Service Administrator Account Passwords
Service administrator accounts are highly privileged, and therefore they should be dealt with
more urgently than other user accounts. After an Active Directory attack, reset all service
administrator account passwords immediately. This minimizes the chance that an attacker
will have sufficient time to crack one of these passwords and use it to log on to your domain.

You must reset each password individually. For information on how to reset service
administrator passwords, see Resetting Passwords in Appendix B.
For information about which groups qualify as service administrator accounts, see Securing
Service Administrator Accounts in Part 1, Chapter 5, of this guide.
Rendering Current Ticket-Granting Tickets invalid
You must reset the Key Distribution Service Account (KRBTGT) password twice to
invalidate ticket-granting tickets (TGT) issued since the attack. The password must be reset
twice to effectively invalidate TGTs.
With Kerberos, users are granted a TGT by KRBTGT upon authentication. Users present this
TGT to gain access to network resources for the lifetime of the ticket, 10 hours by default.
The KRBTGT encrypts TGTs with its password.
If an attacker compromises a password for a user account, logs on to the domain, and receives
a TGT, the attacker is able to access network resources with that TGT for the lifetime of the
ticket. This occurs even if the users password is changed after the attacker received the TGT.
However, if you reset the KRBTGT password, the TGT is invalidated because domain
controllers are not able to decrypt it. You must reset the password twice because domain
controllers attempt to decrypt the TGT with passwords stored in history, two by default.
Important: You must be running Windows 2000 SP2 or later to perform this procedure. If
you are not, replication issues can result. If replication is interrupted, use the Net Stop tool to
stop replication on the domain controller and the repadmin tool to start replication. A
complete discussion of these tools is outside of the scope of this guide. These tools are
documented in the online help for Windows 2000.
To reset the KRBTGT account password, open Active Directory Users and Computers, and
find the krbtgt user account. Right-click the account, and then click Reset password.
Changing All User Account Passwords
One threat that is associated with a breached domain controller is an impersonation attack. If
the attacker has offline access to data in Active Directory, the attacker can attempt to
compromise user account passwords with a password-cracking tool. If passwords are
compromised, the attacker can impersonate an authenticated user. The attacker can log on to
the domain and perform privileged tasks if a service administrator password is compromised.
To prevent the attacker from using compromised passwords, render these passwords useless
by forcing the expiration of all user account passwords in the domain that contains the
breached domain controller. When you force the expiration of account passwords, users must
change their passwords the next time they log on.
If a user is logged on when passwords expire, the password will have to be changed the next
time a logon is attempted. If the attacker manages to crack the users password before the
password is changed and logs on as that user, the attacker might be able to change the
password. If this occurs, the user receives a notification to lock and unlock the computer to

verify credentials. Because the password provided by the user does not match the new
password set by the attacker, the user cannot unlock the computer. This results in a support
call, at which point the user account should be disabled and the password reset.
If the breached domain is trusted by another domain, and if any of the users in the breached
domain have administrator permissions in the trusting domain, you must expire all passwords
in the trusting domain as well. If the attacker cracks a user account password that is also an
administrator in another domain, the attacker has effectively compromised the other domain
as well.
Note: For best security, reset all service administrator account passwords and expire all user
account passwords, including service accounts. However, it is less essential to do so if one or
both of the following situations describe your environment:

If you enabled SYSKEY so that you must provide a password or insert a floppy disk
containing the key on machine reboots on the breached domain controller, and the
password or floppy disk are not available to the attacker.

If your organization uses two-factor authentication for all users, such as smart cards or
biometrics devices. In this case, you must still change all service account passwords.

Securely and efficiently change all user account passwords by performing the following
tasks:
1. Prepare the PDC emulator for globally resetting passwords.
2. Force the expiration of user account passwords in batches.
Preparing the PDC Emulator for Globally Resetting Passwords
Before you force the expiration of all user account passwords, you must adequately prepare
your network to handle this volume of password changes gracefully. The Windows 2000
domain controller that holds the primary domain controller operations master role (PDC
emulator) can become overloaded and experience performance degradation in the following
situations.

When a large number of users change their account passwords in a short period of
time.
When users attempt to log on to a computer before the password change replicates to
all domain controllers.
If NTLM is used for authentication, when users attempt to access network resources
before the new password replicates to all domain controllers in the domain.

If the PDC emulator becomes overloaded, users might be denied access to computers and
resources. For more information on why the PDC emulator can become overloaded in these
situations, see Appendix A: Overloading the PDC Emulator in the Appendix A
Prepare your Active Directory infrastructure to reduce the load on the PDC emulator by
performing the following tasks:

1. Direct general client requests away from the PDC emulator.

2. Isolate the PDC emulator in its own site.
3. Disable password change forwarding to the PDC emulator.
4. Reduce the notification delay interval for replication.
Directing General Client Requests Away from the PDC Emulator
As a general best practice, ensure that the PDC emulator is available to perform tasks that
only it can perform by directing general client request traffic away from it. This can be
accomplished by assigning appropriate priority and weight values to the service (SRV)
resource records for the PDC emulator in the corresponding DNS database. This helps to
ensure that tasks that can be performed by other domain controllers are not sent to the PDC
emulator.
Assign priority and weight values to the PDC emulator so that its priority is higher and its
weight is lower than other domain controllers in the domain. The DC locator uses these
values to determine which domain controller is most appropriate for servicing a client. A
domain controller with a higher priority is less likely to be contacted. If priorities are equal
between domain controllers, the one with lower weight is less likely to be contacted.
Important: For these settings to take effect, you must stop and restart the Netlogon service
on the PDC emulator. To stop the Netlogon service, at the command line type net stop
netlogon, To restart the Netlogon service, at the command line, type net start netlogon.
For specific instructions on how to configure the priority and weight for domain controllers,
see Changing the Priority for DNS SRV Records and Changing the Weight for DNS SRV
Records in Appendix B of this guide.
Isolating the PDC Emulator in its Own Site
Another criterion that is used by the DC locator to preferentially select a domain controller to
fulfill a client request is the site to which the domain controller belongs. The DC locator
always prefers a domain controller that resides in the same site as the client. You can decrease
the number of requests that are received by the PDC emulator by isolating the PDC emulator
in its own site in which there are no clients. This site is created solely for the purpose of
isolating the PDC emulator and not for designating a geographic separation.
Move the PDC emulator to the new site by performing the following tasks:
1. Create a new site.
For this procedure, see Create a Site Object in the Active Directory Operations
Guide, Appendix B Procedures Reference at:
http://www.microsoft.com/technet/prodtechnol/ad/Windows2000/maintain/opsguide/P
art2/ADOGdApB.asp
2. Create a new subnet for the site.

For this procedure, see Create a Subnet Object in the Active Directory Operations
Guide, Appendix B Procedures Reference at:
http://www.microsoft.com/technet/prodtechnol/ad/Windows2000/maintain/opsguide/P
art2/ADOGdApB.asp
3. Move the PDC emulator to the new site by changing its IP address to match a subnet
in the new site.
For this procedure, see Change the Static IP Address of a Domain Controller in
Active Directory Operations Guide, Appendix B: Procedures Reference at:
http://www.microsoft.com/technet/prodtechnol/ad/Windows2000/maintain/opsguide/P
art2/ADOGdApB.asp
Disabling Password Change Forwarding to the PDC Emulator
After the PDC emulator is moved to its own site, you can further decrease the load on it by
disabling password change forwarding to the PDC emulator. Password change forwarding is
enabled by default on all domain controllers. When it is enabled, the PDC emulator,
regardless of the site where it resides, is notified immediately of password changes and
updated with the new password. When many users change their passwords at once, the PDC
emulator receives many notifications, which generates a significant load on the PDC
emulator, causing its performance to degrade.
Disabling password forwarding prevents the immediate notification of password changes to
the PDC emulator only if the PDC emulator is in a separate site. However, the PDC emulator
still receives the new password through normal replication during the next scheduled
replication period.
Note: Disabling password forwarding only takes effect on domain controllers running
Windows 2000 SP2 and later.
Password change forwarding should be disabled on every domain controller in the domain.
To disable password change forwarding on a domain controller, modify the entry under the
following registry key:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Entry name: AvoidPdcOnWan
Data type: REG_DWORD
Value: 0 (disabled)

The default value for this entry is 1 (enabled). A value of 0, or no value, disables password
change forwarding.
You can create a script that modifies this value on all domain controllers in the domain
automatically by performing the following tasks:
1. Create the ComputerSearch.vbs script and copy it to a domain controller in the
affected domain. For information about how to create the script see Identifying
Computers to Receive New Registry Settings in the Appendix B.
2. Create a list of domain controllers in the domain by typing the following command at
a command prompt:

3. Cscript computersearch.vbs /r:DC

4. Apply the new registry value to the listed domain controllers by creating and running
the ApplyReg.vbs script.
Important: When password change forwarding is disabled, the PDC emulator no longer has
the most up-to-date password information. This can result in users being denied access to
network resources before the password change has replicated to all domain controllers. You
can help mitigate this by reducing the notification delay intervals for Active Directory
replication, as described in the next section.
Reducing the Notification Delay Interval for Active Directory Replication
To minimize the chance that users will be denied access to resources due to replication
latency following a password change, reduce notification delay intervals for Active Directory
replication. After you disable password change forwarding to the PDC emulator, the PDC
emulator is no longer available to differentiate between a bad password and a password that
has recently been changed but not replicated. Therefore, the chance that users are denied
access to resources increases.
To minimize this possibility of users being denied access to resources, decrease the
notification delay intervals for Active Directory replication. This expedites the replication of
password changes to other domain controllers in the site.
The notification delay intervals for Active Directory replication should be reduced on every
domain controller in the domain. To decrease the notification delay interval, you must modify
two registry entries. Both of these entries reside under the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Entry name: ReplicatorNotifyPauseAfterModify
Data type: REG_DWORD
Value: 30 (secs)

This entry value determines the number of seconds that the domain controller on which the
password change occurs waits before sending a notification to its first replication partner to
initiate replication. The default value for this setting is 300 seconds. It is recommended that
you reduce this setting to 30 seconds. After all user passwords have been changed, restore the
default setting.
Entry name: ReplicatorNotifyPauseBetweenDSAs
Data type: REG_DWORD
Value: 3 (secs)

This entry value determines the number of seconds that the domain controller on which the
password change occurs waits between subsequent notifications to all other replication
partners. The default value for this setting is 30 seconds. It is recommended that you reduce
this setting to 3 seconds. After all user passwords have been changed, restore the default
setting.
You can create a script that modifies these value on all domain controllers in the domain
automatically by performing the following tasks:

1. Create the ComputerSearch.vbs script and copy it to a domain controller in the

affected domain. For information about how to create the script see Identifying
Computers to Receive New Registry Settings with ComputerSearch.vbs in Appendix
B.
2. Create a list of domain controllers in the domain by typing the following command at
a command prompt:
3. Cscript computersearch.vbs /r:DC

4. Apply the new registry value to the listed domain controllers by creating and running
the ApplyReg.vbs script.
Reducing the Interval for Active Directory Replication Between Sites
To decrease the possibility that users are denied access to necessary resources in specific
sites, you can reduce the interval for Active Directory replication between specific sites. The
default replication interval is 180 minutes. You can decrease this interval, particularly for the
site that contains the PDC emulator, and accelerate password changes replicating between
these sites.
Replication traffic uses network bandwidth. Do not reduce the interval for replication
between sites to such a low value that bandwidth becomes saturated. The appropriate value is
dependent on your environment.
After the password reset and change process is complete, restore these values to their original
configuration.
To configure the replication between site interval, open Active Directory Sites and Services,
right-click the site that you want to configure and click Properties. In Replicate every, enter
the number of minutes you want to wait between replication.
Forcing the Expiration of User Account Passwords in Batches
If all user account passwords are changed at once, the available bandwidth for replication can
become saturated. Forcing the expiration of user passwords in smaller batches decreases the
impact on available replication bandwidth.
The size of the batch that you choose varies, depending on your environment. Start with
batches that seem small and easily manageable for your environment; 3000 to 5000 user
accounts might be a good starting point. If the available replication bandwidth is relatively
unaffected by the batch size you select, increase the batch size during each iteration until you
find the best size for your environment.
You can employ a variety of methods or criteria to help group your users into batches for the
purpose of password change. The order in which you reset passwords should make sense for
your organization. Create batches of user accounts based on, for example:

Account location in a OU subtree.

Range of alphabetized account names.

Account membership in large groups or distribution lists.

Service account passwords also need to be expired and changed by the service administrator
in charge of that service. Service accounts are found in Active Directory Users and
Computers and might have been created by service administrators or by the service itself.
Expire these passwords using the same method as expiring user account passwords. The
appropriate service administrator must change the password and go to each server that runs
the service to manually update the password information.
The user interface for Active Directory allows only one password to expire at a time. To
automate the process, use a script that enumerates user accounts and that forces the expiration
of the password associated with each user account by setting the attribute pwdLastSet on
each account to the value 0. This forces users to change their passwords the next time they
log on.
For a sample script for forcing account password expiration, see Forcing Password
Expiration Using a Script in Appendix B.
After you run the script for one batch, allow some time for users to log on and change their
passwords and for that password information to replicate throughout the domain before
resetting passwords for the next batch of users.
Keep in mind, however, that waiting to change a batch of passwords represents a security
trade-off. The longer that account passwords remain unchanged, the longer the attacker has to
compromise a password and infiltrate your organizations network.
Reviewing the Memberships of All Service Administrator Groups
The service administrator groups are very privileged groups. To inflict the most damage,
attackers usually try to gain access to an account, such as a service administrator account, that
allows them to perform highly privileged tasks.
In addition to compromising passwords for existing service administrator accounts, attackers
might also create user accounts and add them to the service administrator groups. If you do
not find and remove these accounts, attackers will retain easy, privileged access to your
network in the future. You must search for these groups manually, looking for user accounts
that you do not recognize.
Review all users in service administrator groups and remove suspicious accounts from the
service administrator group. If the account belongs to an authorized user, the user will make it
known to your organizations help desk.
For information about which groups qualify as service administrator accounts, see Securing
Service Administrator Accounts in Part I, Chapter 5, of this guide.
Reviewing Installed Software on Domain Controllers and Administrative Workstations
In an ideal situation, you completely rebuild computers that you know have been
compromised by reformatting the hard drive and reinstalling all software on the domain
controller. This is the most secure reaction to attack, because reformatting the hard disk
removes any back doors that attackers leave so that they can enter your network again.

In many cases, completely rebuilding the domain controller is not feasible. If your
organization cannot completely rebuild the domain controller, plan to carefully review all
software that has been installed on domain controllers and administrative workstations. Make
sure that all settings are set appropriately for each application, and check for new applications
that may have been added to the domain controller.
The intruder may have cracked some passwords, making it possible to log on to certain
workstations and to install malicious software. The potential also exists that the attacker has
already installed malicious software, such as a Trojan horse.
To respond to the threat of the installation of a Trojan horse:

Examine services, applications, password filtering software, and notification

packages.
Examine all executables to ensure that these have not experienced tampering.

Run a virus scan on all domain controllers and administrative workstations.

Reviewing All Group Policy Settings and Logon Scripts

If the attacker gains permissions and privileges on the level of service administrator, the
attacker can alter any security safeguards that you have in place for your organization,
including policy settings and logon scripts. After an attack, it is especially important that you
check all policy settings and logon scripts to ensure that they have not been tampered with.
The most efficient way to check the validity of most policy settings is to run the Security
Configuration and Analysis tool, comparing the template that you created (see corresponding
section in Part 1) to the current settings for the domain. The tool reports any inconsistencies
in this comparison. For information on how to use the Security Configuration and Analysis
tool, see Analyzing Current Security Settings in Appendix B.
Note: If the template might have been modified by an attacker, review the settings in the
template to ensure they are still accurate.
If an attacker can access logon scripts and inject malicious code into these scripts, the
malicious code will run on every client computer that authenticates on the network. After an
attack is detected, logon scripts must be analyzed to ensure that they have not been modified.
Finding and Removing Rogue User Accounts
When an attacker is able to log on to a domain with a privileged account, the attacker might
create one or more new, rogue user accounts. It is important to find this type of account or
accounts. If you do not, the attacker can use this account to gain access to your network in the
future and perpetrate other attacks.
The attacker might have added local accounts to administrative workstations or high security
servers. These accounts can be instrumental for the attacker to perpetrate a Trojan horse
attack on your network. Review the local administrator group and privileged accounts on
administrative workstations and high security servers to ensure that the accounts are valid.

To find rogue accounts efficiently, you need to find an authoritative source of the users that
exist on your network, such as a Human Resources database. Examine all user objects and
verify that each object maps to a legitimate user. Disable all user accounts that do not have an
associated legitimate user. If the user account is needed, a support call will result from the
account being disabled. Investigate each call to ensure that the need for the account is valid.
Delete all accounts that are not valid.
Creating New Backups
If you are unsure as to when a domain controller has been physically breached, you cannot be
sure that any of your current backups are safe. Create a fresh backup as soon as the recovery
is complete.
Recovering from a Rogue Administrator Attack

Service administrator accounts are the most highly privileged accounts in Active Directory.
Service administrator accounts are considered to be rogue if one of the following has
occurred:

A service administrator account has been compromised.

A user has elevated the privileges of a user account to the level of a service
administrator.

A trusted service administrator has become an attacker.

Rogue service administrators can perform virtually any malicious act. If you have detected
and removed a rogue service administrator account from your network, the recovery
procedure that you must perform is the same as the recovery for a physically breached
domain controller, with one exception. Instead of removing the breached domain controller
account from Active Directory, you must remove the rogue administrator account from
Active Directory.
To recover from a rogue administrator attack, follow the recommendations described above
in the Recovering from the Physical Breach of a Domain Controller earlier in this chapter.
For information about which groups qualify as service administrator accounts, see Securing
Service Administrator Accounts in Part I, Chapter 5, of this guide.
Recovering from Catastrophic Forest-wide Corruption

If your Active Directory schema is corrupt or if irreparable changes are made to Active
Directory data that is then replicated throughout your forest, you may have to recover the
forest. In this process, you restore one domain controller for each domain from the last
known good backup. All other domain controllers are restored by running the Active
Directory Installation Wizard. Because the process is quite extensive and because data is
usually lost, only recover the forest as a last resort when all other Active Directory restorative
procedures have failed.

There are three stages to recovering your forest: pre-recovery, recovery, and post-recovery. To
complete the forest recovery, it is recommended that you perform the tasks detailed in the
following sections.
A complete description of each task is outside the scope of this guide. The Best Practices:
Active Directory Forest Recovery paper contains a detailed explanation of and instructions
for how to perform each task. For detailed information on performing each task, see Best
Practices: Active Directory Forest Recovery at
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=3EDA5A79C99B-4DF9-823C-933FEBA08CFE.
Performing Tasks in Preparation for a Forest Recovery
Before you recover your forest, perform the following tasks:
1. To ensure that a forest recovery is necessary, check with Microsoft Product Support
Services.
2. Document your current forest structure by:
1. Making a list of all domain controllers.
2. Noting which domain controllers have a backup that was made before the
corruption, if you know when the corruption occurred.
3. Identify the forest root domain (the first domain in a new forest).
The first domain controller that you restore will come from this domain.
4. For every other domain, identify the domain controller with the most recent valid
backup.
These domain controllers will be the recovery domain controllers for all other
domains.
5. Shut down all domain controllers in the forest.
Performing Forest Recovery Tasks
Until you are directed to return the domain controllers to the production network, recover
your forest while the domain controllers are physically isolated in a test environment.
Recover the first domain controller in the forest by performing the following tasks:
1. Restore a domain controller from the forest root domain from the last known good
backup.
For details of restoring a domain controller, see Restore from Backup Media for
Authoritative Restore in the Active Directory Operations Guide, Appendix B Procedures Reference at http://www.microsoft.com/technet

/prodtechnol/ad/Windows2000/maintain/opsguide/Part2/ADOGdApB.asp.
Important: It is essential that you begin the recovery with a domain controller in the
forest root domain. Then repeat steps 1 through12 for one domain controller in each
additional domain in the forest.
2. Verify that the data on the domain controller has not been affected by the failure.
If the Active Directory data is damaged, repeat step 1 using a different backup.
3. Mark this SYSVOL as primary, because this is the first domain controller in the
domain.
4. Ensure that the local DNS Server service is installed and running on the domain
controller.
5. If the restored domain controller is enabled as a global catalog, disable the global
catalog flag.
6. Raise the value of the current RID pool by 100,000.
7. Seize all domain-wide and forest-wide operation master roles (also known as flexible
single master operations or FSMO).
Note: You must seize these roles because, at this point, this is the only functional
domain controller in the forest. When you repeat these steps for other domains, seize
only the domain-wide FSMO roles.
8. Clean up the metadata for all other domain controllers in the domain.
9. Delete all server and computer objects in the domain except for this domain
controller.
10. Reset the computer account password of this domain controller twice.
11. Reset the krbtgt account password twice.
For a discussion of the krbtgt account, see Rendering Current Ticket-Granting
Tickets invalid earlier in this chapter.
12. Reset the trust password (Trusted Domain Object password) twice for all trusted
domains.
13. Repeat steps 1 through 12 on a single domain controller from each domain in the
forest before continuing with the forest recovery.
14. Finally, return the new domain controllers to the network, and rebuild the remaining
domain controllers by performing the following tasks:
1. Join the recovered domain controllers to your network.
2. Ensure that the global catalog flag is enabled for the domain controller in the
forest root domain.

3. Rebuild all other domain controllers in the forest by running the Active
Directory Installation Wizard.
Performing Tasks Required to Complete the Forest Recovery
After your forest is functional again, complete the recovery process by performing the
following tasks:
1. Delete any DNS records for domain controllers that have not been recovered.
2. Delete any WINS records for domain controllers that have not been recovered.
3. Restore the operation master roles to the domain controllers that owned those roles in
the pre-failure configuration.
4. Enable the global catalog flag on domain controllers that were global catalog servers
in the pre-failure configuration.
5. Restore or reinstall any software applications that were running on domain controllers
before recovery.
A detailed explanation of and instructions for how to perform each task is beyond the scope
of this guide. For detailed information on performing each task, see Best Practices: Active
Directory Forest Recovery at http://www.microsoft.com/downloads/details.aspx?
displaylang=en&FamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE.
Recovering from Data Tampering by Restoring Active Directory Data

Tampering with or destroying certain Active Directory data types might not cause Active
Directory to fail, but normal directory functioning might be disrupted. Examples of this type
of tampering include modifying group memberships, altering SACLs on OUs, and removing
topology elements of the Active Directory infrastructure.
Tampering of this type can be easily detected because some clients are unable to access
network resources. It can be difficult to reconstruct missing Active Directory data if your
organization does not maintain records of the exact configuration and security policies for
Active Directory objects.
In some cases, you can recover to a pre-attack state by simply reapplying security templates,
group policy settings, or registry settings. To restore subtree and leaf data, authoritatively
restore only the affected objects from the last known good backup. In these situations, you
can then update all other domain controllers with this new information.
Performing an Authoritative Restore of Directory Objects
Until directed to return the domain controller to the production network, perform these tasks
in a physically isolated test environment.
Restore subtree and leaf data in the affected domain by performing the following tasks:

1. Identify a domain controller that contains tampered data and that has a last known
good backup.
2. Disconnect the domain controller from the production network.
3. Boot the domain controller into DSRestore Mode, and perform a normal restore from
backup.
For details, see Restore from Backup in the Active Directory Operations Guide,
Appendix B Procedures Reference, at:
http://www.microsoft.com/technet/prodtechnol/ad/Windows2000/maintain/opsguide/P
art2/ADOGdApB.asp
4. Restart the domain controller.
5. Verify that the tampered data is present, but that it is restored to its correct data values.
If the Active Directory data is still missing or incorrect, repeat steps 1 through 3,
using an earlier backup.
6. Boot the domain controller into DSRestore Mode, and perform an authoritative
restore of the tampered data.
For details, see Restoring Active Directory subtree and Leaf Data from Backup in
the Active Directory Operations Guide, Appendix B Procedures Reference, at:
http://www.microsoft.com/technet/prodtechnol/ad/Windows2000/maintain/opsguide/P
art2/ADOGdApB.asp
7. Connect the domain controller to the production network.
8. Restart the domain controller.
9. Verify that the tampered data is restored on this domain controller.
10. Verify that the restored version of the tampered data replicates to all other domain
controllers.
Detailed instructions for performing an authoritative restore of tampered objects is beyond
the scope of this guide. For background information and detailed instructions for performing
these tasks, see Best Practices: Active Directory Forest Recovery at:
http://www.microsoft.com/downloads
/details.aspx?displaylang=en&FamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE
Recovering from a Rogue Object Flood Attack

Domain controllers are vulnerable to an attack that adds large numbers of rogue objects to
Active Directory. Such an attack can cause a domain controller to run out of disk space on the
databases drive potentially causing other legitimate object additions, modifications, or
deletions to fail.
After an attacker has been blocked from accessing the network, to recover disk space on
domain controllers, perform the following tasks:

1. Delete the reserve file on all affected domain controllers.

2. Create a backup of the recovery domain controller.
3. Find and delete the rogue objects.
4. Accelerate the purging of deleted objects (optional).
5. Verify that all deleted objects have been purged.
6. Create a fresh backup of a clean domain controller.
Deleting the Reserve File
If you previously added a reserve file to the Active Directory database drive, you can recover
disk space by deleting the reserve file on all affected domain controllers. Freeing up some
disk space helps your network to function during the recovery process. For information about
the reserve file, see Creating a Reserve File to Enable Recovery from Disk-Space Attacks
in Part I, Chapter 3, of this guide.
If a reserve file does not exist, or if queued objects fill the disk space originally set aside
through the reserve file (after the file has been deleted), you must ascertain how you can
recover disk space while the recovery is taking place. One possibility is moving the database
files on all affected domain controllers to larger, dedicated drives.
Creating a Backup of the Recovery Domain Controller
You perform the recovery on one domain controller. Choose a domain controller on which to
perform the recovery, and create a fresh backup.
It is possible for an attack to occur slowly over time, as opposed to all objects being added to
the directory at once. During the period of time in which rogue objects are added to Active
Directory, legitimate objects may also be created. In the process of purging rogue objects,
these legitimate objects might also be purged. If this occurs, it is easier to restore these
objects from backup than it is to recreate the objects from scratch.
Create a backup for the recovery domain controller before you proceed with the recovery, so
that you have a record of all objects.
Finding and Deleting Rogue Objects
Before you can delete all rogue objects, you must find them. If you already have an idea as to
which objects are rogue objects, use those leads to determine which objects can be deleted.
The steps detailed below should only be used if you have no idea as to when the attack
occurred; these steps can be time consuming.
To find all the rogue objects that were added to Active Directory, you must determine when
the attack began and which object is the first rogue object. Then, you have to examine all
objects that were created since the first rogue object was created, looking for other rogue
objects. If you do not know which object is the first rogue object, you have to search Active
Directory for that object.

If you have been collecting periodic object counts, as recommended in Monitoring for Disk
Space Consumed by Active Directory Objects in Chapter 2 of this guide, you can determine
when the attack took place by performing the following tasks:
1. Disconnect an affected domain controller from the network.
2. Create the ObjCountbyClass.vbs and ObCMAudit.vbs scripts on a workstation and
copy them to the affected domain controller. These scripts are required for rogue
object detection.
For information about how to create ObjCountbyClasse.vbs script, see Monitoring
the Number of Objects In a Domain With ObjCountByClass.vbs in Appendix B of
this guide. For information about how to create ObCMAudit.vbs script, see
Identifying Objects Created or Modified Within A Period of Time With
ObCMAudit.vbs in the Appendix B of this guide.
3. Identify the current number of objects by object class by running the following
command:
4. cscript ObjCountbyClass.vbs

ObjCountbyClass.vbs creates an output file, ObjCountbyClass -date-time.csv, which

contains the number of objects by object class.
5. Examine the output file from ObjCountbyClass.vbs and compare this output to
previous ObjCountbyClass.vbs outputs. By doing so, you can determine when objects
were added and what types of objects experienced a trend in growth.
The output of ObjCountbyClass -date-time.csv, is a .CSV file, so you can view the
output with an application such as Microsoft Excel.
6. Identify a list of the objects created or modified during the timeframe determined in
step 5 by running the following command:
7. cscript ObCMAudit.vbs [/d:date] [/t:time] /h:length

Where:
o
o

date is the date when you detect the disk space attack. This parameter is
optional.
time is the time when you detect the disk space attack. This parameter is
optional.
length is the length of time, in hours, before the time you detected the disk
space attack based on the trend in the growth of the rogue objects discovered
in step 5.

For example, if you detected a disk space attack at 3:00pm on April 1, 2003, and you
thought the disk space attack took place over the last 20 hours, you would run the
following command:
Cscript ObCMAudit.vbs /d:04-01-2003 /t:1500 /h:20

ObCMAudit.vbs creates an output file, ObCMAudit-date-time.csv, that contains a list

of the objects created or modified during the length of time.
8. Examine the list and look for rogue a large number of objects of the type identified in
Step 5.
The output of ObCMAudit.vbs, the Creating a List of Objects Size script is a .CSV
file, so you can export itview the output with an application such as Microsoft Excel
to a spreadsheet and examine each objects size. Look for a large number of objects of
the same object type that has experienced a trend in growth during the period of time
discovered in Step 4.
9. Based on the analysis of the list in Step 5, delete each object that seems to be a rogue
object.
If you have not been collecting periodic object counts, you can still find the first rogue object
by performing the following tasks.
1. Determine the usnCreated of the object most recently added to Active Directory.
Note: A general guideline for how to find the first rogue object follows, assuming that
you have no indication as to when the attack began. Your situation might demand
some modifications.
2. Using the LDP.exe tool, perform the following search.
3.
4.
5.
6.
7.
8.

BaseDN: Root domain

Scope: subtree
Filter: (usnCreated>=1000)
Attributes: usnCreated
Sorted: descending order of usnCreated
Paged: yes

The first item in the output contains the usnCreated value of the object most recently
added to Active Directory. Let the usnCreated value for that object be represented by
maxUsnCreated for the remainder of this procedure.
9. Examine recently created objects, and try to discern which is the first rogue object:
1. Divide maxUsnCreated by 2.
The resulting value is SearchValue. Search Active Directory for all objects that
have a usnCreated equal to or greater than SearchValue with the following
query.
BaseDN: Root domain
Scope: subtree
Filter: (usnCreated>=SearchValue)
Attributes: usnCreated, DN, objectCategory
Sorted: descending order of usnCreated
Paged: yes

2. This search generates a list of objects with a usnCreated value greater than
SearchValue. Examine each of these objects, looking for rogue objects.

3. If rogue objects are not found, continue adjusting the value of SearchValue by
dividing by two and examining the objects until you find rogue objects.
4. The first rogue object is the rogue object with the lowest usnCreated value.
After you think you have found the first rogue object, examine many objects
created before this object to ensure that it is the first rogue object.
10. Discern which objects created after the first rogue object are rogue objects and which
are legitimate.
11. Determine the usnCreated of the first rogue object (RogueObjectusnCreated), and
then create a list of objects created since the attack by performing the following
search:
12.
13.
14.
15.
16.
17.

BaseDN: Root domain

Scope: subtree
Filter: (usnCreated>=RogueObjectusnCreated)
Attributes: DN
Sorted: descending order of usnCreated
Paged: yes

18. Sort the results of this search so that child objects are listed before parents.
With the list sorted like this, you can be sure that you delete child objects before
parent objects. A parent object cannot be deleted unless all its child objects are deleted
first.
19. Examine each object that is returned in this search, looking for patterns in rogue
objects. Some patterns to look for include the following:

2.

Objects that are created with the same parent object.

Objects that have similar attributes.

Write a script that automatically deletes objects that follow the pattern for rogue
objects.
If no pattern is discernable, you may have to delete all rogue objects manually.

Accelerating the Purging of Deleted Objects (Optional)

After the objects are deleted from Active Directory, they still take up disk space until their
tombstone lifetime has expired and the garbage collection interval has passed. The tombstone
lifetime determines how long deleted objects are kept on disk until they are collected and
completely purged from the disk. The garbage collection interval determines how long the
computer waits before deleted objects are collected and completely purged from the disk,
after the tombstone lifetime has expired.
The default for this setting is 60 days; however, your organization may have previously
modified this setting. If you cannot wait for the duration of the tombstone lifetime, you can
decrease this value.

Note: If the reserve file frees up enough disk space for your network to function properly
until the tombstone lifetime expires, skip this section.
The tombstone lifetime setting and the garbage collection interval are forest-wide settings.
Do not modify them unless it is necessary to do so.
Reduce the time required to eliminate rogue objects by performing the following tasks:
1. Reduce the tombstone lifetime.
To ensure that all domain controllers are synchronized, you can reduce the tombstone
lifetime to the recommended value of 14 days. However, if your environment
demands a quicker recovery, adjust this value as necessary. Do not assign a tombstone
lifetime value that is less than the time it takes for all domain controllers in your forest
to synchronize. The minimum value allowed for the tombstone lifetime is two days.
Important: Do not decrease the value of the tombstone lifetime so that it is less than
the amount of time that it takes for all domain controllers to synchronize. To be safe,
wait for two times the maximum latency period. Otherwise, phantom objects will
result and these objects will not be garbage collected.
2. Use the LDAP tool to make the modification described below:
3. Object: cn=Directory
Service,cn=WindowsNT,cn=Service,cn=Configuration,dc=<DOMAIN>
4. ,Attribute:TombstoneLifetime Value: n days

5. Decrease the garbage collection interval to its minimum value of one hour.
6. As the tombstone lifetime expires for the deleted rogue objects, delete them
permanently as quickly as possible to free up disk space.
7. Use the LDAP tool to make the modification described below:
8. Object: cn=Directory
Service,cn=WindowsNT,cn=Service,cn=Configuration,dc=<DOMAIN>,
9. Attribute:GarbageCollection Value: 1 hour

Verifying That All Deleted Objects Have Been Purged

Once the tombstone lifetime has expired and enough time has passed for the deleted objects
to be garbage collected, check the event log for event 700. This event indicates that garbage
collection is complete and online disk defragmentation has begun.
You can increase the number of events that are logged when garbage collection is running by
modifying the entry under the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
Entry name: 6 Garbage Collection
Data type: REG_DWORD
Value: 3

Changing the value of this registry entry allows event 1646 to be logged, which is logged
after event 700. Event 1646 details how much disk space is freed during garbage collection,
and it is logged when the garbage collection process is complete.
Creating a Fresh Backup of a Clean Domain Controller
Depending on how long it takes for you to realize that an attack has occurred, it is possible
that all the backups that you have on hand contain rogue objects. Create a fresh backup as
soon as all the rogue objects are deleted from Active Directory. You can choose any clean
domain controller. Creating this backup minimizes the chances that, if you have to restore a
domain controller from backup, you will also restore the rogue objects and have to perform
this procedure again.
Recovering from an Object Growth Attack

Domain controllers are vulnerable to an attack that creates new, extraordinarily large objects
or that modifies attributes of legitimate objects, resulting in these objects becoming
extraordinarily large. After these objects are compromised and modified, they are considered
to be rogue objects.
This type of attack can cause a domain controller to run out of disk space on the databases
drive, potentially causing other legitimate object additions, modifications, or deletions to fail.
Recover from an object growth attack by performing the following tasks:
1. Delete the reserve file on all affected domain controllers.
2. Find and remove the rogue objects.
3. Create a fresh backup of a clean domain controller.
Deleting the Reserve File
If you previously added a reserve file to the Active Directory database drive, you can recover
disk space by deleting the reserve file on all affected domain controllers. Freeing up some
disk space helps your network to function during the recovery process. For information about
the reserve file, see Creating a Reserve File to Enable Recovery from Disk-Space Attacks
in Part 1, Chapter 3, of this guide.
If a reserve file does not exist, you must ascertain how you can recover disk space while the
recovery is taking place. One possibility is moving the database files on all affected domain
controllers to larger, dedicated drives.
Finding and Removing the Rogue Objects
To recover disk space, you must find the rogue objects and remove them from the database. If
the objects are created by the attacker and fulfill no useful purpose on your network, you can
delete them from the database. However, if the rogue objects are legitimate and are modified,
you can modify the objects so that the rogue object attributes are removed. When the objects
are heavily modified and you are unable to modify the objects, delete and recreate the
objects.

Remove rogue objects that have become extraordinarily large by performing the following
tasks:
1. Disconnect an affected domain controller from the network.
2. Create the ObCMAudit.vbs and ObjMemUse.vbs scripts on a workstation and copy
them to the affected domain controller. The scripts are required for rogue object
detection.
For information about how to create ObCMAudit.vbs script, see Identifying Objects
Created or Modified Within A Period of Time With ObCMAudit.vbs in Appendix B
of this guide. For information about how to create ObjMemUse.vbs script, see
Identifying Large-sized Objects with ObjMemUse.vbs in Appendix B of this guide.
3. Identify the potential rogue objects by running the following command:
4. cscript ObCMAudit.vbs [/d:date] [/t:time] /h:length

Where:
o
o

date is the date when you detect the disk space attack. This parameter is
optional.
time is the time when you detect the disk space attack. This parameter is
optional.
length is the length of time, in hours, before the time you detected the disk
space attack.

Specify a length of time, in hours, that is equal to or greater than the last two intervals
that you have for detecting disk space attack. Free disk space is monitored at specific
intervals, for example, once every hour. You want to identify objects that have been
created or modified during the last two intervals (two hours) to ensure that you
capture a sufficient number of rogue objects.
For example, if you detected a disk space attack at 3:00pm on April 1, 2003, and you
monitor disk space utilization every hour, you would run the following command:
cscript ObCMAudit.vbs /d:04-01-2003 /t:1500 /h:2

ObCMAudit.vbs creates an output file, ObCMAudit-date-time.csv, that contains a list

of the objects created or modified during the length of time.
5. Determine the size of the objects created or modified within a specific timeframe by
running the following command:
6. cscript ObjMemUse.vbs /f:input_file

Where input_file is the name of the file created by ObCMAudit.vbs in step 3.

ObjMemUse.vbs creates an output file, ObjMemeUse-date-time.csv, that contains a
list of the objects created in step 3, along with their size.
7. Examine the list, and look for rogue large objects.

The output of ObjMemeUse-date-time.csv, is a .CSV file; you can view the output
with an application such as Microsoft Excel.
8. For each object that seems to be questionably large, determine if the object should
remain in Active Directory and do one of the following:
1.

If the object should not remain in Active Directory, delete it.

If the object should stay in Active Directory, determine what has been modified in the
object that has made it very large, and modify the object so that it is an appropriate size. If the
object has been heavily modified, it might be easiest to delete the object and recreate it.
2.

Creating a Fresh Backup of a Clean Domain Controller

Depending on how long it takes for you to realize that an attack has occurred, it is possible
that all the backups that you have on hand contain rogue objects. Create a fresh backup as
soon as all the rogue objects are deleted from Active Directory. You can choose any clean
domain controller. Creating this backup minimizes the chances that, if you have to restore a
domain controller from backup, you will also restore the rogue objects and have to perform
this procedure again.
Recommendations: Recovering from Active Directory Attacks

If Active Directory is attacked in one of the methods presented in this chapter, following the
recommended recovery procedures helps to ensure that Active Directory is recovered
securely. Each attack has its own set of recommendations.
Recovering from the Physical Breach of a Domain Controller
The following table provides a checklist of recommendations for recovering from a
physically breached domain controller.
Removing the Account for the Breached Domain Controller from Active Directory
Use the NTDSUtil.exe Support Tool to remove the breached domain controller from Active
Directory.
Resetting All Service Administrator Account Passwords
Use Active Directory Users and Computers to reset all service administrator passwords.

Distribute new passwords to service administrators.

Rendering Current Ticket-Granting Tickets Invalid
Use Active Directory Users and Computers to reset the Key Distribution Service Account

(krbtgt) password twice.

Changing All User Account Passwords
Prepare for password expiration by:
Isolating the PDC emulator in its own site.
Reducing the notification delay interval for replication.
Reducing the interval for Active Directory replication between sites.
Force the expiration of all user account passwords in batches.
Reviewing the Memberships of All Service Administrator Groups
Review all users in service administrator groups and delete all users of whom you are
suspicious.
Examining Installed Software on Domain Controllers and Administrative
Workstations
Review all software installed on domain controllers and administrative workstations
looking for Trojan horses and viruses.
Run an antivirus scan.
Reviewing All Group Policy Settings and Logon Scripts
Run the Security Configuration and Analysis Tool comparing your security template to the
current settings on the domain controller. Restore template settings wherever there is
conflict.
Examine all logon scripts for evidence of tampering or code injection.
Finding and Removing Rogue User Accounts
Review all group membership, looking for accounts that might have been created by the
attacker.
Creating New Backups
Create a new backup after the recovery is complete.

Recovering from a Rogue Administrator Attack

The following table provides a checklist of recommendations for recovering from a rogue
service administrator attack.
Removing the Rogue Administrator Account from Active Directory
Use Active Directory Users and Computers to delete the rogue administrator account.
Resetting All Service Administrator Account Passwords
Use Active Directory Users and Computers to reset all service administrator passwords.

Distribute new passwords to service administrators.

Rendering Current Ticket-Granting Tickets Invalid
Use Active Directory Users and Computers to reset the Key Distribution Service Account
(krbtgt) password twice.
Changing All User Account Passwords
Prepare for password expiration by:
Directing general client requests away from the PDC emulator.
Isolating the PDC emulator in its own site.
Disabling password change forwarding to the PDC emulator.
Reducing the notification delay interval for replication.
Reducing the interval for Active Directory replication between sites.
Force the expiration of all user account passwords in batches by:
Dividing users into small batches.
Creating and running a script that expires all passwords for user accounts in that batch.
Reviewing the Memberships of All Service Administrator Groups
Review all users in service administrator groups and delete all users of whom you are
suspicious.
Examining Installed Software on Domain Controllers and Administrative

Workstations
Review all software installed on domain controllers and administrative workstations
looking for Trojan horses and viruses.
Run an antivirus scan.
Reviewing All Group Policy Settings and Logon Scripts
Run the Security Configuration and Analysis Tool comparing your security template to the
current settings on the domain controller. Restore template settings wherever there is
conflict.
Examine all logon scripts for evidence of tampering or code injection.
Finding and Removing Rogue User Accounts
Review all group membership, looking for accounts that might have been created by the
attacker.
Creating New Backups
Create a new backup after the recovery is complete.
The following table provides a checklist of recommendations for recovering from a
catastrophic forest-wide corruption.
Recovering from Catastrophic Forest-wide Corruption
Perform pre-recovery tasks.

Perform recovery tasks.

Perform post recovery tasks.

Recovering from Data Tampering by Restoring Active Directory Data
The following table provides a checklist of recommendations for recovering from data
tampering.

Performing an Authoritative Restore of Directory Objects

Choose an affected domain controller with a last known good backup and disconnect it
from the network.
Perform a normal restore the tampered data.

Perform an authoritative restore of the data.

Verify that the data is restored and reconnect the domain controller to the network.

Verify that the data is restored on all other domain controllers.

Recovering from a Rogue Object Flood Attack
The following table provides a checklist of recommendations for recovering from a rogue
object flood attack. A rogue object flood attack occurs when objects are added or modified so
that Active Directory runs out of disk space.
Deleting the Reserve File
Delete the reserve file on all affected domain controllers to free up disk space.
Creating a Backup of the Recovery Domain Controller
Create a backup of the domain controller on which you will perform the recovery.
Finding and Deleting Rogue Objects
Use the LDP.exe tool to search Active Directory for the first rogue object.

Delete rogue objects manually or with a script.

Accelerating the Purging the Rogue Objects (Optional)
Decrease the tombstone lifetime to no less than twice the maximum replication latency for
your network.

Decrease the garbage collection interval.

Wait for all deleted objects to be purged.

Verifying That All Deleted Objects Have Been Purged
Look for event 700 in the event log indicating that garbage collection is complete and
online defragmentation has been triggered.
Creating a Fresh Backup of the Clean Domain Controller
Create a new backup after the recovery is complete.
Recovering from a Rogue Object Growth Attack
The following table provides a checklist of recommendations for recovering from a rogue
object growth attack. A rogue object growth attack occurs when object attributes are added or
modified, causing the object to grow to an extraordinarily large size, so that Active Directory
runs out of disk space.
Deleting the Reserve File
Delete the reserve file on all affected domain controllers to free up disk space.
Finding and Deleting Rogue Objects
Disconnect an affected domain controller from the network.
Create the ObCMAudit.vbs and ObjMemUse.vbs scripts on a workstation and copy them
to the affected domain controller.
Create a list of potential rogue objects by running the ObCMAudit.vbs script.

Determine the size of each object listed by running the ObMemUse.vbs script.

Examine the object sizes, modifying or deleting rogue objects.

Creating a Fresh Backup of the Clean Domain Controller

Create a new backup after the recovery is complete.

Top of page
Appendix A: Overloading the PDC Emulator

The PDC emulator maintains the authoritative list of account passwords. In the default
configuration, when a user changes the account password, the domain controller that
processed the password change immediately forwards the new password to the PDC
emulator.
When you force passwords to expire in response to a domain controller breach, thousands of
users might change their passwords at the same time. Resetting all these passwords at once
would result in thousands of password updates being forwarded to the PDC emulator,
potentially overloading the PDC emulator.

Figure 7: Overloading the PDC Emulator with Password Changes

All other domain controllers receive new password information through normal replication.
As a result, after an initial password change, there is some latency before the other domain
controllers receive new passwords. This behavior only presents a problem if NTLM is used
for authentication. If a user attempts to log on to another computer or access a network
resource with the new password during this window, the password information provided by
the user does not match the password information stored on the authenticating domain
controller. Realizing that its password information could be obsolete, the authenticating
domain controller contacts the PDC emulator to attempt to verify the provided password. If
thousands of users are all doing this simultaneously, the PDC emulator might not be able to
accommodate all of the requests. These requests might eventually time-out, resulting in the
user being denied access to the computer or network resource.

Figure 8: Accessing Network Resources Immediately After a Password

Change

The steps involved in accessing a network resource after a password change, but before that
password has replicated to all domain controllers in environments where NTLM is used are
as follows. When a user attempts to access a network resource, the resource contacts a
domain controller to authorize the access. If the domain controller cannot verify the clients
identity (because the password has changed), then it contacts the PDC emulator to check for
an updated password (3). PDC emulator verifies the clients identity and forwards this
information to the domain controller (4) where the users password is updated. The domain
controller then contacts the network resource (5) and allows access if the password provided
was correct and if the user has the permissions to access the resource. The network resource
in turn forwards the requested information to the client (6).
If all users change their passwords at once and then attempt to log on or access a network
resource, the PDC emulator can become overloaded.
With Kerberos, access to network resources is not directly determined by users passwords.
Instead, access is granted based on session tickets. When a user logs on and Kerberos is used
for authentication, the domain controller sends a ticket-granting ticket (TGT) to the client.
When the client attempts to access a resource, the client presents the TGT to a domain
controller. If the TGT is valid, the domain controller returns a session ticket which the client
then sends to the network resource.
Top of page
Appendix B: Procedures
Applying Registry Settings to a List of Computers With ApplyReg.vbs

You can use the ApplyReg.vbs script to apply registry settings to the computers you identified
by using the SearchComputers.vbs script. Before you can use the ApplyReg.vbs script, you
must create the script based on the source code included in this document.

Note: This script requires Windows 2000 with Service Pack 3 or later and Windows Scripting
Host version 5.6 or later.
The ApplyReg.vbs script has the following syntax:
cscript ApplyReg.vbs /r:registry_file /f:computer_file

Where:

registry_file is a .REG file that was created by using Regedit.exe.

computer_file is a .CSV file that was created manually or by using
SearchComputers.vbs.

ApplyReg.vbs applies the registry settings specified in registry_file to each computer

specified in computer_file.
To create the ApplyReg.vbs script
1. Open Notepad
2. Copy or type the following script into Notepad
3. ''Add computer can't be found in AD when the binding operation fails
4. '********************************************************************
******
5. '* File:
ApplyReg.vbs
*
6. '* Created:
April 2003
*
7. '* Version:
1.0
*
8. '*
*
9. '* Description:
Utility that applies the contents of a .reg file
to
*
10. '*
the registry of each available and accessible
*
11. '*
computer specified in the csv report created by
the
*
12. '*
ComputerSearch.vbs script.
*
13. '*
This script generates a report that includes
the
*
14. '*
name of each computer where the .reg file
import
*
15. '*
was attempted and whether the application was
*
16. '*
successful at applying the change.
*
17. '*
*
18. '* Compatibility: This script requires WSH 5.6, CScript, ADSI,
WMI
*
19. '*
and access to Active Directory
*
20. '******************************************************************
********

21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.

Option Explicit
'Define constants
Const ForReading = 1
Const TristateUseDefault = -2
Const ForAppending = 8
'Declare global variables
Dim objArgs,strRptFileName,strRegFileName
Dim objDictionary,strFileName,objFSO,objFile,objRegFile
Dim objRptFile,objRegExp,objShell,iRecord,strLine
Dim arrComptInfo,strDN,strComputer,strNotes
Dim objExec,strPingStdOut,objRegistry
Dim objTextStream,ColRootKey,Key,strKey,strKeyPath
Dim strStatus,iCnt
Call CheckForCScript()
'Use Named Arguments collection for the command line argument.
'The WSHArguments Object is included in WSH version 5.6 and later
Set objArgs = WScript.Arguments.Named
strRptFileName = objArgs.Item("f")
strRegFileName = objArgs.Item("r")
If WScript.Arguments.Named.Count < 2 Then
WScript.Echo "You must specify a csv file name " & VBCrLf & _
"of a file created by ComputerSearch.vbs and " & VbCrLf & _
"the name of the .reg file to apply." & VbCrLf & VbCrLf & _
SampleCommandLine()
WScript.Quit
End If
'Use a dictionary object for the constants that define
'the root keys
Set objDictionary = CreateObject("Scripting.Dictionary")
objDictionary.Add "HKEY_LOCAL_MACHINE",&h80000002
objDictionary.Add "HKEY_CLASSES_ROOT",&h80000000
objDictionary.Add "HKEY_CURRENT_USER",&h80000001
objDictionary.Add "HKEY_USERS",&h80000003
objDictionary.Add "HKEY_CURRENT_CONFIG",&h80000005
'Call the GenFileName function to create a unique file name for the
report
56. strFileName = GenFileName("ApplyReg")
57. 'Create a text file (.csv format) to hold the
58. 'results of the report.
59. Set objFSO = CreateObject("Scripting.FileSystemObject")
60. 'This will overwrite the file if it already exists.
61. Set objFile = objFSO.CreateTextFile(strFileName,True)
62. objFile.Close
63. Set objFile = objFSO.OpenTextFile(strFileName,ForAppending)
64. 'Write the headings for this csv file
65. objFile.WriteLine "DistinguishedName," & _
66.
"Computer Name,Status,Notes"
67. 'Get the registry file
68. Set objRegFile = objFSO.GetFile(strRegFileName)
69. 'Open the computer search report file for reading
70. Set objRptFile = objFSO.OpenTextFile(strRptFileName,ForReading)
71. 'Skip the header row of the report
72. objRptFile.SkipLine
73. 'Create the Regular Expression object
74. Set objRegExp = New RegExp
75. 'Set some global properties for the RegExp object
76. objRegExp.IgnoreCase = FALSE
77. objRegExp.Global = TRUE
78. objRegExp.MultiLine = FALSE
79. 'Create the Wscript.Shell object for accessing the Exec method
80. Set objShell = CreateObject("WScript.Shell")

81. iRecord = 1
82. WScript.Echo "Report records processed: "
83. Do While objRptFile.AtEndOfStream <> TRUE
84.
strLine = objRptFile.ReadLine
85.
'Bind to dn of a computer listed in the report file.
86.
arrComptInfo = Split(BindDN(strLine),"||")
87.
strDN = arrComptInfo(0)
88.
strComputer = arrComptInfo(1)
89.
'An invalid dn is specified in the report file
90.
If strComputer = "None" Then
91.
strNotes = arrComptInfo(2) & " distinguished name specified"
92.
strStatus = "Unable to connect to the specified dn."
93.
Else
94.
strNotes = arrComptInfo(2) & " name used for remote
connection."
95.
'Before connecting to the computer, use ping to see if you get
a response.
96.
'A WMI connection attempt is not used because WMI's connection
timeout interval
97.
'is too long
98.
Set objExec = objShell.Exec("ping -n 2 -w 1000 " & strComputer)
99.
strPingStdOut = LCase(objExec.StdOut.ReadAll)
100.
'Test whether ping was successful
101.
If InStr(strPingStdOut, "reply from ") Then
102.
'Attempt to connect to the registry provider on a remote
computer
103.
Set objRegistry=GetObject("winmgmts:
{impersonationLevel=impersonate}!\\" &_
104.
strComputer & "\root\default:StdRegProv")
105.
On Error Resume Next
106.
If Err.Number <> 0 Then
107.
'Store the following line to write to the status column
for this computer.
108.
'Typical causes of failure:
109.
'WMI not running or operator does not have permission to
make a remote connection.
110.
strStatus = Err.Description
111.
Err.Clear
112.
On Error GoTo 0
113.
Else
114.
'Perform the registry update
115.
Set objTextStream =
objRegFile.OpenAsTextStream(ForReading, TristateUseDefault)
116.
Do While objTextStream.AtEndOfStream <> TRUE
117.
'Read a line of data
118.
strLine = objTextStream.ReadLine
119.
'Match root keys and paths
120.
objRegExp.Pattern = "(^\[HKEY_\w+[^\\])(.*)"
121.
If objRegExp.Test(strLine) = TRUE Then 'Create the key
122.
Set ColRootKey = objRegExp.Execute(strLine)
123.
For Each Key in ColRootKey
124.
strKey = Mid(Key.SubMatches(0),2)
125.
strKeyPath =
Mid(Key.SubMatches(1),2,Len(Trim(Key.SubMatches(1)))-2)
126.
objRegistry.CreateKey
objDictionary(strKey),strKeyPath
127.
Next
128.
Else 'Create value names and values for the key
129.
'Match strings: "valuename"="value"
130.
objRegExp.Pattern = "(\x22.*\x22=\x22)(.*)"
131.
If objRegExp.Test(strLine) = TRUE Then

132.
Call CreateString(strLine)
133.
End If
134.
'Match Binary data: "valuename"=hex:
135.
objRegExp.Pattern = "(\x22.*\x22=hex:)(.*)"
136.
If objRegExp.Test(strLine) = TRUE Then
137.
Call CreateBinary(strLine)
138.
End If
139.
'Match DWORD data: "valuename"=dword:
140.
objRegExp.Pattern = "(\x22.*\x22=dword:)(.*)"
141.
If objRegExp.Test(strLine) = TRUE Then
142.
Call CreateDWORD(strLine)
143.
End If
144.
'Match Expandable string: "valuename"=hex(2):
145.
objRegExp.Pattern = "(\x22.*\x22=hex\(2\):)(.*)"
146.
If objRegExp.Test(strLine) = TRUE Then
147.
Call CreateExpString(strLine)
148.
End If
149.
'Match Multistring: "valuename"=hex(7):
150.
objRegExp.Pattern = "(\x22.*\x22=hex\(7\):)(.*)"
151.
If objRegExp.Test(strLine) = TRUE Then
152.
Call CreateMultiString(strLine)
153.
End If
154.
'The registry Key pattern is true. Therefore, the script
has encountered
155.
'another registry key to apply.
156.
End If
157.
Loop
158.
strStatus = "Registry update applied."
159.
End If
160.
Else
161.
'Store the following line to write to the status and notes
columns for this computer
162.
strStatus = "Host unreachable"
163.
strNotes = "Verify that this host is online."
164.
End If
165.
End If
166.
objFile.WriteLine Chr(34) & strDN & Chr(34) & "," & strComputer &
_
167.
"," & strStatus & "," & strNotes
168.
'Display a record counter
169.
For iCnt = 1 to Len(iRecord)
170.
WScript.StdOut.Write Chr(8)
171.
Next
172.
WScript.StdOut.Write iRecord
173.
iRecord = iRecord + 1
174. Loop
175. WScript.Echo VbCrLf & VbCrLf & "The report data has been saved to:
" & _
176. strfileName & "." & VbCrLf & _
177. "Import or open the CSV data in a spreadsheet" & VbCrLf & _
178. "or database program to determine which computers were updated."
179. '******************************************************************
****
180. '* Routine: CreateString
181. '******************************************************************
****
182. Sub CreateString(Line)
183.
Dim ColEntries,Entry,strValueName,strValue
184.
Set ColEntries = objRegExp.Execute(Line)
185.
For Each Entry in ColEntries

186.
strValueName =
Mid(Entry.SubMatches(0),2,Len(Trim(Entry.Submatches(0)))-4)
187.
strValue =
Mid(Entry.SubMatches(1),1,Len(Trim(Entry.Submatches(1)))-1)
188.
objRegistry.SetStringValue
objDictionary(strKey),strKeyPath,strValueName,strValue
189.
Next
190. End Sub
191. '******************************************************************
****
192. '* Routine: CreateBinary
193. '******************************************************************
****
194. Sub CreateBinary(Line)
195.
Dim arrValue(),ColEntries,Entry,strValueName,arrHexValue,i,HexVal
196.
Set ColEntries = objRegExp.Execute(Line)
197.
For Each Entry in ColEntries
198.
strValueName =
Mid(Entry.SubMatches(0),2,Len(Trim(Entry.Submatches(0)))-7)
199.
'Use the split function to create an array so that each hex
value can be
200.
'appended with an &h value in the next For Each statement
201.
arrHexValue = Split(Trim(Entry.SubMatches(1)),",")
202.
'Declare a dynamic array to hold the properly formatted hex
values to
203.
'be passed to the WMI SetBinaryValue method.
204.
i=0
205.
For Each HexVal in arrHexValue
206.
Redim Preserve arrValue(i)
207.
arrValue(i) = "&h" & HexVal
208.
i=i + 1
209.
Next
210.
objRegistry.SetBinaryValue
objDictionary(strKey),strKeyPath,strValueName,arrValue
211.
Redim arrValue(0)
212.
Next
213. End Sub
214. '******************************************************************
****
215. '* Routine: CreateDWORD
216. '******************************************************************
****
217. Sub CreateDWORD(Line)
218.
Dim ColEntries,Entry,strValueName,intValue
219.
Set ColEntries = objRegExp.Execute(Line)
220.
For Each Entry in ColEntries
221.
strValueName =
Mid(Entry.Submatches(0),2,Len(Trim(Entry.Submatches(0)))-9)
222.
'Convert the hex value that will be passed to the WMI
223.
'SetDWORDValue method, to a decimal data type
224.
intValue = CInt("&h" & Trim(Entry.SubMatches(1)))
225.
objRegistry.SetDWORDValue
objDictionary(strKey),strKeyPath,strValueName,intValue
226.
Next
227. End Sub
228. '******************************************************************
****
229. '* Routine: CreateExpString
230. '******************************************************************
****
231. Sub CreateExpString(Line)

232.
Dim arrValue(),ColEntries,Entry,strValueName,strValueFirstLine
233.
Dim
strValueMiddleLines,strValueLastLine,strExpandableString,HexVal
234.
Dim strExpandableStringFormatted,arrItems
235.
Set ColEntries = objRegExp.Execute(Line)
236.
For Each Entry in ColEntries
237.
strValueName =
Mid(Entry.SubMatches(0),2,Len(Trim(Entry.Submatches(0)))-10)
238.
strValueFirstLine = Trim(Entry.SubMatches(1))
239.
Next
240.
'Read another line to test for data that might belong to an
expandable string entry
241.
strLine = objTextStream.ReadLine
242.
'Match additional lines of expandable-string data:
nn,nn,nn...\
243.
objRegExp.Pattern = "(^\s{2}[0-9{1,2}|a-f{1,2},]+\\$)"
244.
Do While objRegExp.Test(strLine) = TRUE
245.
Set ColEntries = objRegExp.Execute(strLine)
246.
For Each Entry in ColEntries
247.
strValueMiddleLines = strValueMiddleLines &
Trim(Entry.SubMatches(0))
248.
Next
249.
'Read another line to test for data that might belong to the
middle lines of
250.
'an expandable string entry
251.
strLine = objTextStream.ReadLine
252.
Loop
253.
'Match the last line of a expandable-string expression
254.
objRegExp.Pattern = "(^\s{2}[0-9{1,2},|a-f{1,2},]+[0-9{1,2}$|af{1,2}$])"
255.
If objRegExp.Test(strLine) Then
256.
Set ColEntries = objRegExp.Execute(strLine)
257.
For Each Entry in ColEntries
258.
strValueLastLine = Trim(Entry.SubMatches(0))
259.
Next
260.
End If
261.
'Combine the expandable-string value
262.
strExpandableString = strValueFirstLine & strValueMiddleLines &
strValueLastLine
263.
'Remove the "\" character from strExpandableStringValue
264.
objRegExp.Pattern = "\\"
265.
strExpandableStringFormatted =
objRegExp.Replace(strExpandableString,"")
266.
'Convert to an array for formatting each value
267.
arrItems = Split(strExpandableStringFormatted,",")
268.
For Each HexVal in arrItems
269.
Redim Preserve arrValue(i)
270.
If HexVal <> "00" Then
271.
arrValue(i) = CStr(Chr(CInt("&h" & HexVal)))
272.
strData = strData & arrValue(i)
273.
i= i + 1
274.
End If
275.
Next
276.
'Add the expandable string to the registry
277.
objRegistry.SetExpandedStringValue
objDictionary(strKey),strKeyPath,strValueName,strData
278. End Sub
279. '******************************************************************
****
280. '* Routine: CreateMultiString
281. '******************************************************************
****

282. Sub CreateMultiString(Line)

283.
Dim arrArgData(),ColEntries,Entry,strValueName,strValueFirstLine
284.
Dim strValueMiddleLines,strValueLastLine,strMultiString
285.
Dim strMultiStringFormatted,arrLine,iArgs
286.
Dim HexVal,arrItems,arrValue,strData
287.
Set ColEntries = objRegExp.Execute(Line)
288.
For Each Entry in ColEntries
289.
strValueName =
Mid(Entry.SubMatches(0),2,Len(Trim(Entry.Submatches(0)))-10)
290.
strValueFirstLine = Trim(Entry.SubMatches(1))
291.
Next
292.
'Read another line to test for data that might belong to a
multistring entry
293.
strLine = objTextStream.ReadLine
294.
'Match additional lines of multi-string data:
nn,nn,nn...\
295.
objRegExp.Pattern = "(^\s{2}[0-9{1,2}|a-f{1,2},]+\\$)"
296.
Do While objRegExp.Test(strLine) = TRUE
297.
Set ColEntries = objRegExp.Execute(strLine)
298.
For Each Entry in ColEntries
299.
strValueMiddleLines = strValueMiddleLines &
Trim(Entry.SubMatches(0))
300.
Next
301.
'Read another line to test for data that might belong to the
middle
302.
'lines of a multistring entry
303.
strLine = objTextStream.ReadLine
304.
Loop
305.
'Match the last line of a Multistring expression
306.
objRegExp.Pattern = "(^\s{2}[0-9{1,2},|a-f{1,2},]+[0-9{1,2}$|af{1,2}$])"
307.
If objRegExp.Test(strLine) Then
308.
Set ColEntries = objRegExp.Execute(strLine)
309.
For Each Entry in ColEntries
310.
strValueLastLine = Trim(Entry.SubMatches(0))
311.
Next
312.
End If
313.
'Combine the expandable-string value
314.
strMultiString = strValueFirstLine & strValueMiddleLines &
strValueLastLine
315.
'Remove the "\" character from strMultiStringValue
316.
objRegExp.Pattern = "\\"
317.
strMultiStringFormatted = objRegExp.Replace(strMultiString,"")
318.
'Each line is delimited by "00,00,00". Create seperate strings
for each line.
319.
'Each line is an argument in the array supplied to the
SetMultiStringValue method.
320.
arrLine = Split(strMultiStringFormatted,"00,00,00")
321.
iArgs = 0
322.
'Convert each item in each line to string data
323.
For Each Line in arrLine
324.
If Line <> "" AND Trim(Line) <> "," Then
325.
'Remove commas padding the beginning and/or the end.
326.
If Instr(1,Line,",") = 1 Then
327.
Line = Mid(Line,2)
328.
End If
329.
If Instr(Len(Line),Line,",") = Len(Line) Then
330.
Line = Mid(Line,1,Len(Line) - 1)
331.
End If
332.
'Split each item in each line for conversion.
333.
arrItems = Split(Line,",")
334.
i=0

335.
'Convert each hex value to character data.
336.
For Each HexVal in arrItems
337.
Redim Preserve arrValue(i)
338.
If HexVal <> "00" Then
339.
arrValue(i) = CStr(Chr(CInt("&h" & HexVal)))
340.
strData = strData & arrValue(i)
341.
i= i + 1
342.
End If
343.
Next
344.
Redim Preserve arrArgData(iArgs)
345.
arrArgData(iArgs) = strData
346.
strData = ""
347.
iArgs = iArgs + 1
348.
End If
349.
Next
350.
objRegistry.SetMultiStringValue
objDictionary(strKey),strKeyPath,strValueName,arrArgData
351.
Redim arrArgData(0)
352. End Sub
353. '******************************************************************
****
354. '* Routine: CheckForCScript
355. '******************************************************************
****
356. Sub CheckForCScript
357.
'This script must run from cscript because
358.
'it uses the WScript.StdOut property.
359.
'Test the script host and if it's not cscript,
360.
'instruct the operator on how to run the script.
361.
If Right(LCase(WScript.FullName),11) <> LCase("cscript.exe") Then
362.
WScript.Echo "This script must run from cscript." & _
363.
VbCrLf & "Example: cscript ApplyReg.vbs /f:ComptSearch.csv
/r:RegFile.reg"
364.
WScript.Quit
365.
End If
366. End Sub
367. '******************************************************************
****
368. '* Function: PadZero
369. '******************************************************************
****
370. Function PadZero(dtValue)
371.
If Len(dtValue) = 1 Then
372.
PadZero = 0 & dtValue
373.
Else
374.
PadZero = dtValue
375.
End If
376. End Function
377. '******************************************************************
****
378. '* Function: GenFileName
379. '******************************************************************
****
380. Function GenFileName(prefix)
381.
'Create a unique time stamped name for the text file
382.
Dim dtDate,strYear,strMonth,strDay,strDate
383.
Dim dtNow,strHour,strMinute,strSecond,strTime
384.
dtDate = Date()
385.
strYear = Mid(Year(dtDate),3)
386.
strMonth = PadZero(Month(dtDate))
387.
strDay = PadZero(Day(dtDate))

388.
strDate = strYear & strMonth & strDay & "-"
389.
dtNow = Now()
390.
strHour = PadZero(Hour(dtNow))
391.
strMinute = PadZero(Minute(dtNow))
392.
strSecond = PadZero(Second(dtNow))
393.
strTime = strHour & strMinute & strSecond
394.
GenFileName = prefix & "-" & strDate & strTime & ".csv"
395. End Function
396. '******************************************************************
****
397. '* Function: SampleCommandLine
398. '******************************************************************
****
399. Function SampleCommandLine()
400.
SampleCommandLine = _
401.
"For example, to apply registry changes specified in" & VbCrLf
& _
402.
"a file named SysAdmin.reg, to all computers listed in" &
VbCrLf & _
403.
"ComptSearch.csv, type:" & VbCrLf & _
404.
"CScript ApplyReg.vbs /r:SysAdmin.reg /f:ComptSearch.csv"
405. End Function
406. '******************************************************************
****
407. '* Function: BindDN
408. '******************************************************************
****
409. Function BindDN(Line)
410.
Const E_ADS_PROPERTY_NOT_FOUND = &h8000500D
411.
Const LDAP_NO_SUCH_OBJECT = &h80072030
412.
Dim strDN,objComputer,strComptName
413.
'Use Instr to get the distinguishedName column for writing to the
414.
'first column of the report.
415.
strDN = Mid(Line,2,Instr(1,Line,Chr(34) & Chr(44))-2)
416.
'Bind to the computer in AD
417.
On Error Resume Next
418.
Set objComputer = GetObject("LDAP://" & strDN)
419.
If Err.Number = LDAP_NO_SUCH_OBJECT Then
420.
'The GetObject method was unable to bind to the specified
421.
'dn. This probably means the computer is not listed in AD.
422.
BindDN = strDN & "||None||Invalid"
423.
Else
424.
'Get the dNSHostName of the computer
425.
strComptName = objComputer.Get("dNSHostName")
426.
'If the dNSHostName attribute is set, use it for the registry
update.
427.
If Err.number <> E_ADS_PROPERTY_NOT_FOUND Then
428.
BindDN = strDN & "||" & strComptName & "||Host"
429.
Err.Clear
430.
'If the dNSHostName attribute is not set then use
431.
'the cn for the registry update.
432.
Else
433.
strComptName = objComputer.Get("cn")
434.
BindDN = strDN & "||" & strComptName & "||NetBIOS"
435.
End If
436.
End If
437.
Err.Clear
438.
On Error GoTo 0
439. End Function

440.

Save the file as ApplyReg.vbs

Analyzing Current Security Settings

This tool creates a log file with the current security configuration of the computer analyzed.
Requirements

Credentials: Domain Admins or Enterprise Admins

To analyze the current security settings:

1. Open Security Configuration and Analysis administrative tool.
2. In the console tree, right-click Security Configuration and Analysis and then click
Open Database.
If you are creating a new database:
1. For File name, type FileName and then click Open.
2. Select a template and then click Open.
3. If you are opening an existing database, select the database and then click Open.
4. In the details pane, right-click Security Configuration and Analysis, and then click
Analyze Computer Now.
5. Do one of the following:
1. To use the default log, in Error log file path, click OK.
2. To specify a different log, in Error log file path, type a valid path and file
name.
Changing the Priority for DNS SRV Records

Perform this procedure to raise the priority for the PDC emulators DNS SRV records in the
domain where you are expiring all user passwords. Use Regedit.exe to perform this
procedure.
Requirements

Credentials: Domain Admins or Enterprise Admins

To change the priority of a domain controller

1. On the PDC emulator, in the Run dialog box, type regedit, and press ENTER.
2. In the registry editor, navigate to
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Click Edit, click New, and then click DWORD value.
4. For the new value name, type LdapSrvPriority, and press ENTER.

5. Double-click the value name that you just typed to open the Edit DWORD Value
dialog box.
6. Enter a value from 0 through 65535. The default value is 0. The higher the value that
you choose relative to the other domain controllers in the domain, the less likely that
this domain controller will be contacted.
7. Choose Decimal as the Base option.
8. Click File, and then click Exit to close the registry editor.
Important: For this setting to take effect, you must stop and restart the Netlogon service on
the PDC emulator. To stop the Netlogon service, at the command line type net stop
netlogon. To restart the Netlogon service, at the command line, type net start netlogon.
Changing the Weight for DNS SRV Records

Perform this procedure to lower the weight of the PDC emulators DNS SRV records in the
domain where you are expiring all user passwords. Use Regedit.exe to perform this
procedure.
Requirements

Credentials: Domain Admins or Enterprise Admins

To change the weight of the PDC emulators DNS SRV Record:

1. On the PDC emulator, in the Run dialog box, type regedit, and press ENTER.
2. In the registry editor, navigate to
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.
3. Click Edit, click New, and then click DWORD value.
4. For the new value name, type LdapSrvWeight and press ENTER. (The value name is
not case sensitive.)
5. Double-click the value name you just typed to open the Edit DWORD Value dialog
box.
6. Enter a value from 0 through 65535. The default value is 100. The lower the value
that you choose relative to the other domain controllers in the domain, the less likely
that this domain controller will be contacted.
7. Choose Decimal as the Base option.
8. Click File, and then click Exit to close the registry editor.
Important: For this setting to take effect, you must stop and restart the Netlogon service on
the PDC emulator. To stop the Netlogon service, at the command line type net stop
netlogon, To restart the Netlogon service, at the command line, type net start netlogon.

Converting the GUID of a GPO to a Friendly Name

When an event log entry is generated because a GPO is modified, the GUID of the GPO that
is modified is listed in the Description field of the event. You can determine the friendly
name of the GPO from the GUID. The friendly name is the name that is show in consoles,
such as Active Directory Users and Computers.
Requirements

Credentials: Domain Admins

Tools: Ldifde.exe, Notepad.exe

To convert the GUID of a GPO to a friendly name

1. Find the event in the event log for the modification of the GPO.
2. Double-click the event entry in the log.
3. Click the copy button on the event, illustrated in Figure 7.

Figure 9: GPO Modification Event

4. Start Notepad.exe.
5. Paste the event copied in Step 3 into Notepad.
6. At a command prompt, type the following without pressing ENTER:
7. ldifde -f output.txt -d "<domain>" -r "cn=<guid>)" -l displayName,cn

8. Paste the GUID from Notepad to <guid> in the command line, and then press
ENTER.
The following in an example of how the command line appears after pasting the
GUID from Notepad:
ldifde -f output.txt -d "DC=corp,DC=contoso,DC=com" -r
"cn={31B2F340-016D-11D2-945F-00C04FB984F9})" -l displayName,cn

9. Open output.txt to view the friendly name of the GPO.

Forcing Password Expiration Using a Script

Forcing the expiration of all user account passwords and then manually resetting the
passwords would be impractical in any but a very small organization. For larger
organizations, consider forcing the expiration of user account passwords with a script like the
one provided below.
Description
This script forces users to change their account passwords the next time they logon.
Script Code
Set objConnection = CreateObject("ADODB.Connection")
objConnection.Open "Provider=ADsDSOObject;"
Set objCommand = CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
objCommand.CommandText = _
"<LDAP://ou=Management,dc=NA,dc=fabrikam,dc=com>;" & _
"(&(objectCategory=Person)(objectClass=user));" & _
"ADsPath;subtree"
Set objRecordSet = objCommand.Execute
While Not objRecordset.EOF
strADsPath = objRecordset.Fields("ADsPath")
Set objUser = GetObject(strADsPath)
objUser.Put "pwdLastSet", 0
objUser.SetInfo
objRecordSet.MoveNext
Wend
WScript.Echo objRecordSet.RecordCount & _
" user account objects must change the " & _
"password at next logon."
objConnection.Close

Disclaimer
The sample scripts are not supported under any Microsoft standard support program or
service. The sample scripts are provided AS IS without warranty of any kind. Microsoft
further disclaims all implied warranties including, without limitation, any implied warranties
of merchantability or of fitness for a particular purpose. The entire risk arising out of the use
or performance of the sample scripts and documentation remains with you. In no event shall
Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the
scripts be liable for any damages whatsoever (including, without limitation, damages for loss
of business profits, business interruption, loss of business information, or other pecuniary
loss) arising out of the use of or inability to use the sample scripts or documentation, even if
Microsoft has been advised of the possibility of such damages.

Identifying Computers to Receive New Registry Settings with

ComputerSearch.vbs

You can use the ComputerSearch.vbs script to help identify computers objects in Active
Directory so that you can subsequently apply registry settings to the list of computers
identified by ComputerSearch.vbs. Before you can use the ComputerSearch.vbs script, you
must create the script based on the source code included in this document.
Note: This script requires Windows 2000 with Service Pack 3 or later and Windows Scripting
Host version 5.6 or later.
The ComputerSearch.vbs script has the following syntax:
cscript ComputerSearch.vbs [/r:role]

Where role can be DC for domain controllers or MC for member computers.

If you omit role, then ComputerSearch.vbs will return both domain controllers and member
computers.
ComputerSearch.vbs creates an output file, ComputerSearch-date-time.csv, which contains a
list of the computer objects found in Active Directory.
To create the ComputerSearch.vbs script
1. Open Notepad
2. Copy or type the following script into Notepad
3. '********************************************************************
******
4. '* File:
ComputerSearch.vbs
*
5. '* Created:
March 2003
*
6. '* Version:
1.0
*
7. '*
*
8. '* Description:
Diagnostic utility that returns a report
containing
*
9. '*
the distinguished names of computers in the
domain
*
10. '*
(domain controllers, member computers or both).
This *
11. '*
report can be viewed in a spreadsheet or
database
*
12. '*
program and it can be read by ApplyReg.vbs to
apply
*
13. '*
registry changes to all the computers listing
in
*
14. '*
the report.
*
15. '*
*

16. '* Compatibility: This script requires WSH 5.6, CScript, ADSI,
*
17. '*
and access to Active Directory
*
18. '******************************************************************
********
19. Option Explicit
20. 'Define any constants used in this script
21. 'Denotes a workstation:
22. Const ADS_UF_WORKSTATION_TRUST_ACCOUNT = &h1000
23. 'Denotes a DC:
24. Const ADS_UF_SERVER_TRUST_ACCOUNT = &h2000
25. Const ForAppending = 2
26. Dim objArgs,strRole
27. Dim objRootDSE,strDomain
28. Dim objConnection,objCommand,objRecordSet
29. Dim strFileName,objFSO,objFile
30. Call CheckForCScript
31. 'Use Named Arguments collection for the command line argument.
32. 'The WSHArguments Object is included in WSH version 5.6 and later
33. Set objArgs = WScript.Arguments.Named
34. strRole = UCase(objArgs.Item("r"))
35. If WScript.Arguments.Named.Count < 1 Then
36.
WScript.Echo "No role was specified on the command-line." &
VbCrLf & _
37.
"Therefore, the report will list both domain controller and" &
VbCrLf & _
38.
"member computers in the domain." & VbCrLf & _
39.
"Possible roles are: dc (domain controller) or mc (member
computer)."
40. End If
41. If WScript.Arguments.Named.Exists("r") Then
42.
If strRole <> "DC" AND strRole <> "MC" Then
43.
WScript.Echo SampleCommandLine()
44.
WScript.Quit
45.
End If
46. End If
47. 'Use the RootDSE object for upcoming search operation
48. Set objRootDSE = GetObject("LDAP://rootDSE")
49. 'Bind to the current domain
50. 'Use to specify the search base for the LDAP search
51. strDomain = "<LDAP://" & _
52.
objRootDSE.Get("defaultNamingContext") & ">"
53. Set objConnection = CreateObject("ADODB.Connection")
54. objConnection.Open "Provider=ADsDSOObject;"
55. Set objCommand = CreateObject("ADODB.Command")
56. objCommand.ActiveConnection = objConnection
57. objCommand.CommandText = strDomain & _
58.
";(objectCategory=computer);" & _
59.
"distinguishedName,userAccountControl;subtree"
60.
'"distinguishedName,userAccountControl,samAccountName,dNSHostName;sub
tree"
61. 'Specify page size for this command object.
62. 'This is necessary to avoid overutilization of server
63. 'and network resources. Also, by default,
64. 'only 1000 records will be returned if paging isn't
65. 'specified. The domain might contain more
66. 'than 1000 computer objects.
67. objCommand.Properties("Page Size") = 256
68. objCommand.Properties("Asynchronous") = True

69.
70.
71.
72.

objCommand.Properties("Cache results") = False

'Run the computer object query
Set objRecordSet = objCommand.Execute
'Create a unique file name (timestamp) using the GenFileName
function
73. strFileName = GenFileName("ComputerSearch")
74. 'Create a text file (.csv format) to hold the
75. 'results of the class test.
76. Set objFSO = CreateObject("Scripting.FileSystemObject")
77. 'This will overwrite the file if it already exists.
78. Set objFile = objFSO.CreateTextFile(strFileName,True)
79. objFile.Close
80. Set objFile = objFSO.OpenTextFile(strFileName,ForAppending)
81. Call PopulateReport
82. objConnection.Close
83. WScript.Echo VbCrLf & "The report data has been saved to: " &
strfileName & "."
84. '******************************************************************
****
85. '* Routine: PopulateReport
86. '******************************************************************
****
87. Sub PopulateReport
88.
On Error Resume Next
89.
Dim strRecord,iCnt,i
90.
i=0
91.
ObjFile.WriteLine "distinguishedName,Role"
92.
While Not objRecordset.EOF
93.
If strRole = "" Then
94.
If ADS_UF_SERVER_TRUST_ACCOUNT AND
objRecordset.Fields("userAccountControl") Then
95.
strRecord = GenRecord & "Domain Controller"
96.
objFile.WriteLine strRecord
97.
i=i+1
98.
ElseIf ADS_UF_WORKSTATION_TRUST_ACCOUNT AND
objRecordset.Fields("userAccountControl") Then
99.
strRecord = GenRecord & "Workstation or Server"
100.
objFile.WriteLine strRecord
101.
i=i+1
102.
End If
103.
ElseIf strRole = "DC" Then
104.
If ADS_UF_SERVER_TRUST_ACCOUNT AND
objRecordset.Fields("userAccountControl") Then
105.
strRecord = GenRecord & "Domain Controller"
106.
objFile.WriteLine strRecord
107.
i=i+1
108.
End If
109.
ElseIf strRole = "MC" Then
110.
If ADS_UF_WORKSTATION_TRUST_ACCOUNT AND
objRecordset.Fields("userAccountControl") Then
111.
strRecord = GenRecord & "Workstation or Server"
112.
objFile.WriteLine strRecord
113.
i=i+1
114.
End If
115.
End If
116.
'Progress indicator
117.
For iCnt = 1 to Len(i) + 35
118.
WScript.StdOut.Write Chr(8)
119.
Next
120.
WScript.StdOut.Write "Current number of computers found: " &
i

121.
objRecordset.MoveNext
122.
Wend
123. End Sub
124. '******************************************************************
****
125. '* Routine: CheckForCScript
126. '******************************************************************
****
127. Sub CheckForCScript
128.
'This script must run from cscript because
129.
'it uses the WScript.StdOut property.
130.
'Test the script host and if it's not cscript,
131.
'instruct the operator on how to run the script.
132.
If Right(LCase(WScript.FullName),11) <> LCase("cscript.exe") Then
133.
WScript.Echo "This script must run from cscript." & _
134.
VbCrLf & "Example: cscript ComputerSearch.vbs"
135.
WScript.Quit
136.
End If
137. End Sub
138. '******************************************************************
****
139. '* Function: PadZero
140. '******************************************************************
****
141. Function PadZero(dtValue)
142.
If Len(dtValue) = 1 Then
143.
PadZero = 0 & dtValue
144.
Else
145.
PadZero = dtValue
146.
End If
147. End Function
148. '******************************************************************
****
149. '* Function: GenFileName
150. '******************************************************************
****
151. Function GenFileName(prefix)
152.
'Create a unique time stamped name for the text file
153.
Dim dtDate,strYear,strMonth,strDay,strDate
154.
Dim dtNow,strHour,strMinute,strSecond,strTime
155.
dtDate = Date()
156.
strYear = Mid(Year(dtDate),3)
157.
strMonth = PadZero(Month(dtDate))
158.
strDay = PadZero(Day(dtDate))
159.
strDate = strYear & strMonth & strDay & "-"
160.
dtNow = Now()
161.
strHour = PadZero(Hour(dtNow))
162.
strMinute = PadZero(Minute(dtNow))
163.
strSecond = PadZero(Second(dtNow))
164.
strTime = strHour & strMinute & strSecond
165.
GenFileName = prefix & "-" & strDate & strTime & ".csv"
166. End Function
167. '******************************************************************
****
168. '* Function: SampleCommandLine
169. '******************************************************************
****
170. Function SampleCommandLine()
171.
SampleCommandLine = _
172.
"Specify the /r parameter to limit the computer list to" &
VbCrLf & _

173.
"only domain controllers or only member computers in the
domain." & VbCrLf & _
174.
"ComputerSearch.vbs /r:dc" & VbCrlf & _
175.
"or" & VbCrlf & _
176.
"ComputerSearch.vbs /r:mc"
177. End Function
178. '******************************************************************
****
179. '* Function: GenRecord
180. '******************************************************************
****
181. Function GenRecord()
182.
Dim strRecord
183.
strRecord = chr(34) & objRecordset.Fields("distinguishedName") &
chr(34) & ","
184.
GenRecord = strRecord
185. End Function

186.

Save the file as ComputerSearch.vbs.

Identifying Large-sized Objects with ObjMemUse.vbs

You can use the ObjMemUse.vbs script to help find rogue objects in Active Directory that are
consuming a significant amount of disk space. Before you can use the ObjMemUse.vbs
script, you must create the script based on the source code included in this document.
Note: This script requires Windows 2000 with Service Pack 3 or later and Windows Scripting
Host version 5.6 or later.
The ObjMemUse.vbs script has the following syntax:
cscript ObjMemUse.vbs /f:input_file [/s:object_size]

Where:

input_file is the name of the file, including path, created by ObCMAudit.vbs.

object_size is the minimum size, in Kb, of an object that you consider to be large. If
object_size is omitted, the ObjMemUse will consider any objects larger than 50Kb to
be large object.

ObjMemUse.vbs creates an output file, ObjMemUse-date-time.csv, which contains a list of

the objects listed in the file created by ObCMAudit.vbs and the size of each object.
Note: ObjMemUse.vbs provides only an estimate of an objects size. The estimate can vary
by as much as 4K - 8K. This means that an object that is less than 4K in size might be
estimated as 0K. However, when the object is large enough that the 4K variance is negligible,
then the difference between the size of the object and the estimate returned by
ObjMemUse.vbs is negligible.
To create the ObjMemUse.vbs script.
1. Open Notepad.
2. Copy or type the following script into Notepad.

3. *********************************************************************
*****
4. '* File:
ObjMemUse.vbs
*
5. '* Created:
April 2003
*
6. '* Version:
1.0
*
7. '*
*
8. '* Description:
Security diagnostic utility that creates a report
*
9. '*
containing objects that appear to be large. This
*
10. '*
utility uses a report created by ObjCMAudit.vbs
*
11. '*
to estimate the size of the created or modified
*
12. '*
objects.
*
13. '*
*
14. '* Notes:
This script uses the Raw performance counter
class
*
15. '*
for two reasons:
*
16. '*
1. The cooked (calculated) counter is not
currently
*
17. '*
available in Windows 2000.
*
18. '*
2. The cooked counter uses a cooking type of
*
19. '*
PERF_COUNTER_LARGE_RAWCOUNT, which doesn't
require *
20. '*
any further calculations but the cooked
counter
*
21. '*
is 64-bits in length to support very large
values. *
22. '*
*
23. '* Compatibility: This script requires WSH 5.6, CScript, ADSI,
WMI,
*
24. '*
and access to Active Directory
*
25. '******************************************************************
********
26. Option Explicit
27. 'Define any constants used in this script
28. Const ForAppending = 2
29. Const ForReading = 1
30. 'Declare global variables
31. Dim objArgs,strRptFileName,intSize,strFileName
32. Dim objFSO,objFile,objRptFile
33. Dim objRootDSE,strDomain,objADObject
34. Dim strLine,strDN
35. Dim intWSBefore,intWSAfter
36. Dim i,iCnt,intObjSizeBaseline
37. Dim intCurObjSize,intCalculatedSize
38. Call CheckForCScript()
39. 'Use Named Arguments collection for the command line argument.
40. 'The WSHArguments Object is included in WSH version 5.6 and later

41.
42.
43.
44.
45.
46.

Set objArgs = WScript.Arguments.Named

strRptFileName = objArgs.Item("f")
intSize = Round(Abs(objArgs.Item("s"))) * 1024
'Verify the command-line arguments
If ValidArgsTesting() = False Then WScript.Quit
'Call the GenFileName function to create a unique file name for the
report
47. strFileName = GenFileName("objMemUse")
48. 'Create a text file (.csv format) for the report.
49. Set objFSO = CreateObject("Scripting.FileSystemObject")
50. 'This will overwrite the file if it already exists.
51. Set objFile = objFSO.CreateTextFile(strFileName,True)
52. objFile.Close
53. Set objFile = objFSO.OpenTextFile(strFileName,ForAppending)
54. 'Write the headings for this csv file
55. objFile.WriteLine "DistinguishedName," & _
56.
"Change in Working Set Memory (bytes)"
57. Set objRptFile = objFSO.OpenTextFile(strRptFileName,ForReading)
58. 'Skip the header row of the report
59. objRptFile.SkipLine
60. Set objRootDSE = GetObject("LDAP://rootDSE")
61. strDomain = objRootDSE.Get("defaultNamingContext")
62. Set objRootDSE = Nothing
63. 'Tare the local property cache w/a default AD object.
64. Set objADObject = GetObject("LDAP://cn=BuiltIn," & strDomain)
65. 'Check memory before calling GetInfo
66. intWSBefore = CheckMemory(0)
67. objADObject.GetInfo
68. 'Check memory after calling GetInfo
69. intWSAfter = CheckMemory(0)
70. Set objADObject = Nothing
71. intCurObjSize = intWSAfter - intWSBefore
72. 'Calculate baseline working set memory
73. intObjSizeBaseline = BaseLine()
74. WScript.Echo "Report records processed: "
75. i=1
76. While Not objRptFile.AtEndOfStream
77.
'Extract a line from the report
78.
strLine = objRptFile.ReadLine
79.
'Return everything except for the first quotation mark
80.
strLine = Mid(strLine,2)
81.
'Return everything up to the second quotation mark
82.
strDN = Split(strLine,chr(34))
83.
'Bind to the object
84.
Set objADObject = GetObject("LDAP://" & strDN(0))
85.
'Check memory before calling GetInfo
86.
intWSBefore = CheckMemory(0)
87.
objADObject.GetInfo
88.
'Check memory after calling GetInfo
89.
intWSAfter = CheckMemory(0)
90.
Set objADObject = Nothing
91.
intCalculatedSize = ((intWSAfter - intWSBefore intObjSizeBaseline)/2)
92.
If intCalculatedSize >= intSize Then
93.
'Write data to the new report file
94.
objFile.WriteLine Chr(34) & strDN(0) & chr(34) & "," &
intCalculatedSize
95.
End If
96.
For iCnt = 1 to Len(i)
97.
WScript.StdOut.Write Chr(8)
98.
Next

99.
WScript.StdOut.Write i
100.
i = i + 1
101. Wend
102. WScript.Echo VbCrLf & VbCrLf & "The report data has been saved to:
" & _
103. strfileName & "." & VbCrLf & _
104. "Import or open the CSV data in a spreadsheet" & VbCrLf & _
105. "or database program to analyze object size estimates."
106. '******************************************************************
****
107. '* Routine: CheckForCScript
108. '******************************************************************
****
109. Sub CheckForCScript
110.
'This script must run from cscript because
111.
'it uses the WScript.StdOut property.
112.
'Test the script host and if it's not cscript,
113.
'instruct the operator on how to run the script.
114.
If Right(LCase(WScript.FullName),11) <> LCase("cscript.exe") Then
115.
WScript.Echo "This script must run from cscript." & _
116.
VbCrLf & "Example: cscript ObjMemUse.vbs"
117.
WScript.Quit
118.
End If
119. End Sub
120. '******************************************************************
****
121. '* Function: ValidArgsTesting
122. '******************************************************************
****
123. Function ValidArgsTesting
124.
If WScript.Arguments.Named.Count < 1 Then
125.
WScript.Echo "You must specify a csv file name " & VBCrLf & _
126.
"of a file created by ObjCMAudit.vbs." & VbCrLf & _
127.
SampleCommandLine()
128.
ValidArgsTesting = False
129.
ElseIf Wscript.Arguments.Named.Exists("f") AND
Wscript.Arguments.Named.Count = 1 Then
130.
WScript.echo "No size value was specified. Therefore, objects
that require" & _
131.
VbCrLf & "50kb or more of the local property cache will be
reported."
132.
intSize = 50 * 1024
133.
ValidArgsTesting = True
134.
ElseIf WScript.Arguments.Named.Exists("s") AND IsNumeric(intSize)
= FALSE Then
135.
WScript.Echo "The size value that you specified is not valid."
& _
136.
VbCrLf & "You must specify a number." & _
137.
VbCrLf & SampleCommandLine()
138.
ValidArgsTesting = False
139.
ElseIf WScript.Arguments.Named.Count >= 1 AND _
140.
WScript.Arguments.Named.Exists("f") = false Then
141.
WScript.Echo "The /f: parameter is required."
142.
WScript.Echo VbCrLf & SampleCommandLine()
143.
ValidArgsTesting = False
144.
Else
145.
WScript.Echo "Objects that require " & intSize & "kb or more "
& _
146.
"than the Builtin container object in the local property" & _
147.
VbCrLf & "cache will be reported." & _

148.
VbCrLf & "Note, this script rounds the number specified to
the nearest" & _
149.
VbCrLf & "whole number. Negative numbers are not allowed and
are automatically" & _
150.
VbCrLf & "converted to positive values."
151.
ValidArgsTesting = True
152.
End If
153. End Function
154. '******************************************************************
****
155. '* Function: SampleCommandLine
156. '******************************************************************
****
157. Function SampleCommandLine()
158.
SampleCommandLine = _
159.
"For example, to create a report on all objects" & _
160.
VbCrLf & "that consume 250kb of memory to complete" & VbCrLf &
_
161.
" a binding operation, based on computers listed in" & VbCrLf
& _
162.
" a file named obcmReport.csv, type:" & VbCrLf & _
163.
"ObjMemUse.vbs /f:obcmReport.csv /s:250"
164. End Function
165. '******************************************************************
****
166. '* Function: BaseLine
167. '******************************************************************
****
168. Function BaseLine
169.
Dim blnVal,intPreObjSize,intCount
170.
intPreObjSize = 0
171.
intCount= 0
172.
blnVal = False
173.
Do Until blnVal = True
174.
If intPreObjSize = intCurObjSize Then
175.
intCount = intCount + 1
176.
If intCount = 10 then
177.
blnVal = True
178.
'intObjSizeBaseline = intCurObjSize
179.
Baseline = intCurObjSize
180.
End If
181.
Else
182.
intCount = 0
183.
intPreObjSize = intCurObjSize
184.
Set objADObject = GetObject("LDAP://cn=BuiltIn," & strDomain)
185.
intWSBefore = CheckMemory(0)
186.
objADObject.GetInfo
187.
intWSAfter = CheckMemory(0)
188.
Set objADObject = Nothing
189.
intCurObjSize = intWSAfter - intWSBefore
190.
End If
191.
Loop
192. End Function
193. '******************************************************************
****
194. '* Function: CheckMemory
195. '******************************************************************
****
196. Function CheckMemory(index)
197.
Dim blnValue,intPreWorkingSet,intCurWorkingSet,intMemorySameCount
198.
intMemorySameCount = 0

199.
intPreWorkingSet = 0
200.
intCurWorkingSet = _
201.
(GetObject("winmgmts:Win32_PerfRawData_PerfProc_Process='cscript'").W
orkingSet)
202.
blnValue = False
203.
Do Until blnValue = True
204.
If intPreWorkingSet = intCurWorkingSet Then
205.
intMemorySameCount = intMemorySameCount + 1
206.
If intMemorySameCount = 10 then
207.
blnValue = true
208.
CheckMemory = intCurWorkingSet
209.
End If
210.
Else
211.
intMemorySameCount = 0
212.
intPreWorkingSet = intCurWorkingSet
213.
intCurWorkingSet = _
214.
(GetObject("winmgmts:Win32_PerfRawData_PerfProc_Process='cscript'").W
orkingSet)
215.
End If
216.
Loop
217. End Function
218. '******************************************************************
****
219. '* Function: PadZero
220. '******************************************************************
****
221. Function PadZero(dtValue)
222.
If Len(dtValue) = 1 Then
223.
PadZero = 0 & dtValue
224.
Else
225.
PadZero = dtValue
226.
End If
227. End Function
228. '******************************************************************
****
229. '* Function: GenFileName
230. '******************************************************************
****
231. Function GenFileName(prefix)
232.
'Create a unique time stamped name for the text file
233.
Dim dtDate,strYear,strMonth,strDay,strDate
234.
Dim dtNow,strHour,strMinute,strSecond,strTime
235.
dtDate = Date()
236.
strYear = Mid(Year(dtDate),3)
237.
strMonth = PadZero(Month(dtDate))
238.
strDay = PadZero(Day(dtDate))
239.
strDate = strYear & strMonth & strDay & "-"
240.
dtNow = Now()
241.
strHour = PadZero(Hour(dtNow))
242.
strMinute = PadZero(Minute(dtNow))
243.
strSecond = PadZero(Second(dtNow))
244.
strTime = strHour & strMinute & strSecond
245.
GenFileName = prefix & "-" & strDate & strTime & ".csv"
246. End Function

247.

Save the file as ObjMemUse.vbs

Identifying Objects Created or Modified Within a Period of Time with

ObCMAudit.vbs

You can use the ObCMAudit.vbs script to identify objects that are created or modified in a
domain within a given period of time to help you identify any rogue objects in Active
Directory. Before you can use the ObCMAudit.vbs script, you must create the script based on
the source code included in this document.
Note: This script requires Windows 2000 with Service Pack 3 or later and Windows Scripting
Host version 5.6 or later.
The ObCMAudit.vbs script has the following syntax:
cscript ObCMAudit.vbs [/d:date] [/t:time] /h:length

Where:

date is the date when you detected the disk space attack. This parameter is optional.
time is the time you detected the disk space attack. This parameter is optional.

length is the length of time, in hours, prior to the time you detected the disk space
attack based on the trend in the growth of the rogue objects discovered in Step 4.
ObCMAudit.vbs has no parameters.

ObCMAudit.vbs creates an output file, ObCMAudit-date-time.csv, that contains a list of the

objects created or modified during the length of time.
To create the ObCMAudit.vbs script.
1. Open Notepad.
2. Copy or type the following script into Notepad.
3. '********************************************************************
******
4. '* File:
ObjCMAudit.vbs
*
5. '* Created:
March 2003
*
6. '* Version:
1.0
*
7. '*
*
8. '* Description:
Security diagnostic utility that creates a report
*
9. '*
containing all objects created or modified within
a
*
10. '*
specified time window. Use this tool to build a
*
11. '*
report of object creation and modification
activity. *
12. '*
You can then complete two common tasks with the
*
13. '*
report.
*

14. '*
1. Use the ObjMemUse.vbs file to read the
report
*
15. '*
and estimate the size of the created
objects.
*
16. '*
2. Import the csv file into a spreadsheet
program
*
17. '*
or a database program to analyze the
results.
*
18. '*
*
19. '* Compatibility: This script requires WSH 5.6, CScript, ADSI,
WMI
*
20. '*
and access to Active Directory
*
21. '******************************************************************
********
22. Option Explicit
23. 'Define any constants used in this script
24. Const ForAppending = 2
25. 'Declare global variables
26. Dim objArgs,intHours,dtFromDate,dtFromTime,dtVal,intLocalTime
27. Dim objRootDSE
28. Dim strFileName,objFSO,objFile
29. Dim objConnection,objCommand
30. Dim arrNamingContexts,NamingContext,strContainer
31. 'This script must run from cscript because
32. 'it uses the WScript.StdOut property.
33. 'Test the script host and if it's not cscript,
34. 'instruct the operator how to run the script.
35. If Right(LCase(WScript.FullName),11) <> LCase("cscript.exe") Then
36.
WScript.Echo "This script must run from cscript." & _
37.
VbCrLf & SampleCommandLine() & VbCrLf & _
38.
VbCrLf & "Check the locale setting of your system for the
correct" & _
39.
" date and time format."
40.
WScript.Quit
41. End If
42. 'Use Named Arguments collection for the command line argument.
43. 'The WSHArguments Object is included in WSH version 5.6 and later
44. Set objArgs = WScript.Arguments.Named
45. intHours = cInt(objArgs.Item("h"))
46. dtFromDate = objArgs.Item("d")
47. dtFromTime = objArgs.Item("t")
48. If WScript.Arguments.Named.Exists("d") AND _
49.
WScript.Arguments.Named.Exists("t") Then
50.
dtVal = DateValue(dtFromDate) & " " & TimeValue(dtFromTime)
51.
If IsDate(dtVal) = False Then
52.
WScript.Echo "The date or time value that you specified is not
valid." & _
53.
VbCrLf & "You must specify a valid date and time." & _
54.
VbCrLf & SampleCommandLine()
55.
WScript.Quit
56.
End If
57. ElseIf WScript.Arguments.Named.Count = 2 Then
58.
WScript.Echo "A command line parameter is missing." & _
59.
VbCrLf & SampleCommandLine() & VbCrLf _
60.
VbCrLf & "Check the locale setting of your system for the
correct" & _
61.
" date and time format."
62.
WScript.Quit
63. ElseIf WScript.Arguments.Named.Count = 1 AND _

64.
65.

WScript.Arguments.Named.Exists("h") Then
WScript.Echo "No date and time endpoint was provided. " & VbCrLf
& _

66.

"Therefore, the time window endpoint is based upon " & VbCrLf &

67.
"the current system time."
68.
dtVal = Now()
69. End If
70. If WScript.Arguments.Named.Count < 1 Then
71.
WScript.Echo "You must specify a time window (in hours) " &
VBCrLf & _
72.
"within which objects were created or modified." & VbCrLf & _
73.
SampleCommandLine()
74.
WScript.Quit
75. Else
76.
intLocalTime = LocalTime()
77.
'Call the GenFileName function to create a unique file name
78.
strFileName = GenFileName("ObjCMAudit")
79.
'Create a text file (.csv format) to hold the
80.
'results of the report.
81.
Set objFSO = CreateObject("Scripting.FileSystemObject")
82.
'This will overwrite the file if it already exists.
83.
Set objFile = objFSO.CreateTextFile(strFileName,True)
84.
objFile.Close
85.
Set objFile = objFSO.OpenTextFile(strFileName,ForAppending)
86.
'Write the headings for this csv file
87.
objFile.WriteLine "DistinguishedName,Class,Action,Date"
88.
'Create the ADSI OLE DB provider object
89.
Set objConnection = CreateObject("ADODB.Connection")
90.
objConnection.Open "Provider=ADsDSOObject;"
91.
'Create the command object and set the ActiveConnection
92.
'property equal to the command object
93.
Set objCommand = CreateObject("ADODB.Command")
94.
objCommand.ActiveConnection = objConnection
95.
'Specify Page size for this command object.
96.
'The domain and configuration containers are likely to contain
97.
'large result sets
98.
objCommand.Properties("Page Size") = 256
99.
objCommand.Properties("Asynchronous") = True
100.
'This will be used as a forward only recordset
101.
'so caching isn't necessary and, if a large result set
102.
'is returned, caching will consume too much memory.
103.
objCommand.Properties("Cache results") = False
104.
'Use the RootDSE object for upcoming binding operations
105.
Set objRootDSE = GetObject("LDAP://rootDSE")
106.
'Get the DNs for all naming contexts defined on the DC
107.
arrNamingContexts = objRootDSE.GetEx("namingContexts")
108.
'Enumerate the list of Naming Contexts and write a multi-line
109.
'report file.
110.
For Each NamingContext in arrNamingContexts
111.
'Set the strContainer variable equal to the binding string of
the container.
112.
strContainer = "<LDAP://" & NamingContext & ">"
113.
WScript.Echo VbCrLf & "Reporting on objects in the " & _
114.
NamingContext & " container" & VBCrLf & _
115.
"created or modified between " & DateAdd("h",-intHours,dtVal) &
" and " & dtVal
116.
Call CheckDates(strContainer,intHours)
117.
Next
118.
'Clean up
119.
Set objRootDSE = Nothing

120. End If
121. WScript.Echo VbCrLf & VbCrLf & "The report data has been saved to:
" & _
122. strfileName & "." & VbCrLf & _
123. "Import or open the CSV data in a spreadsheet" & VbCrLf & _
124. "or database program and/or rename the file and use" & VbCrLf & _
125. "the report data to analyze object size using the ObjMemUse.vbs
script." & VbCrLf & _
126. "For example, rename " & strFileName & " to ocm.csv and then run
the " & VbCrLf & _
127. "object size analysis script by typing: cscript ObjMemUse.vbs
/f:ocm.csv"
128. '******************************************************************
****
129. '* Routine: CheckDates
130. '******************************************************************
****
131. Sub CheckDates(Container,Hours)
132.
Dim objRSContainer,dtWhenCreated,dtWhenChanged
133.
Dim dtAdjwhenCreated,dtAdjwhenChanged
134.
Dim dtWChgDiff,dtWCreDiff
135.
Dim strDN,arrClass,iCnt,i
136.
'Construct the query.
137.
'Note: Using objectClass as an attribute to return because
objectCategory
138.
'does not contain a value for all classes.
139.
objCommand.CommandText = Container & _
140.
";(&(objectCategory=*)(!
objectCategory=foreignSecurityPrincipal));" & _
141.
"distinguishedName,whenCreated,whenChanged,objectClass;subtree"
142.
'Run the query
143.
Set objRSContainer = objCommand.Execute
144.
i = 0
145.
WScript.Echo "Records processed:"
146.
'Iterate the recordset
147.
While Not objRSContainer.EOF
148.
dtWhenCreated = objRSContainer.Fields("whenCreated")
149.
dtWhenChanged = objRSContainer.Fields("whenChanged")
150.
'Test for null values in whenChanged and whenCreated
151.
'For example, whenCreated and whenChanged are not mandatory
attributes
152.
'and are not set for objects that are instantiated from the
crossRefContainer
153.
'structural class
154.
If (IsNull(dtWhenCreated) OR dtWhenCreated <
CDate("01/01/1990")) OR _
155.
(IsNull(dtWhenChanged) OR dtWhenChanged <
CDate("01/01/1990")) Then
156.
If IsNull(dtWhenCreated) AND IsNull(dtWhenChanged) Then
157.
objFile.WriteLine ReadAndWrite(objRSContainer,"Created and
Changed","not set")
158.
ElseIf IsNull(dtWhenCreated) Then
159.
objFile.WriteLine
ReadAndWrite(objRSContainer,"Created","not set")
160.
ElseIf IsNull(dtWhenChanged) Then
161.
objFile.WriteLine
ReadAndWrite(objRSContainer,"Changed","not set")
162.
End If
163.
Else
164.
'Convert the time returned to local time by adding or
subtracting

165.
'from GMT.
166.
dtAdjwhenCreated = DateAdd("h",intLocalTime,dtWhenCreated)
167.
dtAdjwhenChanged = DateAdd("h",intLocalTime,dtWhenChanged)
168.
'Take the number of hours and date time endpoint provided by
169.
'the operator and return all objects created from that hour
forward
170.
'The date value (dtVal) is the date and time endpoint of the
test.
171.
dtWChgDiff = DateDiff("h",dtAdjwhenChanged,dtVal)
172.
dtWCreDiff = DateDiff("h",dtAdjwhenCreated,dtVal)
173.
'The sgn function is necessary in the next two If Then
evaluations.
174.
'Otherwise, these evaulations will return values that are
greater than
175.
'the defined date/time endpoint.
176.
If ((Hours >= Cint(dtWChgDiff) AND Sgn(Cint(dtWChgDiff)) <>
-1) AND _
177.
(Hours >= Cint(dtWCreDiff) AND Sgn(Cint(dtWCreDiff)) <>
-1)) Then
178.
objFile.WriteLine
ReadAndWrite(objRSContainer,"[Created] \ [Changed]", _
179.
"[" & dtAdjwhenCreated & "] \ [" & dtAdjwhenChanged &
"]")
180.
ElseIf Hours >= Cint(dtWChgDiff) AND Sgn(Cint(dtWChgDiff)) <>
-1 Then
181.
objFile.WriteLine
ReadAndWrite(objRSContainer,"Changed","[" & dtAdjwhenChanged & "]")
182.
ElseIf Hours >= Cint(dtWCreDiff) AND Sgn(Cint(dtWCreDiff)) <>
-1 Then
183.
objFile.WriteLine
ReadAndWrite(objRSContainer,"Created","[" & dtAdjwhenCreated & "]")
184.
End If
185.
End If
186.
For iCnt = 1 to Len(i)
187.
WScript.StdOut.Write Chr(8)
188.
Next
189.
WScript.StdOut.Write i
190.
i = i + 1
191.
objRSContainer.MoveNext
192.
Wend
193. End Sub
194. '******************************************************************
****
195. '* Function: LocalTime
196. '******************************************************************
****
197. 'Get local time zone offset. Requires WMI and the Win32_TimeZone
class
198. 'which is part of Windows 2000 and later.
199. Function LocalTime()
200.
Dim objWMIService,colTimeZones,objTimeZone
201.
Set objWMIService = GetObject("winmgmts:
{impersonationLevel=Impersonate}!\\.\root\cimv2")
202.
Set colTimeZones = objWmiService.InstancesOf("Win32_TimeZone")
203.
For Each objTimeZone In colTimeZones
204.
LocalTime = Fix(objTimeZone.Bias / 60)
205.
Next
206. End Function
207. '******************************************************************
****
208. '* Function: SampleCommandLine

209. '******************************************************************
****
210. Function SampleCommandLine()
211.
SampleCommandLine = VbCrLf & _
212.
"Example: To test a 4 hour time window on 03-07-2003" & VbCrLf &
_
213.
"from 9:30 AM and 50 seconds to 1:30 PM and 50 seconds, type:" &
VbCrLf & _
214.
"cscript ObjCMAudit.vbs /h:4 " & _
215.
"/d:03-07-2003 /t:1:30:50PM" & VbCrLf & VbCrLf & _
216.
"You can also enter a time value using a 24-hour clock." &
VbCrLf & _
217.
"Example: To test a 2 hour time window on 03-07-2003" & VbCrLf &
_
218.
"from 14:00 (2:00pm) to 16:00 (4:00pm), type:" & VbCrLf & _
219.
"cscript ObjCMAudit.vbs /h:2 " & _
220.
"/d:03-07-2003 /t:16:00"
221. End Function
222. '******************************************************************
****
223. '* Function: PadZero
224. '******************************************************************
****
225. Function PadZero(dtValue)
226.
If Len(dtValue) = 1 Then
227.
PadZero = 0 & dtValue
228.
Else
229.
PadZero = dtValue
230.
End If
231. End Function
232. '******************************************************************
****
233. '* Function: GenFileName
234. '******************************************************************
****
235. Function GenFileName(prefix)
236.
'Create a unique time stamped name for the text file
237.
Dim dtDate,strYear,strMonth,strDay,strDate
238.
Dim dtNow,strHour,strMinute,strSecond,strTime
239.
dtDate = Date()
240.
strYear = Mid(Year(dtDate),3)
241.
strMonth = PadZero(Month(dtDate))
242.
strDay = PadZero(Day(dtDate))
243.
strDate = strYear & strMonth & strDay & "-"
244.
dtNow = Now()
245.
strHour = PadZero(Hour(dtNow))
246.
strMinute = PadZero(Minute(dtNow))
247.
strSecond = PadZero(Second(dtNow))
248.
strTime = strHour & strMinute & strSecond
249.
GenFileName = prefix & "-" & strDate & strTime & ".csv"
250. End Function
251. '******************************************************************
****
252. '* Function: ReadAndWrite
253. '******************************************************************
****
254. Function ReadAndWrite(RecordSet,Status,AttribValue)
255.
Dim strDN,arrClass,strClassName
256.
strDN = RecordSet.Fields("distinguishedName")
257.
arrClass = RecordSet.Fields("objectClass")
258.
strClassName = arrClass(UBound(arrClass))

259.
ReadAndWrite = Chr(34) & strDN & Chr(34) & "," & strClassName &
"," & _
260.
Status & "," & AttribValue
261. End Function

262.

Save the file as ObCMAudit.vbs

Modifying Policy Settings with Ntdsutil

This procedure allows an administrator to manually modify a policy setting. If recording

policy settings is performed periodically, then any changes to policies can be quickly
discovered and repaired.
Ntdsutil.exe is located in the Support tools folder o n the Windows 2000 installation CDROM.
Requirements

Credentials: Domain Admins

Tools: Ntdsutil.exe

To view current policy settings on your domain controllers:

1. From a command line, type Ntdsutil
2. At the Ntdsutil command prompt, type LDAP policies
3. At the LDAP policy command prompt, type set < setting > to < settingValue >
4. At the server connection command prompt, type connect to server <
DomainControllerName >
5. Modify current LDAP policy settings
For example; Set MaxPoolThreads to 8
6. To save the changes, type Commit Changes
7. When finished, type q
Note: This procedure only shows the Default Domain Policy settings. If you apply your own
policy setting, you cannot see it.
Monitoring the Number of Objects In a Domain With
ObjCountByClass.vbs

You can use the ObjCountByClass.vbs script to monitor the number of objects in a domain.
Before you can use the ObjCountByClass.vbs script, you must create the script based on the
source code included in this
document.http://www.microsoft.com/technet/prodtechnol/ad/Windows2000/maintain/opsguid
e/Part2/ADOGdApB.asp.

Note: This script requires Windows 2000 with Service Pack 3 or later and Windows Scripting
Host version 5.6 or later.
The ObjCountByClass.vbs script has the following syntax:
cscript ObjCountByClass.vbs

ObjCountByClass.vbs has no parameters.

ObjCountByClass.vbs creates an output file, ObjCountByClass -date-time.csv, which
contains the number of objects by object class (where date is the date you ran
ObjCountByClass.vbs and time is the time you ran ObjCountByClass.vbs.
To create the ObjCountByClass.vbs script
1. Start Notepad
2. Copy or type the following script into Notepad
3. *********************************************************************
*****
4. '* File:
ObjCountByClass.vbs
*
5. '* Created:
April 2003
*
6. '* Version:
1.0
*
7. '*
*
8. '* Description:
Diagnostic utility that counts the number of
objects *
9. '*
by objectClass, created in all containers
*
10. '*
defined in the namingContexts attribute of
RootDSE.
*
11. '*
Use this tool to build an object creation trend
*
12. '*
analysis. Output is placed in a date and timestamped *
13. '*
CSV report file with a beginning prefix of
*
14. '*
ObjCountByClass. Import the csv file into a
*
15. '*
a spreadsheet program or a database program for
*
16. '*
trend analysis.
*
17. '*
*
18. '* Compatibility: This script requires WSH 5.6, CScript, ADSI,
*
19. '*
and access to Active Directory
*
20. '******************************************************************
********
21. Option Explicit
22. 'Define any constants used in this script
23. Const ForAppending = 2

24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.

'Declare global variables

Dim dtDate,dtTime,strDate,strTime
Dim objRootDSE,strSchema,strDomain,strConfig
Dim objConnection,objCommand,objRSSchema
Dim objFSO,objFile,strCount,strFileName
Dim arrNamingContexts,NamingContext,strContainer
Call CheckForCScript
'Set the date and time values. These are used by
'the GenFileName function and appear in the first
'and second column of the report.
dtDate = Date()
dtTime = Time()
'Formatted date and time values for report columns 1 and 2
strDate = DateFormat(dtDate)
strTime = TimeFormat(dtTime)
'Use the RootDSE object for upcoming binding operations
Set objRootDSE = GetObject("LDAP://rootDSE")
'Get the DNs for all naming contexts defined on the DC
arrNamingContexts = objRootDSE.GetEx("namingContexts")
'Bind to the current schema to obtain a list of all ClassSchema
objects
44. strSchema = "<LDAP://" & _
45.
objRootDSE.Get("schemaNamingContext") & ">"
46. 'Create the ADSI OLE DB provider object
47. Set objConnection = CreateObject("ADODB.Connection")
48. objConnection.Open "Provider=ADsDSOObject;"
49. 'Create the command object and set the ActiveConnection
50. 'property equal to the command object
51. Set objCommand = CreateObject("ADODB.Command")
52. objCommand.ActiveConnection = objConnection
53. 'Create the schema query
54. objCommand.CommandText = strSchema & _
55.
";(objectClass=classSchema);" & _
56.
"lDAPDisplayName,distinguishedName;subtree"
57. 'Specify page size for this command object.
58. 'This is necessary to avoid overutilization of server
59. 'and network resources. Also, by default,
60. 'only 1000 records will be returned if paging isn't
61. 'specified. The schema might contain more
62. 'than 1000 classSchema objects.
63. objCommand.Properties("Page Size") = 256
64. objCommand.Properties("Asynchronous") = True
65. 'Caching is required because the schema recordset
66. 'iterated multiple times.
67. objCommand.Properties("Cache results") = True
68. 'Run the schema query
69. Set objRSSchema = objCommand.Execute
70. 'Create a unique file name (timestamp) using the GenFileName
function
71. strFileName = GenFileName("ObjCountByClass")
72. 'Create a text file (.csv format) to hold the
73. 'results of the class test.
74. Set objFSO = CreateObject("Scripting.FileSystemObject")
75. 'This will overwrite the file if it already exists.
76. Set objFile = objFSO.CreateTextFile(strFileName,True)
77. objFile.Close
78. Set objFile = objFSO.OpenTextFile(strFileName,ForAppending)
79. 'Write the column headings to the report file
80. objFile.WriteLine
"dtDate,dtTime,strContainer,strObjectClass,intTotal"
81. 'Enumerate the list of Naming Contexts and write a multi-line

82. 'report file.

83. For Each NamingContext in arrNamingContexts
84.
'Set the strContainer variable equal to the binding string of the
container.
85.
strContainer = "<LDAP://" & NamingContext & ">"
86.
'Write the column headings
87.
Call CountObjects(NamingContext,strContainer)
88. Next
89. 'Clean up
90. Set objConnection = Nothing
91. 'Close the file
92. objFile.Close
93. WScript.Echo VbCrLf & "The report data has been saved to: " &
strfileName & "."
94. WScript.Echo "Import or open the CSV data in a spreadsheet or
database program."
95. '******************************************************************
****
96. '* Routine: CheckForCScript
97. '******************************************************************
****
98. Sub CheckForCScript
99.
'This script must run from cscript because
100.
'it uses the WScript.StdOut property.
101.
'Test the script host and if it's not cscript,
102.
'instruct the operator on how to run the script.
103.
If Right(LCase(WScript.FullName),11) <> LCase("cscript.exe") Then
104.
WScript.Echo "This script must run from cscript." & _
105.
VbCrLf & "Example: cscript objCountByClass.vbs"
106.
WScript.Quit
107.
End If
108. End Sub
109. '******************************************************************
****
110. '* Routine: CountObjects
111. '******************************************************************
****
112. Sub CountObjects(NamingContext,Container)
113.
Dim
i,strClassName,strDN,objRSContainer,intRecordCount,iCnt,iPercent
114.
Dim objField,colObjClass,strClassValue
115.
i = 0
116.
'Use a While Wend loop to test for each type of class object
117.
WScript.Echo VbCrLf
118.
While Not objRSSchema.EOF
119.
'Set the class and dn variables equal to the two attributes
120.
'contained in the Fields collection.
121.
strClassName = objRSSchema.Fields("lDAPDisplayName")
122.
strDN = objRSSchema.Fields("distinguishedName")
123.
'objectClass must be returned in the resultset so that the last
entry
124.
'of the multi-valued attribute can be returned as the
objectclass
125.
'in the report.
126.
objCommand.CommandText = Container & _
127.
";(objectCategory=" & strDN & ");" & _
128.
"objectClass;subtree"
129.
'Caching isn't necessary because this recordset is read only
once.
130.
objCommand.Properties("Cache results") = False
131.
Set objRSContainer = objCommand.Execute

132.
If i = 0 Then
133.
WScript.Echo "Counting objects in:" & " " & NamingContext
134.
End If
135.
'Get the class name from the recordset. The last entry is
136.
'all that's required in the objectClass multi-valued attribute
137.
While Not objRSContainer.EOF
138.
For Each objField in objRSContainer.Fields
139.
colObjClass = objField.Value
140.
For Each strClassValue in colObjClass
141.
'The last entry for strClassValue becomes the value
142.
'of strClassName
143.
strClassName = strClassValue
144.
Next
145.
Next
146.
intRecordCount = objRSContainer.RecordCount
147.
If intRecordCount > 0 Then
148.
objFile.WriteLine strDate & "," & strTime & "," & _
149.
Chr(34) & NamingContext & Chr(34) & "," & strClassName &
"," & intRecordCount
150.
End If
151.
objRSContainer.MoveNext
152.
Wend
153.
'Progress indicator
154.
For iCnt = 1 to Len(iPercent) + 22
155.
WScript.StdOut.Write Chr(8)
156.
Next
157.
iPercent = (Round(i/objRSSchema.RecordCount,2) * 100) + 1
158.
WScript.StdOut.Write "Percentage complete: " & iPercent & "%"
159.
i = i + 1
160.
objRSSchema.MoveNext
161.
Wend
162.
'Clean up
163.
Set objRSContainer = Nothing
164.
objRSSchema.MoveFirst
165. End Sub
166. '******************************************************************
****
167. '* Function: PadZero
168. '******************************************************************
****
169. Function PadZero(dtValue)
170.
If Len(dtValue) = 1 Then
171.
PadZero = 0 & dtValue
172.
Else
173.
PadZero = dtValue
174.
End If
175. End Function
176. '******************************************************************
****
177. '* Function: GenFileName
178. '* NOTE, This is slightly modified from the other GenFileName
functions
179. '* the initial date and time values are calculated outside of the
180. '* function because the values are used in the first and second
columns
181. '* of the report.
182. '******************************************************************
****
183. Function GenFileName(prefix)
184.
'Create a unique time stamped name for the text file
185.
Dim strYear,strMonth,strDay,strDate

186.
Dim strHour,strMinute,strSecond,strTime
187.
strYear = Mid(Year(dtDate),3)
188.
strMonth = PadZero(Month(dtDate))
189.
strDay = PadZero(Day(dtDate))
190.
strDate = strYear & strMonth & strDay & "-"
191.
strHour = PadZero(Hour(dtTime))
192.
strMinute = PadZero(Minute(dtTime))
193.
strSecond = PadZero(Second(dtTime))
194.
strTime = strHour & strMinute & strSecond
195.
GenFileName = prefix & "-" & strDate & strTime & ".csv"
196. End Function
197. '******************************************************************
****
198. '* Function: DateFormat
199. '******************************************************************
****
200. Function DateFormat(DateVal)
201.
Dim strYear,strMonth,strDay
202.
'Get the date for column 1 of each row.
203.
strYear = Year(DateVal)
204.
strMonth = PadZero(Month(DateVal))
205.
strDay = PadZero(Day(DateVal))
206.
DateFormat = strYear & "/" & strMonth & "/" & strDay
207. End Function
208. '******************************************************************
****
209. '* Function: TimeFormat
210. '******************************************************************
****
211. Function TimeFormat(TimeVal)
212.
Dim strHour,strMinute,strSecond
213.
'Get the time for column 2 of each row.
214.
strHour = PadZero(Hour(TimeVal))
215.
strMinute = PadZero(Minute(TimeVal))
216.
strSecond = PadZero(Second(TimeVal))
217.
TimeFormat = strHour & ":" & strMinute & ":" & strSecond
218. End Function

219.

Save the file as ObjCountByClass.vbs

Removing an Active Directory Domain Controller

Use the NTDSUtil.exe Support tool to perform this procedure. Ntdsutil.exe is located in the
Support tools folder o n the Windows 2000 installation CD-ROM.
To remove a selected Active Directory domain controller:
1. Run the ntdsutil command and at the prompt, type metadata cleanup
2. This returns the metadata cleanup command prompt.
3. Type connection
This returns the connection command prompt.
4. At the connection command prompt, type connect to server < ServerName>
5. Type quit

This returns the metadata cleanup command prompt.

6. Type select operation target
This returns the operational target command prompt.
7. Type list sites
A numbered list of sites is displayed.
8. Type select site < SiteNumber>
9. Type list domains in site
A numbered list of domains is displayed.
10. Type select domain < DomainNumber>
11. Type list servers in site
A numbered list of servers for a domain in a site is displayed.
12. Type select server < ServerNumber>
13. At the select operation target command prompt, type quit
14. At the metadata cleanup command prompt, type remove selected server
Resetting Passwords

Perform this procedure when administrator passwords must be quickly reset, such as when a
forest-wide password reset is required because passwords might have been compromised.
Requirements

Credentials: Domain Admins or Enterprise Admins

To reset a password
1. Open Active Directory Users and Computers, and locate the service administrator
accounts.
2. Right-click an account, and then click Reset password.
3. Type the new password in New Password and Confirm New Password, and then
click OK.
4. Distribute the new password to the service administrator.
5. Repeat steps 2 through 4 for each service administrator account.

Securing Scripts with Script Signing

Two alternatives exist for creating signed scripts. For those interested in developing their own
script host, the Windows Product SDK contains a set of tools for signing scripts
(signcode.exe and chktrust.exe). When writing your own script host, call Win32 API
WinVerifyTrust. This API verifies the trust on a .VBS or .JS file.
Alternatively, the Windows Script Host (WSH) 5.6 ships with a signer object to create and
verify signed scripts. The following JScript code creates a signed file.
var Signer = new ActiveXObject("Scripting.Signer");
var File = "c:\\myfile.vbs";
var Cert = "Jane Q. Programmer";
var Store = "my";
Signer.SignFile(File, Cert, Store);

The following sample, in this case as VBScript code, verifies the signing on a file:
Dim Signer, File, ShowUI, FileOK
Set Signer = CreateObject("Scripting.Signer")
File = "c:\newfile.wsf"
ShowUI = True
FileOK = Signer.VerifyFile(File, ShowUI)
If FileOK Then
WScript.Echo File & " is trusted."
Else
WScript.Echo File & " is NOT trusted."
End If

Viewing Current Policy Settings

This procedure allows an administrator view current LDAP policy settings. This procedure
collects information that is required for the baseline database.
Ntdsutil.exe is located in the Support tools folder o n the Windows 2000 installation CDROM.
Requirements

Credentials: Domain Admins

Tools: Ntdsutil.exe

Ntdsutil.exe is located in the Support tools folder on the Windows 2000 installation CDROM.
To view current policy settings on your domain controllers:
1. From a command line, type Ntdsutil
2. At the Ntdsutil command prompt, type LDAP policies
3. At the LDAP policy command prompt, type connections

4. At the server connection command prompt, type connect to server <

DomainControllerName>
View current LDAP policy settings.
5. At the server connection command prompt, type q
6. At the LDAP policy command prompt, type show values
A display of the policies as they exist appears.
Acknowledgements
Developed by the Windows Server Content Group
Program Managers: Arun Nanda
Writers: Kathleen Cole, Jennifer Bayer, Doug Steen
Editor: Jim Becker
Lab Staff: Robert Thingwold, David Meyer
Lab Partners: Hewlett Packard Corporation and Cisco Systems, Inc.
We thank the following people for reviewing the guide and providing valuable feedback:
Eric Fitzgerald, Andy Harjanto, Smitha Vuppuluri, Jason Garms