1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Best Practice Guide for Securing Active

Directory Installations and DaytoDay
Operations: Part II
Part II of the Best Practice Guide for Securing Active Directory Installations and DaytoDay 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 DaytoDay 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

[Link] 1/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 decisionmaking 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.

[Link] 2/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 DaytoDay Operations: Part I at
[Link]

Part II of the process is designed to help maintain a secure Active Directory infrastructure. This includes a list of daytoday
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.

[Link] 3/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 highsecurity server
when it:

Runs a service in the context of a service administratorlevel 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 highsecurity servers.

Based on these criteria, in addition to domain controllers there may be other highsecurity servers in your network which will
require special daytoday operations to remain secure. Protect all highsecurity 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 forestwide configuration settings for Active Directory.

Manage security of service administrator accounts.

This chapter provides specific recommendations for maintaining the security of domain controllers, other highsecurity 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
daytoday and, occasionally special maintenance on domain controllers and administrative workstations. How these tasks

[Link] 4/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 nonauthoritative.

Domain controllers are highsecurity servers, requiring special handling.

Due to the highlevel 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, enterprisewide account for backup.

Limit domain controller backup hardware to locations with hardware and media security.

Schedule regular domain controller backups, and destroy outofdate backup media.

Protect Backup Operators accounts.

Practice restoring domain controllers from backup media periodically.

Implement an enterprisewide, 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.

[Link] 5/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

When a domain controller is promoted, a special builtin 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 administratorlevel 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 highlyprivileged 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:
[Link] 6/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 onsite 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 diskintensive 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 Disadvantages

No domain controller backups at branch offices Easy to secure Higher risk of data loss

Least administrative overhead Long delays possible when restoring

a domain controller in the branch
office

Backups at all branch offices using remote Relatively easy to secure More administrative overhead
backup systems offline media in secure data
centers Reduced risk of delays in
restoring domain controller in
branch office

Backups at all branch offices using local backup Low risk of data loss Most administrative overhead
to disks online media
Least downtime when a domain Difficult to secure.
controller fails in 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.

Tapebackup 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.

[Link] 7/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 offpeak time to perform all the backups that you have
planned. Backing up a domain controller is a diskintensive operation that should be performed during offpeak 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 offpeak 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 offline 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:

[Link].[GC].[MD5].[Link], where:

FQCN is the fully qualified computer name.

Build is the build number of the operating system.

[Link] 8/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

OMRole indicates the operations master roles 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 builtin 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 builtin 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 Apply To

Allow Administrators List Contents This Object Only

Read All Properties

Write All Properties

Delete

Read Permissions

Modify Permissions

Modify Owner

All Validated Writes

All Extended Rights

Create All Child Objects

[Link] 9/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Delete All Child Objects

Allow Authenticated Users List Contents This Object Only

Read All Properties

Read Permissions

Allow Domain Admins List Contents 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 Enterprise Admins List Contents 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 Change Password This Object Only

Allow PreWindows 2000 Compatible Access List Contents Special

Read All Properties

Read Permissions

Allow SYSTEM Full Control This Object Only

[Link] 10/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 seldomused 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:

[Link] 11/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 scaleddown 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 scaleddown 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
[Link]

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 Recommendation

[Link] 12/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Hardware devices computers, hard Must be managed to ensure that all data has been destroyed and is not
drives recoverable before leaving the organization

Media tapes, hard drives, SANs, optical Must be erased or degaussed with an approved utility before being reused
disks, DVDRAM

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 DaytoDay Operations: Part I at [Link]
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 countermeasure, 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 DaytoDay
Operations: Part I at [Link]

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 highsecurity 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 highsecurity
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.

[Link] 13/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Table 4 Severity Ratings for Security Bulletins and Associated Hotfixes

Rating Definition

Critical A vulnerability whose exploitation can allow the propagation of an Internet worm without user action

Important A vulnerability whose exploitation can result in compromise of the confidentiality, 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
[Link] 14/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

In a large organization, an automatic method is required to ensure that all of the highsecurity 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, subscriptionbased service that alerts administrators to new
security updates. Register for this free service at: [Link]

An administrator must be responsible for reviewing any security updates and determining if the updates will be installed on
domain controllers, other highsecurity servers and administrative workstations. When using this notification method, select a
separate method for distributing and installing the updates.

Windows Update Service

[Link] 15/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 highsecurity servers include the following:

For security reasons, an organizations domain controllers and other highsecurity 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 highsecurity 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 highsecurity 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 highsecurity 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
[Link] 16/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 highsecurity 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
[Link]

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, securitypatch 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 Continue to use your current solution.
security updates

Using SMS and need a patchmanagement Implement the SMS security patch extensions contained in Systems
solution Management Server 2.0.

Not using SMS and need a patchmanagement Consider SMS, SUS, or thirdparty solutions to determine which one best
solution 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 Receive email notifications of updates. An administrator must review the updates and
Notification Service with determine if immediate distribution is required or if the update can wait until the next
Systems Management Server scheduled operating system update.
[Link] 17/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Windows Update Service Automatically download the update and then notify a local administrator that the
with Automatic Update update is available for installation.

Software Update Service Automatically download the update to the SUS server and then notify an administrator
with Automatic Update 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
Deploys Updates By
Method

Windows Configuring Windows Update to do one of the following:

Update
Service Inform an administrator who is interactively logged onto the Web server that updates are available
and then install the updates.

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

[Link] 18/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Audit To Verify the Update Installation

Method

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 denialof 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 denialof
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 denialofservice 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.

[Link] 19/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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.

[Link] 20/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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
toDay Operations: Part I at: [Link]

For more information on using smart cards authentication, see The Smart Card Deployment Cookbook at:
[Link]

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:

Passwordbased credentials for administrative accounts, then split the password between the two administrators.

Smart cardbased 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 DaytoDay Operations: Part I at:
[Link]

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, 14character passwords.

Ensure that a minimum number of trustworthy administrators can access to these passwords.
[Link] 21/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Information to Record About Each Component
Component

Audit policies
List of policies that are enabled.
For each policy, if success, failure, or both are enabled for auditing.

GPOs List of GPOs

Assignment of GPOs List of containers and OUs that have GPOs assigned.

For each container or OU, the specific GPOs that are assigned.

Existing trust relationships List of trusts.

Type of trust twoway or oneway

Names of trusting and trusted domains

Domain Controllers OU List of domain controllers.

Service Administrators OU List of administrative workstations.

[Link] 22/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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.

Replication topology List of sites.

Configuration settings for each site.

List of subnets within each site.

Configuration settings for each subnet.

List of manually created connections.

Configuration settings for each manually created connection.

List of site links.

Configuration settings for each site link.

Database characteristics Number of objects of each class in the database.

Size of the database file .DIT

Service packs and hotfixes for domain Current operating system.

controllers and administrative
workstations Current service packs.

Current hotfixes.

Current version of virus scan database.

Current version of the virus scan software.

System state for domain controllers and Collect initial system state status.
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

Audits of individuals with service Review the needs of these individuals for the legitimate need for administrative
administrator credentials access, and ensure they have the 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.

[Link] 23/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Update Review
Active Directory Infrastructure Component Detection by
Baseline 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 Daily None

report

[Link] 24/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Service packs and hotfixes for domain controllers and Automatic Weekly None
administrative workstations report

System state for domain controllers and administrative Automatic Daily None
workstations report

Current backup media exists Manual Weekly None

report

Directory backup media can restore domain controllers Manual Quarterly None
report

Audits of individuals with service administrator credentials Manual Quarterly Quarterly

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.

[Link] 25/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 patchmanagement solution implement SMS patch extension.

If you do not have SMS implement SMS, SUS, or a thirdparty 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 Forestwide Configuration Settings

[Link] 26/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

The following table provides a checklist of recommendations for managing forestwide configuration settings.

Managing ForestWide 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 administratorlevel 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

[Link] 27/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 healthchecking 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 securitysensitive 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 securitysensitive 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
[Link] 28/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 securitysensitive 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 DaytoDay
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, securitysensitive 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 eventspecific 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.

<computernam Unless otherwise noted, this variable indicates the domain controller where the operation was performed.
e>

<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 forestlevel changes.

2. Monitor domainlevel changes.

3. Monitor changes in the Service Administrators OU.

4. Monitor changes to the disk space consumed by Active Directory objects.

Monitoring ForestLevel Changes

Forestlevel changes in Active Directory have the broadest scope of any administrative operations, and as such they represent a
large security attack surface. Forestwide configuration changes include the following:
[Link] 29/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 forestwide 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

[Link] 30/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Event ID 565

User <username>

Computer <computername>

Additional Fields For Schema Object Creation Event

Description: Object Server: DS

Object Type: <objecttype>

Object Name: CN=Schema,CN=Configuration,DC=<domain>

Accesses: Create Child

Additional Fields For Schema Object Deactivation Event

Description: Object Server: DS

Object Type: <objecttype>

Object Name: CN=<attributeclassname>,CN=Schema,CN=Configuration,DC=<domain>

Accesses: Write Property

Properties: Write Property

?isDefunct

Additional Fields For Schema Object Modification Event

Description: Object Server: DS

Object Type: <objecttype>

Object Name: CN=<attributeclassname>,CN=Schema,CN=Configuration,DC=<domain>

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 Forestwide Corruption in Chapter 3 of this guide.

[Link] 31/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Description: Object Server: DS

Object Type: Computer

Object Name: OU=Domain Controllers,DC=<domain>

Accesses: Create Child

Additional Fields For Domain Controller Demotion Events

Description: Object Server: DS

Object Type: Computer

[Link] 32/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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>

Description: Object Server: DS

Object Type: Computer

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 slow
speed network segments, that they are in the same site and have highspeed network connectivity. This can potentially
saturate the network utilization of the slowspeed network segments and prevent domain controllers from receiving
timely updates.
[Link] 33/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Degrade performance by directing client traffic over slowspeed 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 slowspeed 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

Description: Object Server: DS

Object Type: Computer

Object Name: CN=Sites,CN=Configuration,DC=<domain>

[Link] 34/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Accesses: Create Child

Additional Fields For Site Deletion Events

Description: Object Server: DS

Object Type: site

Object Name: CN=Sites,CN=Configuration,DC=<domain>

Accesses: Delete Child

Additional Fields For Site Modification Events

Description: Object Server: DS

Object Type: site

Object Name: CN=<sitename>,Sites,CN=Configuration,DC=<domain>

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

Description: Object Server: DS

Object Type: %{00000000000000000000000000000000}

[Link] 35/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Object Name: CN=Subnets,CN=Sites,CN=Configuration,DC=<domain>

Accesses: Create Child

Properties: Create Child

subnet

Additional Fields For Subnet Deletion Events

Description: Object Server: DS

Object Type: Subnet

Object Name: CN=Subnets,CN=Sites,CN=Configuration,DC=<domain>

Accesses: Delete Child

Additional Fields For Subnet Modification Events

Description: Object Server: DS

Object Type: Subnet

Object Name: CN=<subnetname>,CN=Subnets,CN=Sites,CN=Configuration, DC=<domain>

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

[Link] 36/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Description: Object Server: DS

Object Type: siteLink

Object Name: CN=<transporttype>,CN=InterSite Transports,CN=Sites, CN=Configuration,DC=<domain>

Accesses: Create Child

Additional Fields For Site Link Deletion Events

Description: Object Server: DS

Object Type: siteLink

Object Name: CN=<transporttype>,CN=InterSite Transports,CN=Sites, CN=Configuration,DC=<domain>

Accesses: Delete Child

Additional Fields For Site Link Modification Events

Description: Object Server: DS

Object Type: siteLink

Object Name: CN=<sitelinkname>,CN=<transporttype>,CN=InterSite Transports, CN=Sites,

CN=Configuration,DC=<domain>

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>

[Link] 37/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Additional Fields For Connection Creation Events

Description: Object Server: DS

Object Type: nTDSConnection

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

Description: Object Server: DS

Object Type: nTDSConnection

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

Description: 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>

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 denialofservice 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.
[Link] 38/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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>

Description: Object Server: DS

Object Type: queryPolicy

Object Name: CN=Default Query Policy,CN=QueryPolicies,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 denialofservice attacks.
Unauthorized changes to the dSHeuristics attribute can indicate an attempt to breach Active Directory security.

Detection

[Link] 39/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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>

Description: Object Server: DS

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 Forestwide Operations Master Roles

Changes in forestwide 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 forestwide 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.

[Link] 40/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Detection

You can detect changes in forestwide 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 forestwide operations master roles is shown in the remaining sections of Table 21. In the case of
changes in forestwide operations master roles, <computername> is the name of the domain controller which currently holds the
operations master role.

Table 21 Detecting Changes in the Forestwide Operations Master Roles

Event field Relevant values

Common Fields For Changes in Forestwide 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

Description: Object Server: DS

Object Type: dMD

Object Name: CN=Schema,CN=Configuration,DC=<domain>

Accesses: Control Access

Properties: Control Access

Change Schema Master

Additional Fields For Changes in Domain Naming Master Role

Description: Object Server: DS

Object Type: crossRefContainer

Object Name: CN= Partitions,CN=Configuration,DC=<domain>

Accesses: Control Access

Properties: Control Access

[Link] 41/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Change Domain Master

Response

When you detect unauthorized changes in forestwide operations master roles, immediately transfer back, or if necessary seize,
the forestwide operations master roles to the configuration that you have documented. Documenting forestwide 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:
[Link]

Monitoring DomainLevel 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 domainwide configuration changes include the following:

Changes in domainwide 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 builtin groups, such as Administrators and Backup Operators

Changes to the audit policy settings for the domain.

Detecting Changes in Domainwide Operations Master Roles

Changes in domainwide operation master roles are critical to security because they affect the entire domain. Domainwide
operation master roles include the following:

Relative ID RID master

Primary domain controller PDC emulator master

Infrastructure master

Because domainwide 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 domainwide 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 domainwide operations master roles is shown in the remaining sections of
Table 22. In the case of changes in domainwide operations master roles, <computername> is the name of the domain controller
which currently holds the operations master role.

[Link] 42/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Table 22 Detecting Changes in the Domainwide Operations Master Roles

Event field Relevant values

Common Fields For Changes in Domainwide 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

Description: Object Server: DS

Object Type: rIDManager

Object Name: CN= RID Manager $,CN=Configuration,DC=<domain>

Accesses: Control Access

Properties: Control Access

Change RID Master

Additional Fields For Changes in PDC Emulator Master Role

Description: Object Server: DS

Object Type: domainDNS

Object Name: DC=<domain>

Accesses: Control Access

Properties: Control Access

Change PDC

Additional Fields For Changes in Infrastructure Master Role

Description: Object Server: DS

Object Type: infrastructureUpdate

[Link] 43/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Object Name: CN= Infrastructure,DC=<domain>

Accesses: Control Access

Properties: Control Access

Change Infrastructure Master

Response

When you detect changes in domainwide operations master roles, immediately restore the domainwide operations master
roles to their original configuration. Documenting your domainwide 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: [Link]

Detecting Changes in Trusts

Any changes in domain trusts can cause domainwide 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>

[Link] 44/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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:
[Link]

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>

Description: Object Server: DS

Object Type: container

[Link] 45/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Description: Object Server: DS

Object Type: groupPolicyContainer

Object Name: CN=Policies,CN=System,DC=<domain>

[Link] 46/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Accesses: Create Child

Additional Fields For Deletion of GPOs

Description: Object Server: DS

Object Type: groupPolicyContainer

Object Name: CN=Policies,CN=System,DC=<domain>

Accesses: Delete Child

Additional Fields For Modification of GPOs

Description: Object Server: DS

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.

[Link] 47/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Description: Object Server: DS

Object Type: domainDNS

Object Name: DC=<domain>

Accesses: Write Property

Properties: Write Property

gPLink

gPOptions

Additional Fields For Modification of GPO Assignments to Domain Controllers OU

Description: Object Server: DS

Object Type: organizationalUnit

Object Name: OU=DomainControllers,DC=<domain>

Accesses: Write Property

Properties: Write Property

gPLink

gPOptions

Response

[Link] 48/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 Builtin 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 builtin 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 builtin groups. Any
unauthorized changes to these groups can compromise the security of the domain.

Detection

You can detect changes in the membership of the builtin 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 builtin groups. <group> is the name of the builtin group that was modified.

Table 27 Detecting Changes in the Membership of Builtin Groups

Event field Relevant values

Source Security

Category Account Management

Type Success

Event ID 636

User <username>

Computer <computername>

Description: Member Name: <accountaddedremoved>

Target Domain: Builtin

Target Account ID: BUILTIN\<group>

Response

[Link] 49/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

If you detect unauthorized changes in the group membership of builtin groups, immediately restore the builtin group
membership to the original list of members. Documenting your builtin 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 builtin 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 securityrelated 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 Relevant values

Source Security

Category Account Management

Type Success

Event ID 612

User NT AUTHORITY\SYSTEM

Computer <computername>

Description: Audit Policy Change:

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.

AuditPolicyChange:
NewPolicy:
SuccessFailure
+Logon/Logoff
[Link] 50/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

ObjectAccess
++PrivilegeUse
+AccountManagement
+PolicyChange
+System
DetailedTracking
+DirectoryServiceAccess
+AccountLogon

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 [Link]

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

[Link] 51/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Description: Object Server: DS

Object Type: <objecttype>

Object Name: OU=Users and Groups,OU=Service Administrators,DC=<domain>

Accesses: Create Child

Additional Fields For Deletions in the Users and Groups OU

Description: Object Server: DS

Object Type: <objecttype>

Object Name: OU=Users and Groups,OU=Service Administrators,DC=<domain>

[Link] 52/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Accesses: Delete Child

Additional Fields For Modifications to the Accounts in the Users and Groups OU

Description: Object Server: DS

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

[Link] 53/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Description: Object Server: DS

Object Type: computer

Object Name: OU=Administrator Workstations,OU=Service Administrators,DC=<domain>

Accesses: Create Child

Additional Fields For Deletions to the Administrator Workstations OU

Description: Object Server: DS

Object Type: computer

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.
[Link] 54/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Description: Object Server: DS

Object Type: groupPolicyContainer

Object Name: CN=Policies,CN=System,DC=<domain>

Accesses: Create Child

Additional Fields For Deletion of GPOs

Description: Object Server: DS

[Link] 55/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Object Type: groupPolicyContainer

Object Name: CN=Policies,CN=System,DC=<domain>

Accesses: Delete Child

Additional Fields For Modification of GPOs

Description: Object Server: DS

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 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 securityrelated
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

[Link] 56/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Event ID 565

User <username>

Computer <computername>

Description: Object Server: DS

Object Type: domainDNS

Object Name: OU=Service Administrators,DC=<domain>

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 normalsized 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 largesized objects consume
the available disk space, also known as a largesized object attack.

Monitoring for a Rogue Object Flood Attack

In this situation, the attacker creates an inordinately large number of normalsized 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
[Link] 57/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

determine which objects are the rogue objects.

Detection

Detect a rogue object flood attack by performing the following tasks:

1. Create the [Link] script.

For more information about the [Link] 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 [Link] daily to collect the number of each objects of each object class
type in the domain.

You must run the [Link] script in the cscript environment from a command line or a batch file by entering
the following command:

[Link]

Note: The [Link] 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 [Link] into a database or spreadsheet to enable trend analysis of object
type counts in the domain.

The [Link] script creates a status file in commaseparated value CSV format, named ObjectClassCountdate
[Link], 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 longterm 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 Largesized 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 largesized 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.

[Link] 58/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 [Link] daily to collect the number of each objects of each object class
type in the domain.

You must run the [Link] script in the cscript environment from a command line or a batch file by entering
the following command line and then pressing ENTER:

[Link]

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 largesized 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 longterm response, identify the rogue objects in Active Directory and then remove
them. For more information on how to respond and recover from a largesized 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 DaytoDay Operations: Part I help to ensure that the domain controllers are deployed
in a secure manner. Monitoring securitysensitive 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 denialofservice
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:

[Link] 59/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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:[Link]*
'*Created:March2003*
'*Version:1.0*
'**
'*Description:Diagnosticutilitythatattemptstoconnecttothe*
'*rootDSEentryofanADdomaincontrollertoreturn*
'*[Link]*
'*anequivalentutilitytopingthatchecksforthe*
'*availabilityofthedirectoryserviceonanActive*
'*Directorydomaincontroller.*
'**
'*Compatibility:ThisscriptrequiresWSH5.6,CScript,ADSI*
'*andaccesstoActiveDirectory*
'**************************************************************************
OptionExplicit
'Defineanyconstantsusedinthisscript
ConstLDAP_SERVER_DOWN=&h8007203a
'Declareglobalvariables
DimobjArgs,strServerName,strMessage
'UseNamedArgumentscollectionforthecommandlineargument.
'TheWSHArgumentsObjectisincludedinWSHversion5.6andlater
SetobjArgs=[Link]
strServerName=[Link]("dc")
[Link]<1Then
CallUsage()
[Link]
[Link]("dc")Then
CallUsage()
[Link]
Else
strMessage=PingDS(strServerName)
[Link]
EndIf
'**********************************************************************
'*Routine:Usage
'**********************************************************************
SubUsage()
[Link]"Usage:dsping/dc:target_name"&VbCrLf&_
"Fortarget_name,specifytheipaddressorname(NetBIOSnameorFQDN)"&VbCrLf&_
"ofanActiveDirectorydomaincontroller."
EndSub
'**********************************************************************
'*Function:PingDS
[Link] 60/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

'**********************************************************************
FunctionPingDS(ServerName)
DimobjRootDSE,strDNSHostName
OnErrorResumeNext
SetobjRootDSE=GetObject("LDAP://"&serverName&"/rootDSE")
[Link]=LDAP_SERVER_DOWNThen
PingDS=ServerName&"didnotreply."
Else
OnErrorGoTo0
strDNSHostName="LDAP://"&[Link]("DnsHostName")
PingDS="DnsHostName:"&strDNSHostName&"replied."
EndIf
EndFunction

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 denialofservice 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

[Link] 61/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 nonsecurityrelated issues as well. Resolving these issues,
regardless of whether the intent was malicious or not, is the same. With securityrelated 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 Securityrelated Monitoring

Performance Indication of Health

Rationale
Counter Problem

Object: Greater than 80% Greater than 80% processor utilization indicates that the processor is over
Processor utilization on all utilized and the domain controller might be under a denialofservice attack.
processors
Counter: %
Processor
Time

Instance:
_Total

Object: Less than 25% of the total When less than 25% of the total disk space is available on the disk that contains
LogicalDisk disk space of each drive the database, a rogue object flood attack might be occurring.
on the domain controller
Counter: %
Free Space

Instance: all
instances

[Link] 62/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Object: Less than 10% of the When less than 10% of the physical memory is available, this indicates that the
Memory physical memory in the memory is overutilized and the domain controller might be under a denialof
domain controller service attack.
Counter:
Available
Bytes

Instance: N/A

Object: Increase of any kind A significant increase in pages/sec in conjunction with low Memory object and
Memory Available Bytes counter indicates that the memory is overutilized and that the
domain controller might be under a denialofservice attack.
Counter:
Pages/sec

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 Securityrelated Monitoring

Performance Indication of Health

Rationale
Counter Problem

Object: NTDS Trend of increase in A significant increase in the length of time to perform an LDAP bind can
length of time. indicates that the domain controller is over utilized and might be under a
Counter: LDAP denialofservice attack.
Bind Time

Instance: N/A

Object: NTDS Trend of decrease in A significant decrease in the number of successful LDAP binds can indicate that
number of successful the domain controller is over utilized and might be under a denialofservice
Counter: LDAP LDAP binds. attack.
Successful
Binds/sec

Instance: N/A

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:

[Link] 63/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 nonMicrosoft 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 pointintime list of the system state configuration settings and software inventory of the executables.

The pointintime snapshot of the computer provides a baseline for the software to use in determining when any changes
in the system state or executables occur.

[Link] 64/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Periodically compares the current system state configuration settings and list of executables to the pointintime list and
inventory.

The software compares the current system state and list of executables with the baseline to determine if:

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 DaytoDay Operations: Part . Install an administrative workstation by using the
recommendations in Securing Service Administrator Workstations in Chapter 4 in Securing Active Directory Installations and
DaytoDay 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.
[Link] 65/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 daytoday
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 forestlevel and domainlevel changes to Active
Directory and monitoring changes in service administrator accounts, administrative workstations, and disk space.

Monitoring Forestlevel 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 forestwide operations master roles.

[Link] 66/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Monitoring Domainlevel Changes

Detect changes in domainwide 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 builtin 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 normalsized objects.

Monitor for a limited number of extraordinarily largesized 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.

[Link] 67/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 preattack 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.

[Link] 68/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 forestwide 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.

[Link] 69/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 [Link] 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, rightclick 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 TicketGranting Tickets invalid

You must reset the Key Distribution Service Account KRBTGT password twice to invalidate ticketgranting 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.

[Link] 70/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

To reset the KRBTGT account password, open Active Directory Users and Computers, and find the krbtgt user account. Rightclick
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 passwordcracking 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 twofactor 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.

[Link] 71/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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:
[Link]

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:
[Link]

[Link] 72/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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:
[Link]

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
Entryname:AvoidPdcOnWan
Datatype: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 [Link] 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:

[Link]/r:DC

3. Apply the new registry value to the listed domain controllers by creating and running the [Link] script.

Important: When password change forwarding is disabled, the PDC emulator no longer has the most uptodate 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.

[Link] 73/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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
Entryname:ReplicatorNotifyPauseAfterModify
Datatype: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.

Entryname:ReplicatorNotifyPauseBetweenDSAs
Datatype: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 [Link] 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 [Link] in
Appendix B.

2. Create a list of domain controllers in the domain by typing the following command at a command prompt:

[Link]/r:DC

3. Apply the new registry value to the listed domain controllers by creating and running the [Link] 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, rightclick 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

[Link] 74/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 tradeoff. 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

[Link] 75/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

[Link] 76/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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: prerecovery, recovery, and postrecovery. 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 [Link]
displaylang=en&FamilyID=3EDA5A79C99B4DF9823C933FEBA08CFE.

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:

a. Making a list of all domain controllers.

b. 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.
[Link] 77/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 [Link]

/prodtechnol/ad/Windows2000/maintain/opsguide/Part2/[Link].

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 domainwide and forestwide 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 domainwide 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 TicketGranting 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.

[Link] 78/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

14. Finally, return the new domain controllers to the network, and rebuild the remaining domain controllers by performing
the following tasks:

a. Join the recovered domain controllers to your network.

b. Ensure that the global catalog flag is enabled for the domain controller in the forest root domain.

c. 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 prefailure configuration.

4. Enable the global catalog flag on domain controllers that were global catalog servers in the prefailure 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
[Link]

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 preattack 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.

[Link] 79/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

For details, see Restore from Backup in the Active Directory Operations Guide, Appendix B Procedures Reference, at:
[Link]

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:
[Link]

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: [Link]
/[Link]?displaylang=en&FamilyID=3EDA5A79C99B4DF9823C933FEBA08CFE

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 DiskSpace Attacks in Part I, Chapter
3, of this guide.

[Link] 80/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 [Link] and [Link] 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 [Link] script, see Monitoring the Number of Objects In a Domain
With [Link] in Appendix B of this guide. For information about how to create [Link] script, see
Identifying Objects Created or Modified Within A Period of Time With [Link] in the Appendix B of this guide.

3. Identify the current number of objects by object class by running the following command:

[Link]

[Link] creates an output file, ObjCountbyClass [Link], which contains the number of objects by
object class.

4. Examine the output file from [Link] and compare this output to previous [Link] 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 [Link], is a .CSV file, so you can view the output with an application such as
Microsoft Excel.

5. Identify a list of the objects created or modified during the timeframe determined in step 5 by running the following
command:

[Link] 81/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

[Link][/d:date][/t:time]/h:length

Where:

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:

[Link]/d:04012003/t:1500/h:20

[Link] creates an output file, [Link], that contains a list of the objects created or modified
during the length of time.

6. Examine the list and look for rogue a large number of objects of the type identified in Step 5.

The output of [Link], 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.

7. 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 [Link] tool, perform the following search.

BaseDN:Rootdomain
Scope:subtree
Filter:(usnCreated>=1000)
Attributes:usnCreated
Sorted:descendingorderofusnCreated
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.

3. Examine recently created objects, and try to discern which is the first rogue object:

a. 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.

[Link] 82/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

BaseDN:Rootdomain
Scope:subtree
Filter:(usnCreated>=SearchValue)
Attributes:usnCreated,DN,objectCategory
Sorted:descendingorderofusnCreated
Paged:yes

b. This search generates a list of objects with a usnCreated value greater than SearchValue. Examine each of these
objects, looking for rogue objects.

c. 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.

d. 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.

4. Discern which objects created after the first rogue object are rogue objects and which are legitimate.

5. 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:

BaseDN:Rootdomain
Scope:subtree
Filter:(usnCreated>=RogueObjectusnCreated)
Attributes:DN
Sorted:descendingorderofusnCreated
Paged:yes

6. 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.

7. Examine each object that is returned in this search, looking for patterns in rogue objects. Some patterns to look for
include the following:

Objects that are created with the same parent object.

Objects that have similar attributes.

8. 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.

[Link] 83/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

The tombstone lifetime setting and the garbage collection interval are forestwide 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:

Object:cn=DirectoryService,cn=WindowsNT,cn=Service,cn=Configuration,dc=<DOMAIN>
,Attribute:TombstoneLifetimeValue:ndays

3. Decrease the garbage collection interval to its minimum value of one hour.

4. As the tombstone lifetime expires for the deleted rogue objects, delete them permanently as quickly as possible to free
up disk space.

5. Use the LDAP tool to make the modification described below:

Object:cn=DirectoryService,cn=WindowsNT,cn=Service,cn=Configuration,dc=<DOMAIN>,
Attribute:GarbageCollectionValue:1hour

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
Entryname:6GarbageCollection
Datatype: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

[Link] 84/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 DiskSpace 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 [Link] and [Link] 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 [Link] script, see Identifying Objects Created or Modified Within A Period
of Time With [Link] in Appendix B of this guide. For information about how to create [Link] script,
see Identifying Largesized Objects with [Link] in Appendix B of this guide.

3. Identify the potential rogue objects by running the following command:

[Link][/d:date][/t:time]/h:length

Where:

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.

[Link] 85/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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:

[Link]/d:04012003/t:1500/h:2

[Link] creates an output file, [Link], that contains a list of the objects created or modified
during the length of time.

4. Determine the size of the objects created or modified within a specific timeframe by running the following command:

[Link]/f:input_file

Where input_file is the name of the file created by [Link] in step 3.

[Link] creates an output file, [Link], that contains a list of the objects created in step 3,
along with their size.

5. Examine the list, and look for rogue large objects.

The output of [Link], is a .CSV file; you can view the output with an application such as Microsoft
Excel.

6. For each object that seems to be questionably large, determine if the object should remain in Active Directory and do one
of the following:

a. If the object should not remain in Active Directory, delete it.

b. 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.

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

[Link] 86/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Use the [Link] 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 TicketGranting 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

[Link] 87/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 TicketGranting 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

[Link] 88/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 forestwide corruption.

Recovering from Catastrophic Forestwide Corruption

Perform prerecovery 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

[Link] 89/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 [Link] 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.

[Link] 90/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 [Link] and [Link] scripts on a workstation and copy them to the affected
domain controller.

Create a list of potential rogue objects by running the [Link] script.

Determine the size of each object listed by running the [Link] 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.

[Link] 91/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

[Link] 92/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 ticketgranting 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 [Link]
You can use the [Link] script to apply registry settings to the computers you identified by using the [Link]
script. Before you can use the [Link] 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 [Link] script has the following syntax:

[Link]/r:registry_file/f:computer_file

Where:

registry_file is a .REG file that was created by using [Link].

computer_file is a .CSV file that was created manually or by using [Link].

[Link] applies the registry settings specified in registry_file to each computer specified in computer_file.

To create the [Link] script

1. Open Notepad

2. Copy or type the following script into Notepad

''Addcomputercan'tbefoundinADwhenthebindingoperationfails
'**************************************************************************
'*File:[Link]*
'*Created:April2003*
'*Version:1.0*
'**
'*Description:[Link]*
'*theregistryofeachavailableandaccessible*
'*computerspecifiedinthecsvreportcreatedbythe*
'*[Link].*
'*Thisscriptgeneratesareportthatincludesthe*
'*[Link]*
'*wasattemptedandwhethertheapplicationwas*
'*successfulatapplyingthechange.*
'**

[Link] 93/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

'*Compatibility:ThisscriptrequiresWSH5.6,CScript,ADSI,WMI*
'*andaccesstoActiveDirectory*
'**************************************************************************
OptionExplicit
'Defineconstants
ConstForReading=1
ConstTristateUseDefault=2
ConstForAppending=8
'Declareglobalvariables
DimobjArgs,strRptFileName,strRegFileName
DimobjDictionary,strFileName,objFSO,objFile,objRegFile
DimobjRptFile,objRegExp,objShell,iRecord,strLine
DimarrComptInfo,strDN,strComputer,strNotes
DimobjExec,strPingStdOut,objRegistry
DimobjTextStream,ColRootKey,Key,strKey,strKeyPath
DimstrStatus,iCnt
CallCheckForCScript()
'UseNamedArgumentscollectionforthecommandlineargument.
'TheWSHArgumentsObjectisincludedinWSHversion5.6andlater
SetobjArgs=[Link]
strRptFileName=[Link]("f")
strRegFileName=[Link]("r")
[Link]<2Then
[Link]"Youmustspecifyacsvfilename"&VBCrLf&_
"[Link]"&VbCrLf&_
"[Link]."&VbCrLf&VbCrLf&_
SampleCommandLine()
[Link]
EndIf
'Useadictionaryobjectfortheconstantsthatdefine
'therootkeys
SetobjDictionary=CreateObject("[Link]")
[Link]"HKEY_LOCAL_MACHINE",&h80000002
[Link]"HKEY_CLASSES_ROOT",&h80000000
[Link]"HKEY_CURRENT_USER",&h80000001
[Link]"HKEY_USERS",&h80000003
[Link]"HKEY_CURRENT_CONFIG",&h80000005
'CalltheGenFileNamefunctiontocreateauniquefilenameforthereport
strFileName=GenFileName("ApplyReg")
'Createatextfile(.csvformat)toholdthe
'resultsofthereport.
SetobjFSO=CreateObject("[Link]")
'Thiswilloverwritethefileifitalreadyexists.
SetobjFile=[Link](strFileName,True)
[Link]
SetobjFile=[Link](strFileName,ForAppending)
'Writetheheadingsforthiscsvfile
[Link]"DistinguishedName,"&_
"ComputerName,Status,Notes"
'Gettheregistryfile
SetobjRegFile=[Link](strRegFileName)
'Openthecomputersearchreportfileforreading
SetobjRptFile=[Link](strRptFileName,ForReading)
'Skiptheheaderrowofthereport
[Link]
'CreatetheRegularExpressionobject
SetobjRegExp=NewRegExp

[Link] 94/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

'SetsomeglobalpropertiesfortheRegExpobject
[Link]=FALSE
[Link]=TRUE
[Link]=FALSE
'[Link]
SetobjShell=CreateObject("[Link]")
iRecord=1
[Link]"Reportrecordsprocessed:"
[Link]<>TRUE
strLine=[Link]
'Bindtodnofacomputerlistedinthereportfile.
arrComptInfo=Split(BindDN(strLine),"||")
strDN=arrComptInfo(0)
strComputer=arrComptInfo(1)
'Aninvaliddnisspecifiedinthereportfile
IfstrComputer="None"Then
strNotes=arrComptInfo(2)&"distinguishednamespecified"
strStatus="Unabletoconnecttothespecifieddn."
Else
strNotes=arrComptInfo(2)&"nameusedforremoteconnection."
'Beforeconnectingtothecomputer,usepingtoseeifyougetaresponse.
'AWMIconnectionattemptisnotusedbecauseWMI'sconnectiontimeoutinterval
'istoolong
SetobjExec=[Link]("pingn2w1000"&strComputer)
strPingStdOut=LCase([Link])
'Testwhetherpingwassuccessful
IfInStr(strPingStdOut,"replyfrom")Then
'Attempttoconnecttotheregistryprovideronaremotecomputer
SetobjRegistry=GetObject("winmgmts:{impersonationLevel=impersonate}!\\"&_
strComputer&"\root\default:StdRegProv")
OnErrorResumeNext
[Link]<>0Then
'Storethefollowinglinetowritetothestatuscolumnforthiscomputer.
'Typicalcausesoffailure:
'WMInotrunningoroperatordoesnothavepermissiontomakearemoteconnection.
strStatus=[Link]
[Link]
OnErrorGoTo0
Else
'Performtheregistryupdate
SetobjTextStream=[Link](ForReading,TristateUseDefault)
[Link]<>TRUE
'Readalineofdata
strLine=[Link]
'Matchrootkeysandpaths
[Link]="(^\[HKEY_\w+[^\\])(.*)"
[Link](strLine)=TRUEThen'Createthekey
SetColRootKey=[Link](strLine)
ForEachKeyinColRootKey
strKey=Mid([Link](0),2)
strKeyPath=Mid([Link](1),2,Len(Trim([Link](1)))2)
[Link](strKey),strKeyPath
Next
Else'Createvaluenamesandvaluesforthekey
'Matchstrings:"valuename"="value"
[Link]="(\x22.*\x22=\x22)(.*)"
[Link](strLine)=TRUEThen

[Link] 95/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

CallCreateString(strLine)
EndIf
'MatchBinarydata:"valuename"=hex:
[Link]="(\x22.*\x22=hex:)(.*)"
[Link](strLine)=TRUEThen
CallCreateBinary(strLine)
EndIf
'MatchDWORDdata:"valuename"=dword:
[Link]="(\x22.*\x22=dword:)(.*)"
[Link](strLine)=TRUEThen
CallCreateDWORD(strLine)
EndIf
'MatchExpandablestring:"valuename"=hex(2):
[Link]="(\x22.*\x22=hex\(2\):)(.*)"
[Link](strLine)=TRUEThen
CallCreateExpString(strLine)
EndIf
'MatchMultistring:"valuename"=hex(7):
[Link]="(\x22.*\x22=hex\(7\):)(.*)"
[Link](strLine)=TRUEThen
CallCreateMultiString(strLine)
EndIf
'[Link],thescripthasencountered
'anotherregistrykeytoapply.
EndIf
Loop
strStatus="Registryupdateapplied."
EndIf
Else
'Storethefollowinglinetowritetothestatusandnotescolumnsforthiscomputer
strStatus="Hostunreachable"
strNotes="Verifythatthishostisonline."
EndIf
EndIf
[Link](34)&strDN&Chr(34)&","&strComputer&_
","&strStatus&","&strNotes
'Displayarecordcounter
ForiCnt=1toLen(iRecord)
[Link](8)
Next
[Link]
iRecord=iRecord+1
Loop
[Link]&VbCrLf&"Thereportdatahasbeensavedto:"&_
strfileName&"."&VbCrLf&_
"ImportoropentheCSVdatainaspreadsheet"&VbCrLf&_
"ordatabaseprogramtodeterminewhichcomputerswereupdated."
'**********************************************************************
'*Routine:CreateString
'**********************************************************************
SubCreateString(Line)
DimColEntries,Entry,strValueName,strValue
SetColEntries=[Link](Line)
ForEachEntryinColEntries
strValueName=Mid([Link](0),2,Len(Trim([Link](0)))4)
strValue=Mid([Link](1),1,Len(Trim([Link](1)))1)
[Link](strKey),strKeyPath,strValueName,strValue

[Link] 96/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Next
EndSub
'**********************************************************************
'*Routine:CreateBinary
'**********************************************************************
SubCreateBinary(Line)
DimarrValue(),ColEntries,Entry,strValueName,arrHexValue,i,HexVal
SetColEntries=[Link](Line)
ForEachEntryinColEntries
strValueName=Mid([Link](0),2,Len(Trim([Link](0)))7)
'Usethesplitfunctiontocreateanarraysothateachhexvaluecanbe
'appendedwithan&hvalueinthenextForEachstatement
arrHexValue=Split(Trim([Link](1)),",")
'Declareadynamicarraytoholdtheproperlyformattedhexvaluesto
'bepassedtotheWMISetBinaryValuemethod.
i=0
ForEachHexValinarrHexValue
RedimPreservearrValue(i)
arrValue(i)="&h"&HexVal
i=i+1
Next
[Link](strKey),strKeyPath,strValueName,arrValue
RedimarrValue(0)
Next
EndSub
'**********************************************************************
'*Routine:CreateDWORD
'**********************************************************************
SubCreateDWORD(Line)
DimColEntries,Entry,strValueName,intValue
SetColEntries=[Link](Line)
ForEachEntryinColEntries
strValueName=Mid([Link](0),2,Len(Trim([Link](0)))9)
'ConvertthehexvaluethatwillbepassedtotheWMI
'SetDWORDValuemethod,toadecimaldatatype
intValue=CInt("&h"&Trim([Link](1)))
[Link](strKey),strKeyPath,strValueName,intValue
Next
EndSub
'**********************************************************************
'*Routine:CreateExpString
'**********************************************************************
SubCreateExpString(Line)
DimarrValue(),ColEntries,Entry,strValueName,strValueFirstLine
DimstrValueMiddleLines,strValueLastLine,strExpandableString,HexVal
DimstrExpandableStringFormatted,arrItems
SetColEntries=[Link](Line)
ForEachEntryinColEntries
strValueName=Mid([Link](0),2,Len(Trim([Link](0)))10)
strValueFirstLine=Trim([Link](1))
Next
'Readanotherlinetotestfordatathatmightbelongtoanexpandablestringentry
strLine=[Link]
'Matchadditionallinesofexpandablestringdata:nn,nn,nn...\
[Link]="(^\s{2}[09{1,2}|af{1,2},]+\\$)"
[Link](strLine)=TRUE
SetColEntries=[Link](strLine)

[Link] 97/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

ForEachEntryinColEntries
strValueMiddleLines=strValueMiddleLines&Trim([Link](0))
Next
'Readanotherlinetotestfordatathatmightbelongtothemiddlelinesof
'anexpandablestringentry
strLine=[Link]
Loop
'Matchthelastlineofaexpandablestringexpression
[Link]="(^\s{2}[09{1,2},|af{1,2},]+[09{1,2}$|af{1,2}$])"
[Link](strLine)Then
SetColEntries=[Link](strLine)
ForEachEntryinColEntries
strValueLastLine=Trim([Link](0))
Next
EndIf
'Combinetheexpandablestringvalue
strExpandableString=strValueFirstLine&strValueMiddleLines&strValueLastLine
'Removethe"\"characterfromstrExpandableStringValue
[Link]="\\"
strExpandableStringFormatted=[Link](strExpandableString,"")
'Converttoanarrayforformattingeachvalue
arrItems=Split(strExpandableStringFormatted,",")
ForEachHexValinarrItems
RedimPreservearrValue(i)
IfHexVal<>"00"Then
arrValue(i)=CStr(Chr(CInt("&h"&HexVal)))
strData=strData&arrValue(i)
i=i+1
EndIf
Next
'Addtheexpandablestringtotheregistry
[Link](strKey),strKeyPath,strValueName,strData
EndSub
'**********************************************************************
'*Routine:CreateMultiString
'**********************************************************************
SubCreateMultiString(Line)
DimarrArgData(),ColEntries,Entry,strValueName,strValueFirstLine
DimstrValueMiddleLines,strValueLastLine,strMultiString
DimstrMultiStringFormatted,arrLine,iArgs
DimHexVal,arrItems,arrValue,strData
SetColEntries=[Link](Line)
ForEachEntryinColEntries
strValueName=Mid([Link](0),2,Len(Trim([Link](0)))10)
strValueFirstLine=Trim([Link](1))
Next
'Readanotherlinetotestfordatathatmightbelongtoamultistringentry
strLine=[Link]
'Matchadditionallinesofmultistringdata:nn,nn,nn...\
[Link]="(^\s{2}[09{1,2}|af{1,2},]+\\$)"
[Link](strLine)=TRUE
SetColEntries=[Link](strLine)
ForEachEntryinColEntries
strValueMiddleLines=strValueMiddleLines&Trim([Link](0))
Next
'Readanotherlinetotestfordatathatmightbelongtothemiddle
'linesofamultistringentry

[Link] 98/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

strLine=[Link]
Loop
'MatchthelastlineofaMultistringexpression
[Link]="(^\s{2}[09{1,2},|af{1,2},]+[09{1,2}$|af{1,2}$])"
[Link](strLine)Then
SetColEntries=[Link](strLine)
ForEachEntryinColEntries
strValueLastLine=Trim([Link](0))
Next
EndIf
'Combinetheexpandablestringvalue
strMultiString=strValueFirstLine&strValueMiddleLines&strValueLastLine
'Removethe"\"characterfromstrMultiStringValue
[Link]="\\"
strMultiStringFormatted=[Link](strMultiString,"")
'Eachlineisdelimitedby"00,00,00".Createseperatestringsforeachline.
'EachlineisanargumentinthearraysuppliedtotheSetMultiStringValuemethod.
arrLine=Split(strMultiStringFormatted,"00,00,00")
iArgs=0
'Converteachitemineachlinetostringdata
ForEachLineinarrLine
IfLine<>""ANDTrim(Line)<>","Then
'Removecommaspaddingthebeginningand/ortheend.
IfInstr(1,Line,",")=1Then
Line=Mid(Line,2)
EndIf
IfInstr(Len(Line),Line,",")=Len(Line)Then
Line=Mid(Line,1,Len(Line)1)
EndIf
'Spliteachitemineachlineforconversion.
arrItems=Split(Line,",")
i=0
'Converteachhexvaluetocharacterdata.
ForEachHexValinarrItems
RedimPreservearrValue(i)
IfHexVal<>"00"Then
arrValue(i)=CStr(Chr(CInt("&h"&HexVal)))
strData=strData&arrValue(i)
i=i+1
EndIf
Next
RedimPreservearrArgData(iArgs)
arrArgData(iArgs)=strData
strData=""
iArgs=iArgs+1
EndIf
Next
[Link](strKey),strKeyPath,strValueName,arrArgData
RedimarrArgData(0)
EndSub
'**********************************************************************
'*Routine:CheckForCScript
'**********************************************************************
SubCheckForCScript
'Thisscriptmustrunfromcscriptbecause
'[Link].
'Testthescripthostandifit'snotcscript,

[Link] 99/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

'instructtheoperatoronhowtorunthescript.
IfRight(LCase([Link]),11)<>LCase("[Link]")Then
[Link]"Thisscriptmustrunfromcscript."&_
VbCrLf&"Example:[Link]/f:[Link]/r:[Link]"
[Link]
EndIf
EndSub
'**********************************************************************
'*Function:PadZero
'**********************************************************************
FunctionPadZero(dtValue)
IfLen(dtValue)=1Then
PadZero=0&dtValue
Else
PadZero=dtValue
EndIf
EndFunction
'**********************************************************************
'*Function:GenFileName
'**********************************************************************
FunctionGenFileName(prefix)
'Createauniquetimestampednameforthetextfile
DimdtDate,strYear,strMonth,strDay,strDate
DimdtNow,strHour,strMinute,strSecond,strTime
dtDate=Date()
strYear=Mid(Year(dtDate),3)
strMonth=PadZero(Month(dtDate))
strDay=PadZero(Day(dtDate))
strDate=strYear&strMonth&strDay&""
dtNow=Now()
strHour=PadZero(Hour(dtNow))
strMinute=PadZero(Minute(dtNow))
strSecond=PadZero(Second(dtNow))
strTime=strHour&strMinute&strSecond
GenFileName=prefix&""&strDate&strTime&".csv"
EndFunction
'**********************************************************************
'*Function:SampleCommandLine
'**********************************************************************
FunctionSampleCommandLine()
SampleCommandLine=_
"Forexample,toapplyregistrychangesspecifiedin"&VbCrLf&_
"[Link],toallcomputerslistedin"&VbCrLf&_
"[Link],type:"&VbCrLf&_
"[Link]/r:[Link]/f:[Link]"
EndFunction
'**********************************************************************
'*Function:BindDN
'**********************************************************************
FunctionBindDN(Line)
ConstE_ADS_PROPERTY_NOT_FOUND=&h8000500D
ConstLDAP_NO_SUCH_OBJECT=&h80072030
DimstrDN,objComputer,strComptName
'UseInstrtogetthedistinguishedNamecolumnforwritingtothe
'firstcolumnofthereport.
strDN=Mid(Line,2,Instr(1,Line,Chr(34)&Chr(44))2)
'BindtothecomputerinAD

[Link] 100/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

OnErrorResumeNext
SetobjComputer=GetObject("LDAP://"&strDN)
[Link]=LDAP_NO_SUCH_OBJECTThen
'TheGetObjectmethodwasunabletobindtothespecified
'[Link].
BindDN=strDN&"||None||Invalid"
Else
'GetthedNSHostNameofthecomputer
strComptName=[Link]("dNSHostName")
'IfthedNSHostNameattributeisset,useitfortheregistryupdate.
[Link]<>E_ADS_PROPERTY_NOT_FOUNDThen
BindDN=strDN&"||"&strComptName&"||Host"
[Link]
'IfthedNSHostNameattributeisnotsetthenuse
'thecnfortheregistryupdate.
Else
strComptName=[Link]("cn")
BindDN=strDN&"||"&strComptName&"||NetBIOS"
EndIf
EndIf
[Link]
OnErrorGoTo0
EndFunction

3. Save the file as [Link]

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, rightclick Security Configuration and Analysis and then click Open Database.

If you are creating a new database:

a. For File name, type FileName and then click Open.

b. 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, rightclick Security Configuration and Analysis, and then click Analyze Computer Now.

5. Do one of the following:

a. To use the default log, in Error log file path, click OK.

b. To specify a different log, in Error log file path, type a valid path and file name.

Changing the Priority for DNS SRV Records

[Link] 101/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 [Link] 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. Doubleclick 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 [Link] 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. Doubleclick the value name you just typed to open the Edit DWORD Value dialog box.

[Link] 102/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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: [Link], [Link]

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. Doubleclick 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 [Link].

5. Paste the event copied in Step 3 into Notepad.

6. At a command prompt, type the following without pressing ENTER:

[Link]"<domain>"r"cn=<guid>)"ldisplayName,cn

[Link] 103/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

7. 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:

[Link]"DC=corp,DC=contoso,DC=com"r
"cn={31B2F340016D11D2945F00C04FB984F9})"ldisplayName,cn

8. Open [Link] 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

SetobjConnection=CreateObject("[Link]")
[Link]"Provider=ADsDSOObject;"
SetobjCommand=CreateObject("[Link]")
[Link]=objConnection
[Link]=_
"<LDAP://ou=Management,dc=NA,dc=fabrikam,dc=com>;"&_
"(&(objectCategory=Person)(objectClass=user));"&_
"ADsPath;subtree"
SetobjRecordSet=[Link]
[Link]
strADsPath=[Link]("ADsPath")
SetobjUser=GetObject(strADsPath)
[Link]"pwdLastSet",0
[Link]
[Link]
Wend
[Link]&_
"useraccountobjectsmustchangethe"&_
"passwordatnextlogon."
[Link]

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 [Link]

You can use the [Link] script to help identify computers objects in Active Directory so that you can subsequently
apply registry settings to the list of computers identified by [Link]. Before you can use the [Link]
script, you must create the script based on the source code included in this document.

[Link] 104/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Note: This script requires Windows 2000 with Service Pack 3 or later and Windows Scripting Host version 5.6 or later.

The [Link] script has the following syntax:

[Link][/r:role]

Where role can be DC for domain controllers or MC for member computers.

If you omit role, then [Link] will return both domain controllers and member computers.

[Link] creates an output file, [Link], which contains a list of the computer objects found
in Active Directory.

To create the [Link] script

1. Open Notepad

2. Copy or type the following script into Notepad

'**************************************************************************
'*File:[Link]*
'*Created:March2003*
'*Version:1.0*
'**
'*Description:Diagnosticutilitythatreturnsareportcontaining*
'*thedistinguishednamesofcomputersinthedomain*
'*(domaincontrollers,membercomputersorboth).This*
'*reportcanbeviewedinaspreadsheetordatabase*
'*[Link]*
'*registrychangestoallthecomputerslistingin*
'*thereport.*
'**
'*Compatibility:ThisscriptrequiresWSH5.6,CScript,ADSI,*
'*andaccesstoActiveDirectory*
'**************************************************************************
OptionExplicit
'Defineanyconstantsusedinthisscript
'Denotesaworkstation:
ConstADS_UF_WORKSTATION_TRUST_ACCOUNT=&h1000
'DenotesaDC:
ConstADS_UF_SERVER_TRUST_ACCOUNT=&h2000
ConstForAppending=2
DimobjArgs,strRole
DimobjRootDSE,strDomain
DimobjConnection,objCommand,objRecordSet
DimstrFileName,objFSO,objFile
CallCheckForCScript
'UseNamedArgumentscollectionforthecommandlineargument.
'TheWSHArgumentsObjectisincludedinWSHversion5.6andlater
SetobjArgs=[Link]
strRole=UCase([Link]("r"))
[Link]<1Then
[Link]"Norolewasspecifiedonthecommandline."&VbCrLf&_
"Therefore,thereportwilllistbothdomaincontrollerand"&VbCrLf&_
"membercomputersinthedomain."&VbCrLf&_

[Link] 105/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

"Possiblerolesare:dc(domaincontroller)ormc(membercomputer)."
EndIf
[Link]("r")Then
IfstrRole<>"DC"ANDstrRole<>"MC"Then
[Link]()
[Link]
EndIf
EndIf
'UsetheRootDSEobjectforupcomingsearchoperation
SetobjRootDSE=GetObject("LDAP://rootDSE")
'Bindtothecurrentdomain
'UsetospecifythesearchbasefortheLDAPsearch
strDomain="<LDAP://"&_
[Link]("defaultNamingContext")&">"
SetobjConnection=CreateObject("[Link]")
[Link]"Provider=ADsDSOObject;"
SetobjCommand=CreateObject("[Link]")
[Link]=objConnection
[Link]=strDomain&_
";(objectCategory=computer);"&_
"distinguishedName,userAccountControl;subtree"
'"distinguishedName,userAccountControl,samAccountName,dNSHostName;subtree"
'Specifypagesizeforthiscommandobject.
'Thisisnecessarytoavoidoverutilizationofserver
'[Link],bydefault,
'only1000recordswillbereturnedifpagingisn't
'[Link]
'than1000computerobjects.
[Link]("PageSize")=256
[Link]("Asynchronous")=True
[Link]("Cacheresults")=False
'Runthecomputerobjectquery
SetobjRecordSet=[Link]
'Createauniquefilename(timestamp)usingtheGenFileNamefunction
strFileName=GenFileName("ComputerSearch")
'Createatextfile(.csvformat)toholdthe
'resultsoftheclasstest.
SetobjFSO=CreateObject("[Link]")
'Thiswilloverwritethefileifitalreadyexists.
SetobjFile=[Link](strFileName,True)
[Link]
SetobjFile=[Link](strFileName,ForAppending)
CallPopulateReport
[Link]
[Link]&"Thereportdatahasbeensavedto:"&strfileName&"."
'**********************************************************************
'*Routine:PopulateReport
'**********************************************************************
SubPopulateReport
OnErrorResumeNext
DimstrRecord,iCnt,i
i=0
[Link]"distinguishedName,Role"
[Link]
IfstrRole=""Then
IfADS_UF_SERVER_TRUST_ACCOUNTANDobjRecordset.Fields("userAccountControl")Then
strRecord=GenRecord&"DomainController"

[Link] 106/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

[Link]
i=i+1
ElseIfADS_UF_WORKSTATION_TRUST_ACCOUNTANDobjRecordset.Fields("userAccountControl")Then
strRecord=GenRecord&"WorkstationorServer"
[Link]
i=i+1
EndIf
ElseIfstrRole="DC"Then
IfADS_UF_SERVER_TRUST_ACCOUNTANDobjRecordset.Fields("userAccountControl")Then
strRecord=GenRecord&"DomainController"
[Link]
i=i+1
EndIf
ElseIfstrRole="MC"Then
IfADS_UF_WORKSTATION_TRUST_ACCOUNTANDobjRecordset.Fields("userAccountControl")Then
strRecord=GenRecord&"WorkstationorServer"
[Link]
i=i+1
EndIf
EndIf
'Progressindicator
ForiCnt=1toLen(i)+35
[Link](8)
Next
[Link]"Currentnumberofcomputersfound:"&i
[Link]
Wend
EndSub
'**********************************************************************
'*Routine:CheckForCScript
'**********************************************************************
SubCheckForCScript
'Thisscriptmustrunfromcscriptbecause
'[Link].
'Testthescripthostandifit'snotcscript,
'instructtheoperatoronhowtorunthescript.
IfRight(LCase([Link]),11)<>LCase("[Link]")Then
[Link]"Thisscriptmustrunfromcscript."&_
VbCrLf&"Example:[Link]"
[Link]
EndIf
EndSub
'**********************************************************************
'*Function:PadZero
'**********************************************************************
FunctionPadZero(dtValue)
IfLen(dtValue)=1Then
PadZero=0&dtValue
Else
PadZero=dtValue
EndIf
EndFunction
'**********************************************************************
'*Function:GenFileName
'**********************************************************************
FunctionGenFileName(prefix)
'Createauniquetimestampednameforthetextfile

[Link] 107/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

DimdtDate,strYear,strMonth,strDay,strDate
DimdtNow,strHour,strMinute,strSecond,strTime
dtDate=Date()
strYear=Mid(Year(dtDate),3)
strMonth=PadZero(Month(dtDate))
strDay=PadZero(Day(dtDate))
strDate=strYear&strMonth&strDay&""
dtNow=Now()
strHour=PadZero(Hour(dtNow))
strMinute=PadZero(Minute(dtNow))
strSecond=PadZero(Second(dtNow))
strTime=strHour&strMinute&strSecond
GenFileName=prefix&""&strDate&strTime&".csv"
EndFunction
'**********************************************************************
'*Function:SampleCommandLine
'**********************************************************************
FunctionSampleCommandLine()
SampleCommandLine=_
"Specifythe/rparametertolimitthecomputerlistto"&VbCrLf&_
"onlydomaincontrollersoronlymembercomputersinthedomain."&VbCrLf&_
"[Link]/r:dc"&VbCrlf&_
"or"&VbCrlf&_
"[Link]/r:mc"
EndFunction
'**********************************************************************
'*Function:GenRecord
'**********************************************************************
FunctionGenRecord()
DimstrRecord
strRecord=chr(34)&[Link]("distinguishedName")&chr(34)&","
GenRecord=strRecord
EndFunction

3. Save the file as [Link].

Identifying Large-sized Objects with [Link]

You can use the [Link] script to help find rogue objects in Active Directory that are consuming a significant amount of
disk space. Before you can use the [Link] 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 [Link] script has the following syntax:

[Link]/f:input_file[/s:object_size]

Where:

input_file is the name of the file, including path, created by [Link].

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.

[Link] 108/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

[Link] creates an output file, [Link], which contains a list of the objects listed in the file created by
[Link] and the size of each object.

Note: [Link] 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 [Link] is
negligible.

To create the [Link] script.

1. Open Notepad.

2. Copy or type the following script into Notepad.

**************************************************************************
'*File:[Link]*
'*Created:April2003*
'*Version:1.0*
'**
'*Description:Securitydiagnosticutilitythatcreatesareport*
'*[Link]*
'*[Link]*
'*toestimatethesizeofthecreatedormodified*
'*objects.*
'**
'*Notes:ThisscriptusestheRawperformancecounterclass*
'*fortworeasons:*
'*[Link](calculated)counterisnotcurrently*
'*availableinWindows2000.*
'*[Link]*
'*PERF_COUNTER_LARGE_RAWCOUNT,whichdoesn'trequire*
'*anyfurthercalculationsbutthecookedcounter*
'*is64bitsinlengthtosupportverylargevalues.*
'**
'*Compatibility:ThisscriptrequiresWSH5.6,CScript,ADSI,WMI,*
'*andaccesstoActiveDirectory*
'**************************************************************************
OptionExplicit
'Defineanyconstantsusedinthisscript
ConstForAppending=2
ConstForReading=1
'Declareglobalvariables
DimobjArgs,strRptFileName,intSize,strFileName
DimobjFSO,objFile,objRptFile
DimobjRootDSE,strDomain,objADObject
DimstrLine,strDN
DimintWSBefore,intWSAfter
Dimi,iCnt,intObjSizeBaseline
DimintCurObjSize,intCalculatedSize
CallCheckForCScript()
'UseNamedArgumentscollectionforthecommandlineargument.
'TheWSHArgumentsObjectisincludedinWSHversion5.6andlater
SetobjArgs=[Link]
strRptFileName=[Link]("f")
intSize=Round(Abs([Link]("s")))*1024
'Verifythecommandlinearguments
[Link] 109/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

IfValidArgsTesting()=[Link]
'CalltheGenFileNamefunctiontocreateauniquefilenameforthereport
strFileName=GenFileName("objMemUse")
'Createatextfile(.csvformat)forthereport.
SetobjFSO=CreateObject("[Link]")
'Thiswilloverwritethefileifitalreadyexists.
SetobjFile=[Link](strFileName,True)
[Link]
SetobjFile=[Link](strFileName,ForAppending)
'Writetheheadingsforthiscsvfile
[Link]"DistinguishedName,"&_
"ChangeinWorkingSetMemory(bytes)"
SetobjRptFile=[Link](strRptFileName,ForReading)
'Skiptheheaderrowofthereport
[Link]
SetobjRootDSE=GetObject("LDAP://rootDSE")
strDomain=[Link]("defaultNamingContext")
SetobjRootDSE=Nothing
'Tarethelocalpropertycachew/adefaultADobject.
SetobjADObject=GetObject("LDAP://cn=BuiltIn,"&strDomain)
'CheckmemorybeforecallingGetInfo
intWSBefore=CheckMemory(0)
[Link]
'CheckmemoryaftercallingGetInfo
intWSAfter=CheckMemory(0)
SetobjADObject=Nothing
intCurObjSize=intWSAfterintWSBefore
'Calculatebaselineworkingsetmemory
intObjSizeBaseline=BaseLine()
[Link]"Reportrecordsprocessed:"
i=1
[Link]
'Extractalinefromthereport
strLine=[Link]
'Returneverythingexceptforthefirstquotationmark
strLine=Mid(strLine,2)
'Returneverythinguptothesecondquotationmark
strDN=Split(strLine,chr(34))
'Bindtotheobject
SetobjADObject=GetObject("LDAP://"&strDN(0))
'CheckmemorybeforecallingGetInfo
intWSBefore=CheckMemory(0)
[Link]
'CheckmemoryaftercallingGetInfo
intWSAfter=CheckMemory(0)
SetobjADObject=Nothing
intCalculatedSize=((intWSAfterintWSBeforeintObjSizeBaseline)/2)
IfintCalculatedSize>=intSizeThen
'Writedatatothenewreportfile
[Link](34)&strDN(0)&chr(34)&","&intCalculatedSize
EndIf
ForiCnt=1toLen(i)
[Link](8)
Next
[Link]
i=i+1
Wend

[Link] 110/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

[Link]&VbCrLf&"Thereportdatahasbeensavedto:"&_
strfileName&"."&VbCrLf&_
"ImportoropentheCSVdatainaspreadsheet"&VbCrLf&_
"ordatabaseprogramtoanalyzeobjectsizeestimates."
'**********************************************************************
'*Routine:CheckForCScript
'**********************************************************************
SubCheckForCScript
'Thisscriptmustrunfromcscriptbecause
'[Link].
'Testthescripthostandifit'snotcscript,
'instructtheoperatoronhowtorunthescript.
IfRight(LCase([Link]),11)<>LCase("[Link]")Then
[Link]"Thisscriptmustrunfromcscript."&_
VbCrLf&"Example:[Link]"
[Link]
EndIf
EndSub
'**********************************************************************
'*Function:ValidArgsTesting
'**********************************************************************
FunctionValidArgsTesting
[Link]<1Then
[Link]"Youmustspecifyacsvfilename"&VBCrLf&_
"[Link]."&VbCrLf&_
SampleCommandLine()
ValidArgsTesting=False
[Link]("f")[Link]=1Then
[Link]"[Link],objectsthatrequire"&_
VbCrLf&"50kbormoreofthelocalpropertycachewillbereported."
intSize=50*1024
ValidArgsTesting=True
[Link]("s")ANDIsNumeric(intSize)=FALSEThen
[Link]"Thesizevaluethatyouspecifiedisnotvalid."&_
VbCrLf&"Youmustspecifyanumber."&_
VbCrLf&SampleCommandLine()
ValidArgsTesting=False
[Link]>=1AND_
[Link]("f")=falseThen
[Link]"The/f:parameterisrequired."
[Link]&SampleCommandLine()
ValidArgsTesting=False
Else
[Link]"Objectsthatrequire"&intSize&"kbormore"&_
"thantheBuiltincontainerobjectinthelocalproperty"&_
VbCrLf&"cachewillbereported."&_
VbCrLf&"Note,thisscriptroundsthenumberspecifiedtothenearest"&_
VbCrLf&"[Link]"&_
VbCrLf&"convertedtopositivevalues."
ValidArgsTesting=True
EndIf
EndFunction
'**********************************************************************
'*Function:SampleCommandLine
'**********************************************************************
FunctionSampleCommandLine()
SampleCommandLine=_

[Link] 111/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

"Forexample,tocreateareportonallobjects"&_
VbCrLf&"thatconsume250kbofmemorytocomplete"&VbCrLf&_
"abindingoperation,basedoncomputerslistedin"&VbCrLf&_
"[Link],type:"&VbCrLf&_
"[Link]/f:[Link]/s:250"
EndFunction
'**********************************************************************
'*Function:BaseLine
'**********************************************************************
FunctionBaseLine
DimblnVal,intPreObjSize,intCount
intPreObjSize=0
intCount=0
blnVal=False
DoUntilblnVal=True
IfintPreObjSize=intCurObjSizeThen
intCount=intCount+1
IfintCount=10then
blnVal=True
'intObjSizeBaseline=intCurObjSize
Baseline=intCurObjSize
EndIf
Else
intCount=0
intPreObjSize=intCurObjSize
SetobjADObject=GetObject("LDAP://cn=BuiltIn,"&strDomain)
intWSBefore=CheckMemory(0)
[Link]
intWSAfter=CheckMemory(0)
SetobjADObject=Nothing
intCurObjSize=intWSAfterintWSBefore
EndIf
Loop
EndFunction
'**********************************************************************
'*Function:CheckMemory
'**********************************************************************
FunctionCheckMemory(index)
DimblnValue,intPreWorkingSet,intCurWorkingSet,intMemorySameCount
intMemorySameCount=0
intPreWorkingSet=0
intCurWorkingSet=_
(GetObject("winmgmts:Win32_PerfRawData_PerfProc_Process='cscript'").WorkingSet)
blnValue=False
DoUntilblnValue=True
IfintPreWorkingSet=intCurWorkingSetThen
intMemorySameCount=intMemorySameCount+1
IfintMemorySameCount=10then
blnValue=true
CheckMemory=intCurWorkingSet
EndIf
Else
intMemorySameCount=0
intPreWorkingSet=intCurWorkingSet
intCurWorkingSet=_
(GetObject("winmgmts:Win32_PerfRawData_PerfProc_Process='cscript'").WorkingSet)
EndIf

[Link] 112/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

Loop
EndFunction
'**********************************************************************
'*Function:PadZero
'**********************************************************************
FunctionPadZero(dtValue)
IfLen(dtValue)=1Then
PadZero=0&dtValue
Else
PadZero=dtValue
EndIf
EndFunction
'**********************************************************************
'*Function:GenFileName
'**********************************************************************
FunctionGenFileName(prefix)
'Createauniquetimestampednameforthetextfile
DimdtDate,strYear,strMonth,strDay,strDate
DimdtNow,strHour,strMinute,strSecond,strTime
dtDate=Date()
strYear=Mid(Year(dtDate),3)
strMonth=PadZero(Month(dtDate))
strDay=PadZero(Day(dtDate))
strDate=strYear&strMonth&strDay&""
dtNow=Now()
strHour=PadZero(Hour(dtNow))
strMinute=PadZero(Minute(dtNow))
strSecond=PadZero(Second(dtNow))
strTime=strHour&strMinute&strSecond
GenFileName=prefix&""&strDate&strTime&".csv"
EndFunction

3. Save the file as [Link]

Identifying Objects Created or Modified Within a Period of Time with [Link]

You can use the [Link] 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 [Link] 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 [Link] script has the following syntax:

[Link][/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. [Link] has no parameters.

[Link] 113/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

[Link] creates an output file, [Link], that contains a list of the objects created or modified during
the length of time.

To create the [Link] script.

1. Open Notepad.

2. Copy or type the following script into Notepad.

'**************************************************************************
'*File:[Link]*
'*Created:March2003*
'*Version:1.0*
'**
'*Description:Securitydiagnosticutilitythatcreatesareport*
'*containingallobjectscreatedormodifiedwithina*
'*[Link]*
'*reportofobjectcreationandmodificationactivity.*
'*Youcanthencompletetwocommontaskswiththe*
'*report.*
'*[Link]*
'*andestimatethesizeofthecreatedobjects.*
'*[Link]*
'*oradatabaseprogramtoanalyzetheresults.*
'**
'*Compatibility:ThisscriptrequiresWSH5.6,CScript,ADSI,WMI*
'*andaccesstoActiveDirectory*
'**************************************************************************
OptionExplicit
'Defineanyconstantsusedinthisscript
ConstForAppending=2
'Declareglobalvariables
DimobjArgs,intHours,dtFromDate,dtFromTime,dtVal,intLocalTime
DimobjRootDSE
DimstrFileName,objFSO,objFile
DimobjConnection,objCommand
DimarrNamingContexts,NamingContext,strContainer
'Thisscriptmustrunfromcscriptbecause
'[Link].
'Testthescripthostandifit'snotcscript,
'instructtheoperatorhowtorunthescript.
IfRight(LCase([Link]),11)<>LCase("[Link]")Then
[Link]"Thisscriptmustrunfromcscript."&_
VbCrLf&SampleCommandLine()&VbCrLf&_
VbCrLf&"Checkthelocalesettingofyoursystemforthecorrect"&_
"dateandtimeformat."
[Link]
EndIf
'UseNamedArgumentscollectionforthecommandlineargument.
'TheWSHArgumentsObjectisincludedinWSHversion5.6andlater
SetobjArgs=[Link]
intHours=cInt([Link]("h"))
dtFromDate=[Link]("d")
dtFromTime=[Link]("t")
[Link]("d")AND_
[Link]("t")Then
[Link] 114/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

dtVal=DateValue(dtFromDate)&""&TimeValue(dtFromTime)
IfIsDate(dtVal)=FalseThen
[Link]"Thedateortimevaluethatyouspecifiedisnotvalid."&_
VbCrLf&"Youmustspecifyavaliddateandtime."&_
VbCrLf&SampleCommandLine()
[Link]
EndIf
[Link]=2Then
[Link]"Acommandlineparameterismissing."&_
VbCrLf&SampleCommandLine()&VbCrLf_
VbCrLf&"Checkthelocalesettingofyoursystemforthecorrect"&_
"dateandtimeformat."
[Link]
[Link]=1AND_
[Link]("h")Then
[Link]"Nodateandtimeendpointwasprovided."&VbCrLf&_
"Therefore,thetimewindowendpointisbasedupon"&VbCrLf&_
"thecurrentsystemtime."
dtVal=Now()
EndIf
[Link]<1Then
[Link]"Youmustspecifyatimewindow(inhours)"&VBCrLf&_
"withinwhichobjectswerecreatedormodified."&VbCrLf&_
SampleCommandLine()
[Link]
Else
intLocalTime=LocalTime()
'CalltheGenFileNamefunctiontocreateauniquefilename
strFileName=GenFileName("ObjCMAudit")
'Createatextfile(.csvformat)toholdthe
'resultsofthereport.
SetobjFSO=CreateObject("[Link]")
'Thiswilloverwritethefileifitalreadyexists.
SetobjFile=[Link](strFileName,True)
[Link]
SetobjFile=[Link](strFileName,ForAppending)
'Writetheheadingsforthiscsvfile
[Link]"DistinguishedName,Class,Action,Date"
'CreatetheADSIOLEDBproviderobject
SetobjConnection=CreateObject("[Link]")
[Link]"Provider=ADsDSOObject;"
'CreatethecommandobjectandsettheActiveConnection
'propertyequaltothecommandobject
SetobjCommand=CreateObject("[Link]")
[Link]=objConnection
'SpecifyPagesizeforthiscommandobject.
'Thedomainandconfigurationcontainersarelikelytocontain
'largeresultsets
[Link]("PageSize")=256
[Link]("Asynchronous")=True
'Thiswillbeusedasaforwardonlyrecordset
'socachingisn'tnecessaryand,ifalargeresultset
'isreturned,cachingwillconsumetoomuchmemory.
[Link]("Cacheresults")=False
'UsetheRootDSEobjectforupcomingbindingoperations
SetobjRootDSE=GetObject("LDAP://rootDSE")
'GettheDNsforallnamingcontextsdefinedontheDC

[Link] 115/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

arrNamingContexts=[Link]("namingContexts")
'EnumeratethelistofNamingContextsandwriteamultiline
'reportfile.
ForEachNamingContextinarrNamingContexts
'SetthestrContainervariableequaltothebindingstringofthecontainer.
strContainer="<LDAP://"&NamingContext&">"
[Link]&"Reportingonobjectsinthe"&_
NamingContext&"container"&VBCrLf&_
"createdormodifiedbetween"&DateAdd("h",intHours,dtVal)&"and"&dtVal
CallCheckDates(strContainer,intHours)
Next
'Cleanup
SetobjRootDSE=Nothing
EndIf
[Link]&VbCrLf&"Thereportdatahasbeensavedto:"&_
strfileName&"."&VbCrLf&_
"ImportoropentheCSVdatainaspreadsheet"&VbCrLf&_
"ordatabaseprogramand/orrenamethefileanduse"&VbCrLf&_
"[Link]."&VbCrLf&_
"Forexample,rename"&strFileName&"[Link]"&VbCrLf&_
"objectsizeanalysisscriptbytyping:[Link]/f:[Link]"
'**********************************************************************
'*Routine:CheckDates
'**********************************************************************
SubCheckDates(Container,Hours)
DimobjRSContainer,dtWhenCreated,dtWhenChanged
DimdtAdjwhenCreated,dtAdjwhenChanged
DimdtWChgDiff,dtWCreDiff
DimstrDN,arrClass,iCnt,i
'Constructthequery.
'Note:UsingobjectClassasanattributetoreturnbecauseobjectCategory
'doesnotcontainavalueforallclasses.
[Link]=Container&_
";(&(objectCategory=*)(!objectCategory=foreignSecurityPrincipal));"&_
"distinguishedName,whenCreated,whenChanged,objectClass;subtree"
'Runthequery
SetobjRSContainer=[Link]
i=0
[Link]"Recordsprocessed:"
'Iteratetherecordset
[Link]
dtWhenCreated=[Link]("whenCreated")
dtWhenChanged=[Link]("whenChanged")
'TestfornullvaluesinwhenChangedandwhenCreated
'Forexample,whenCreatedandwhenChangedarenotmandatoryattributes
'andarenotsetforobjectsthatareinstantiatedfromthecrossRefContainer
'structuralclass
If(IsNull(dtWhenCreated)ORdtWhenCreated<CDate("01/01/1990"))OR_
(IsNull(dtWhenChanged)ORdtWhenChanged<CDate("01/01/1990"))Then
IfIsNull(dtWhenCreated)ANDIsNull(dtWhenChanged)Then
[Link](objRSContainer,"CreatedandChanged","notset")
ElseIfIsNull(dtWhenCreated)Then
[Link](objRSContainer,"Created","notset")
ElseIfIsNull(dtWhenChanged)Then
[Link](objRSContainer,"Changed","notset")
EndIf
Else

[Link] 116/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

'Convertthetimereturnedtolocaltimebyaddingorsubtracting
'fromGMT.
dtAdjwhenCreated=DateAdd("h",intLocalTime,dtWhenCreated)
dtAdjwhenChanged=DateAdd("h",intLocalTime,dtWhenChanged)
'Takethenumberofhoursanddatetimeendpointprovidedby
'theoperatorandreturnallobjectscreatedfromthathourforward
'Thedatevalue(dtVal)isthedateandtimeendpointofthetest.
dtWChgDiff=DateDiff("h",dtAdjwhenChanged,dtVal)
dtWCreDiff=DateDiff("h",dtAdjwhenCreated,dtVal)
'ThesgnfunctionisnecessaryinthenexttwoIfThenevaluations.
'Otherwise,theseevaulationswillreturnvaluesthataregreaterthan
'thedefineddate/timeendpoint.
If((Hours>=Cint(dtWChgDiff)ANDSgn(Cint(dtWChgDiff))<>1)AND_
(Hours>=Cint(dtWCreDiff)ANDSgn(Cint(dtWCreDiff))<>1))Then
[Link](objRSContainer,"[Created]\[Changed]",_
"["&dtAdjwhenCreated&"]\["&dtAdjwhenChanged&"]")
ElseIfHours>=Cint(dtWChgDiff)ANDSgn(Cint(dtWChgDiff))<>1Then
[Link](objRSContainer,"Changed","["&dtAdjwhenChanged&"]")
ElseIfHours>=Cint(dtWCreDiff)ANDSgn(Cint(dtWCreDiff))<>1Then
[Link](objRSContainer,"Created","["&dtAdjwhenCreated&"]")
EndIf
EndIf
ForiCnt=1toLen(i)
[Link](8)
Next
[Link]
i=i+1
[Link]
Wend
EndSub
'**********************************************************************
'*Function:LocalTime
'**********************************************************************
'Getlocaltimezoneoffset.RequiresWMIandtheWin32_TimeZoneclass
'whichispartofWindows2000andlater.
FunctionLocalTime()
DimobjWMIService,colTimeZones,objTimeZone
SetobjWMIService=GetObject("winmgmts:{impersonationLevel=Impersonate}!\\.\root\cimv2")
SetcolTimeZones=[Link]("Win32_TimeZone")
ForEachobjTimeZoneIncolTimeZones
LocalTime=Fix([Link]/60)
Next
EndFunction
'**********************************************************************
'*Function:SampleCommandLine
'**********************************************************************
FunctionSampleCommandLine()
SampleCommandLine=VbCrLf&_
"Example:Totesta4hourtimewindowon03072003"&VbCrLf&_
"from9:30AMand50secondsto1:30PMand50seconds,type:"&VbCrLf&_
"[Link]/h:4"&_
"/d:03072003/t:1:30:50PM"&VbCrLf&VbCrLf&_
"Youcanalsoenteratimevalueusinga24hourclock."&VbCrLf&_
"Example:Totesta2hourtimewindowon03072003"&VbCrLf&_
"from14:00(2:00pm)to16:00(4:00pm),type:"&VbCrLf&_
"[Link]/h:2"&_
"/d:03072003/t:16:00"

[Link] 117/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

EndFunction
'**********************************************************************
'*Function:PadZero
'**********************************************************************
FunctionPadZero(dtValue)
IfLen(dtValue)=1Then
PadZero=0&dtValue
Else
PadZero=dtValue
EndIf
EndFunction
'**********************************************************************
'*Function:GenFileName
'**********************************************************************
FunctionGenFileName(prefix)
'Createauniquetimestampednameforthetextfile
DimdtDate,strYear,strMonth,strDay,strDate
DimdtNow,strHour,strMinute,strSecond,strTime
dtDate=Date()
strYear=Mid(Year(dtDate),3)
strMonth=PadZero(Month(dtDate))
strDay=PadZero(Day(dtDate))
strDate=strYear&strMonth&strDay&""
dtNow=Now()
strHour=PadZero(Hour(dtNow))
strMinute=PadZero(Minute(dtNow))
strSecond=PadZero(Second(dtNow))
strTime=strHour&strMinute&strSecond
GenFileName=prefix&""&strDate&strTime&".csv"
EndFunction
'**********************************************************************
'*Function:ReadAndWrite
'**********************************************************************
FunctionReadAndWrite(RecordSet,Status,AttribValue)
DimstrDN,arrClass,strClassName
strDN=[Link]("distinguishedName")
arrClass=[Link]("objectClass")
strClassName=arrClass(UBound(arrClass))
ReadAndWrite=Chr(34)&strDN&Chr(34)&","&strClassName&","&_
Status&","&AttribValue
EndFunction

3. Save the file as [Link]

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.

[Link] is located in the Support tools folder o n the Windows 2000 installation CDROM.

Requirements

Credentials: Domain Admins

Tools: [Link]

[Link] 118/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 [Link]

You can use the [Link] script to monitor the number of objects in a domain. Before you can use the
[Link] script, you must create the script based on the source code included in this
document.[Link]

Note: This script requires Windows 2000 with Service Pack 3 or later and Windows Scripting Host version 5.6 or later.

The [Link] script has the following syntax:

[Link]

[Link] has no parameters.

[Link] creates an output file, ObjCountByClass [Link], which contains the number of objects by object
class where date is the date you ran [Link] and time is the time you ran [Link].

To create the [Link] script

1. Start Notepad

2. Copy or type the following script into Notepad

**************************************************************************
'*File:[Link]*
'*Created:April2003*
'*Version:1.0*
'**
'*Description:Diagnosticutilitythatcountsthenumberofobjects*
'*byobjectClass,createdinallcontainers*
'*definedinthenamingContextsattributeofRootDSE.*
'*Usethistooltobuildanobjectcreationtrend*
'*[Link]*
'*CSVreportfilewithabeginningprefixof*
'*[Link]*

[Link] 119/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

'*aspreadsheetprogramoradatabaseprogramfor*
'*trendanalysis.*
'**
'*Compatibility:ThisscriptrequiresWSH5.6,CScript,ADSI,*
'*andaccesstoActiveDirectory*
'**************************************************************************
OptionExplicit
'Defineanyconstantsusedinthisscript
ConstForAppending=2
'Declareglobalvariables
DimdtDate,dtTime,strDate,strTime
DimobjRootDSE,strSchema,strDomain,strConfig
DimobjConnection,objCommand,objRSSchema
DimobjFSO,objFile,strCount,strFileName
DimarrNamingContexts,NamingContext,strContainer
CallCheckForCScript
'[Link]
'theGenFileNamefunctionandappearinthefirst
'andsecondcolumnofthereport.
dtDate=Date()
dtTime=Time()
'Formatteddateandtimevaluesforreportcolumns1and2
strDate=DateFormat(dtDate)
strTime=TimeFormat(dtTime)
'UsetheRootDSEobjectforupcomingbindingoperations
SetobjRootDSE=GetObject("LDAP://rootDSE")
'GettheDNsforallnamingcontextsdefinedontheDC
arrNamingContexts=[Link]("namingContexts")
'BindtothecurrentschematoobtainalistofallClassSchemaobjects
strSchema="<LDAP://"&_
[Link]("schemaNamingContext")&">"
'CreatetheADSIOLEDBproviderobject
SetobjConnection=CreateObject("[Link]")
[Link]"Provider=ADsDSOObject;"
'CreatethecommandobjectandsettheActiveConnection
'propertyequaltothecommandobject
SetobjCommand=CreateObject("[Link]")
[Link]=objConnection
'Createtheschemaquery
[Link]=strSchema&_
";(objectClass=classSchema);"&_
"lDAPDisplayName,distinguishedName;subtree"
'Specifypagesizeforthiscommandobject.
'Thisisnecessarytoavoidoverutilizationofserver
'[Link],bydefault,
'only1000recordswillbereturnedifpagingisn't
'[Link]
'than1000classSchemaobjects.
[Link]("PageSize")=256
[Link]("Asynchronous")=True
'Cachingisrequiredbecausetheschemarecordset
'iteratedmultipletimes.
[Link]("Cacheresults")=True
'Runtheschemaquery
SetobjRSSchema=[Link]
'Createauniquefilename(timestamp)usingtheGenFileNamefunction
strFileName=GenFileName("ObjCountByClass")

[Link] 120/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

'Createatextfile(.csvformat)toholdthe
'resultsoftheclasstest.
SetobjFSO=CreateObject("[Link]")
'Thiswilloverwritethefileifitalreadyexists.
SetobjFile=[Link](strFileName,True)
[Link]
SetobjFile=[Link](strFileName,ForAppending)
'Writethecolumnheadingstothereportfile
[Link]"dtDate,dtTime,strContainer,strObjectClass,intTotal"
'EnumeratethelistofNamingContextsandwriteamultiline
'reportfile.
ForEachNamingContextinarrNamingContexts
'SetthestrContainervariableequaltothebindingstringofthecontainer.
strContainer="<LDAP://"&NamingContext&">"
'Writethecolumnheadings
CallCountObjects(NamingContext,strContainer)
Next
'Cleanup
SetobjConnection=Nothing
'Closethefile
[Link]
[Link]&"Thereportdatahasbeensavedto:"&strfileName&"."
[Link]"ImportoropentheCSVdatainaspreadsheetordatabaseprogram."
'**********************************************************************
'*Routine:CheckForCScript
'**********************************************************************
SubCheckForCScript
'Thisscriptmustrunfromcscriptbecause
'[Link].
'Testthescripthostandifit'snotcscript,
'instructtheoperatoronhowtorunthescript.
IfRight(LCase([Link]),11)<>LCase("[Link]")Then
[Link]"Thisscriptmustrunfromcscript."&_
VbCrLf&"Example:[Link]"
[Link]
EndIf
EndSub
'**********************************************************************
'*Routine:CountObjects
'**********************************************************************
SubCountObjects(NamingContext,Container)
Dimi,strClassName,strDN,objRSContainer,intRecordCount,iCnt,iPercent
DimobjField,colObjClass,strClassValue
i=0
'UseaWhileWendlooptotestforeachtypeofclassobject
[Link]
[Link]
'Settheclassanddnvariablesequaltothetwoattributes
'containedintheFieldscollection.
strClassName=[Link]("lDAPDisplayName")
strDN=[Link]("distinguishedName")
'objectClassmustbereturnedintheresultsetsothatthelastentry
'ofthemultivaluedattributecanbereturnedastheobjectclass
'inthereport.
[Link]=Container&_
";(objectCategory="&strDN&");"&_
"objectClass;subtree"

[Link] 121/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

'Cachingisn'tnecessarybecausethisrecordsetisreadonlyonce.
[Link]("Cacheresults")=False
SetobjRSContainer=[Link]
Ifi=0Then
[Link]"Countingobjectsin:"&""&NamingContext
EndIf
'[Link]
'allthat'srequiredintheobjectClassmultivaluedattribute
[Link]
[Link]
colObjClass=[Link]
ForEachstrClassValueincolObjClass
'ThelastentryforstrClassValuebecomesthevalue
'ofstrClassName
strClassName=strClassValue
Next
Next
intRecordCount=[Link]
IfintRecordCount>0Then
[Link]&","&strTime&","&_
Chr(34)&NamingContext&Chr(34)&","&strClassName&","&intRecordCount
EndIf
[Link]
Wend
'Progressindicator
ForiCnt=1toLen(iPercent)+22
[Link](8)
Next
iPercent=(Round(i/[Link],2)*100)+1
[Link]"Percentagecomplete:"&iPercent&"%"
i=i+1
[Link]
Wend
'Cleanup
SetobjRSContainer=Nothing
[Link]
EndSub
'**********************************************************************
'*Function:PadZero
'**********************************************************************
FunctionPadZero(dtValue)
IfLen(dtValue)=1Then
PadZero=0&dtValue
Else
PadZero=dtValue
EndIf
EndFunction
'**********************************************************************
'*Function:GenFileName
'*NOTE,ThisisslightlymodifiedfromtheotherGenFileNamefunctions
'*theinitialdateandtimevaluesarecalculatedoutsideofthe
'*functionbecausethevaluesareusedinthefirstandsecondcolumns
'*ofthereport.
'**********************************************************************
FunctionGenFileName(prefix)
'Createauniquetimestampednameforthetextfile
DimstrYear,strMonth,strDay,strDate

[Link] 122/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

DimstrHour,strMinute,strSecond,strTime
strYear=Mid(Year(dtDate),3)
strMonth=PadZero(Month(dtDate))
strDay=PadZero(Day(dtDate))
strDate=strYear&strMonth&strDay&""
strHour=PadZero(Hour(dtTime))
strMinute=PadZero(Minute(dtTime))
strSecond=PadZero(Second(dtTime))
strTime=strHour&strMinute&strSecond
GenFileName=prefix&""&strDate&strTime&".csv"
EndFunction
'**********************************************************************
'*Function:DateFormat
'**********************************************************************
FunctionDateFormat(DateVal)
DimstrYear,strMonth,strDay
'Getthedateforcolumn1ofeachrow.
strYear=Year(DateVal)
strMonth=PadZero(Month(DateVal))
strDay=PadZero(Day(DateVal))
DateFormat=strYear&"/"&strMonth&"/"&strDay
EndFunction
'**********************************************************************
'*Function:TimeFormat
'**********************************************************************
FunctionTimeFormat(TimeVal)
DimstrHour,strMinute,strSecond
'Getthetimeforcolumn2ofeachrow.
strHour=PadZero(Hour(TimeVal))
strMinute=PadZero(Minute(TimeVal))
strSecond=PadZero(Second(TimeVal))
TimeFormat=strHour&":"&strMinute&":"&strSecond
EndFunction

3. Save the file as [Link]

Removing an Active Directory Domain Controller

Use the [Link] Support tool to perform this procedure. [Link] is located in the Support tools folder o n the Windows
2000 installation CDROM.

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.

[Link] 123/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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 forestwide 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. Rightclick 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 [Link] and [Link]. 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.

[Link] 124/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

varSigner=newActiveXObject("[Link]");
varFile="c:\\[Link]";
varCert="[Link]";
varStore="my";
[Link](File,Cert,Store);

The following sample, in this case as VBScript code, verifies the signing on a file:

DimSigner,File,ShowUI,FileOK
SetSigner=CreateObject("[Link]")
File="c:\[Link]"
ShowUI=True
FileOK=[Link](File,ShowUI)
IfFileOKThen
[Link]&"istrusted."
Else
[Link]&"isNOTtrusted."
EndIf

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.

[Link] is located in the Support tools folder o n the Windows 2000 installation CDROM.

Requirements

Credentials: Domain Admins

Tools: [Link]

[Link] 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

[Link] 125/126
1/26/2017 BestPracticeGuideforSecuringActiveDirectoryInstallationsandDaytoDayOperations:PartII

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

Top of page
2017 Microsoft

[Link] 126/126