Ch1 PDF

Five Key Lessons to
Securing
YourActive
Directory
Chapters
Roberta Bragg
MCSE, CISSP, Author, Columnist,
Speaker, Consultant
1. Perform a Self-Audit
2. Know and Use Security Tools and Techniques
3. Monitor Active Directory Operations
4. Leverage People and Processes
5. Active Directory Security Maintenance
Sponsored by:
CONTENTS
INTRODUCTION .................................................................................................5
WHO SHOULD READ THIS BOOK ..................................................................6
CHAPTER 1: PERFORM A SELF-AUDIT...........................................................7
FIRST, LOOK IN THE MIRROR ..........................................................................8
YOU CAN CHANGE THINGS, SHOULD YOU? .............................................10
PERFORM THE AUDIT......................................................................................12
STEP 1: DOCUMENT YOUR INFRASTRUCTURE ................................................................. 12
STEP 2: CHECK PHYSICAL SECURITY FOR DOMAIN CONTROLLERS ............................... 13
STEP 3: CHECK ACTIVE DIRECTORY HEALTH .................................................................. 15
Check Connectivity ............................................................................................................. 15
Evaluate DNS Operation.................................................................................................. 16
Evaluate DNS Security ...................................................................................................... 16
Evaluate Time Services Operation ................................................................................. 17
Evaluate AD Replication ................................................................................................... 18
Evaluate FRS Replication .................................................................................................. 18
STEP 4: EVALUATE AD INFRASTRUCTURE DESIGN .......................................................... 19
Examine Security Boundaries .......................................................................................... 19
STEP 5: EXAMINE NETWORK INFRASTRUCTURE DESIGN AND DEFENSE............................ 21
Review Network Design.................................................................................................... 21
Review Intrusion Detection and Response................................................................... 22
STEP 6: EXAMINE ADMINISTRATIVE ROLES AND STRUCTURES ........................................ 22
Review Default Administrative Groups ......................................................................... 22
Evaluate Delegated Permissions on AD Objects ........................................................ 24
Evaluate Group Policy Administration ........................................................................... 26
Secure Administrative Workstations.............................................................................. 26
Secure Administrative Access .......................................................................................... 27
Evaluate the Security of Administrative Communications between
Workstations and DCs...................................................................................................... 28
Evaluate Administrative Practices................................................................................... 28
Evaluate Management of Administrative Tools.......................................................... 30
STEP 7: EXAMINE GROUP POLICY DETAILS ...................................................................... 30
Check GPO Files and AD Records.................................................................................. 32
Evaluate Policy Application............................................................................................... 33
STEP 8: REVIEW TECHNICAL CONTROLS .......................................................................... 33
Evaluate the Domain Security Policy ............................................................................. 33
Evaluate the DC Security Policy ...................................................................................... 35
Review Audit Policy............................................................................................................. 35
Review User Rights on DCs ............................................................................................. 36
Evaluate Security Options................................................................................................. 37
Evaluate Services ................................................................................................................ 38
Evaluate Event Log Settings............................................................................................. 39
Evaluate EFS ........................................................................................................................ 39
STEP 9: EVALUATE FILE AND REGISTRY PERMISSIONS ON DCS ....................................... 40
STEP 10: REVIEW PROTECTION FOR AD COMMUNICATIONS ........................................ 41
STEP 11: REVIEW MAINTENANCE PROCEDURES............................................................... 42
Review Logging Configuration and Management ...................................................... 42
Review Change Management Procedures ................................................................... 43
Review Security Patch Processing ................................................................................... 44
Securing Your Active Directory. Chapter 1 - Perform a Self-Audit
STEP 12: REVIEW NON-TECHNICAL CONTROLS .............................................................45

Review Security Policy ........................................................................................................45
Evaluate User Security Awareness .................................................................................46
Evaluate Policy and Procedure for DC Administration..............................................46
Review Business Continuity/Disaster Recovery Plans.................................................47
SUMMARY........................................................................................................... 48
SELF-AUDIT CHECKLIST ................................................................................ 49
ABOUT QUEST WINDOWS MANAGEMENT ............................................. 51
ABOUT QUEST SOFTWARE, INC. ................................................................ 51
INTRODUCTION
Active Directory (AD) is the backbone of a Windows Server 2003 or
Windows 2000 Server domain infrastructure, providing a channel for
security implementation and maintenance in the forest. Secure AD
and you have advanced the protection of all forest elements.
Ignoring AD security can put your entire infrastructure at risk.
Securing AD, however, is not a trivial task. Many Windows security
subsystems are integrated with it, and many of them can be used to
secure it. The account database, Kerberos authentication protocol,
password policy, definition of user rights and system controls,
assignment of object permissionsall are contained in or managed
with AD. You must also consider the distribution of its elements and
the nature of the people who interact with it. AD is not some entity
that can be localized on a single machine but spans multiple
computers and networks. It presents a broad attack surface and many
threats must be evaluated. There are literally hundreds of steps that
should be at least considered when designing, implementing, and
maintaining AD security. This e-book can help you with that task.
It consists of five lessons:
Chapter 1: Perform a Self-auditA checklist to assist in
determining current Active Directory security status.
Chapter 2: Know and Use Security Tools and TechniquesHow
tos with an emphasis on securing Active Directory.
Chapter 3: Monitor Active Directory OperationsHow to monitor
and improve Active Directory health.
Chapter 4: Leverage People and ProcessesTraining, awareness,
security policy, accountability, physical security, and business
continuity.
Chapter 5: Active Directory Security MaintenanceAuditing and
monitoring, policy and process reviews.
WHO SHOULD READ THIS BOOK

The book should be used both as a checklist and tutorial. Lesson one,
the checklist, is perhaps the hardest lesson. It is especially difficult
since the other chapters will not be immediately available to you.
Despite being the most difficult, it also provides an overview of the
extensive work that must be done and the breadth and depth of
knowledge needed to secure AD.
To immediately benefit from this lesson, you should be an
experienced AD administrator or experienced IT auditor with training
in AD. If your Windows administration experience does not include
responsibility for AD or if your IT auditor background does not
include work in this area, you will either need to obtain help elsewhere
or use the information in the other lessons to provide training. A year
of experience in AD administration should be sufficient.
Note that it is years of experience specifically with AD thats
important here. Desktop and server administration experience, while
important, will not provide the background needed to understand
and answer the questions posed. If you are a security manager,
programmer or student, this e-book can help you understand why
and how AD must be secured. Use this chapter as a checklist of what
else you need to know; use it as a discussion point with your peers
and experienced AD administrators. Regardless of your level of
experience, you will find information in upcoming lessons to aid you
in securing AD.
Because this is an e-book, future content is fluid. The first chapter is
available now, but future lessons are still in the writing and
production stage. If you have AD in your environment, you may have
questions about securing it, comments about official hardening
guides or a unique perspective on AD security. Heres your
opportunity to shape future lessons by letting me know how I can
help them meet your needs, and by sharing stories and opinions
from your experiences. Write me at roberta.bragg@mcpmag.com.
CHAPTER 1: PERFORM A SELF-AUDIT

Like many complex undertakings, the process of securing AD must
be approached as a series of repetitive taskssteps that can be taken
to continually improve the basic security posture and respond to
changes in threats, knowledge, infrastructure and requirements. The
first step in implementing AD security is an assessment of where you
are today. This lesson provides the steps for that critique. Be aware
that many of the steps and many questions needing answers require
a background in AD, along with experience administering a Windows
environment. I may also suggest the use of tools you are unfamiliar
with or practices that you have no experience with. This information
will be included in future lessons and references.
It is also true that many items in this audit should be part of regular
maintenance strategies or taken into consideration when designing
an AD infrastructure. This document can help plan maintenance or
review a proposed AD design. Keep in mind, though, that its purpose
is to provide a checklist; it is not a primer on AD design,
troubleshooting or maintenance. To use the checklist to make a
complete assessment you may need to do more background work or
obtain the advice and assistance of knowledgeable AD folks.
If you are an IT auditor, you might use this checklist to prepare work
papers and require others to provide answers to the technical
questions posed. It is not meant, however, to be the only resource for
properly auditing AD.
FIRST, LOOK IN THE MIRROR

When I was first writing about auditing Windows systems, the word
audit meant, for many IT pros, a tax audit, or that rare and
mysterious IT audit as performed by people inOh, the horror of it
suits. Now the word audit has come to mean any inspection of IT
security by anyone. Penetration tests performed by IT admins or
security consultants are now called audits. Walkthroughs of system
configurations and the use of the Security Configuration and Analysis
Tool to analyze security settings against a baseline template is called
an audit. Auditing, some say, means turning on some switches in the
Local Security Policy of the domain controller and collecting massive
log files. I have even been told that we are not able to perform an IT
audit because we are not CPAs and, therefore, not auditors.
So what is an AD self-audit? Its not intrusive or disruptive like an
actual attack, and its not formal and independent like one done by
IT auditors on your internal audit staff or financial auditors. An AD
self-audit is an in-depth review done by the people who maintain or
secure Active Directory. Its purposes are many:
Ensure that activities and procedures conform to norms and

criteria. (I.e., are you doing what information security experts
believe is acceptable practice?)
Apply a systematic, disciplined approach to evaluate current

security measures. (Make sure everything is checked, and
checked in a way to give the desired results.)
Assess the adequacy of system controls. (Do the controls work?

Its one thing to have a password policy; its another to have one
that actually enforces practices that result in passwords that are
difficult if not impossible to crack, provides defense-in-depth,
and uses a system that ensures even crackable passwords have
little value due to their limited life.)
Ensure compliance with established security policies and

procedures. (Are rules being followed?)
Recommend necessary changes in controls, policies, and

procedures to meet security objectives. (A successful review
finds something that can be corrected or done better.)
A self-audit is not a substitute for an independent audit by

individuals with solid IT auditing credentials and solid AD technical
credentials. It cannot pass as an audit of system controls as required
by law for some organizations or as an audit that will fulfill some
internal requirement. However, it will help you to determine the
current status of your organizations AD security and decide on the
steps needed to make it more secure. If you have not yet deployed
AD, these self-audit steps can aid your planning people in how to
include proper AD security processes from the beginning. Using this
guide during development and doing a self-audit before going live
will kick off your AD operation on much better security footing.
Note
A self-audit is not a troubleshooting exercise. But it may turn up problems,

making it impossible to complete the audit. It is also impractical to perform
all the steps covered on all domain controllers (DCs). Formal IT audits
typically select relevant examples to audit, and you should, too. For
example, it may be impractical to check connectivity for all DCs, but you
can test representative DCs in different sites and domains, including DCs
across the firewall from the current location and DCs in trust relationships.
Several of the steps require more knowledge of DNS, Windows and
AD than can be included here. Some of these things will be detailed
in future lessons. Some will require previous knowledge, while others
may necessitate hitting the books.
YOU CAN CHANGE THINGS, SHOULD YOU?

In a formal audit, an independent individual or team of individuals,
possibly from outside your company, conduct the audit. Throughout
the audit, they remain outsiders. They do not make changes to your
systems or even directly access data. There are several necessary
reasons for this detachment.
It is felt that only an independent, removed review can provide

the required objectivity. After all, an insider might seek to hide
or distort the information, intentionally or not.
Part of the review looks for any evidence of fraud. If insiders are
used, they may be the perpetrators or blinded by their
relationships with the people whose systems they are auditing,
and therefore gloss over any evidence of a crime.
Outsiders do not have administrative-level privileges on

information systems and cannot change the environment they
are auditing. There should be no chance that an auditor might
be responsible for system configuration or data changes. The
auditors ask questions and diligently research their information
from reports and documents provided by the IT staff upon
request. The auditor reports variances to and situations that do
not meet, the current security policy, and recommends changes,
but makes none personally.
When conducting a self-audit, you are not an outsider looking in.
You may have the access required to change things, and you are not
looking to uncover fraud. Instead you want to check that everything
is working, configured and deployed as specified in the
organizations security policy, and that you havent missed any
opportunities to improve security.
Before starting a self-audit, determine what the response will be to
items that need fixing or changing. On the one hand it may seem
foolish to not change something needing attention; on the other, the
audit might never be completed if you stop to fix every problem or
address every area of non-compliance.
I suggest performing the audit and delegating changes and
recommendations. For example, if you discover a problem with DNS,
note it and turn it over to the people in charge of DNS. If, while
checking the health of Group Policy, you discover a policy that is not
being applied, turn it over to the person in charge of that GPO.
10
However, if you are the one responsible in these areas you must
determine if the problem requires immediate attention. If the DNS
issue you discover is preventing all Group Policy processing, then
stop auditing and start fixing. If a specific GPO is not being applied
and that GPO is the domain GPO, stop auditing and find the
problem. If your settings are out of compliance and you know that
compliance causes no operational problems, you may want to
correct them.
If the issues are less importantfor example, you dont know what a
malfunctioning GPO does, Id continue the audit and make a list of
things to do. If your network and AD operations are well-run to begin
with, youre probably not going to turn up horrendous operational
problems during the audit. The audit is not meant to discover or
troubleshoot operational issues, but instead to identify whether
security is being done as it should and where it might be improved.
11
PERFORM THE AUDIT

To perform the audit, complete the following steps. Answer the
questions as best you can. You may find it more convenient to
change the order of the steps.
Begin by making sure you have a copy of your organizations security
policy, and spend time up front documenting your AD infrastructure.
Many questions may require this knowledge, and many may be based
on standard best practices. You may want to add your security policy
requirements for analysis or for comparison with this information. It
is possible that your organizations policy and implementation
provide better AD security in your environment, or that items
considered best practices here cannot be implemented in your
environment. Remember, an audit should end with recommendations
for change, but change should be evaluated and approved.
Step 1: Document Your Infrastructure

In order to evaluate AD security, you have to know where DCs and
clients are. This information will help you understand where you need
to check connectivity and other infrastructure tasks. It will also help
you complete your list of steps, in this section as well as others. After
all, if you do not need to replicate AD over firewalls, it is not necessary
to review the firewall configuration. Likewise, if there are trust
relationships between domains in your forest and domains in another,
you may want to schedule a meeting with the administrators of the
other forest to determine their security postures and the impact on
your ability to secure AD in your environment.
You will not be able to check every aspect of every DC, site, or client.
Traditionally, an auditor looks at representative examples and does
not test every unique component. Although you may want to know
everything about your network, it is better to go down the checklist
on some systems than give up due to deadlines and be halfway down
the list.
12
The documentation required for a self-audit should be part of your

network documentation, and easy to obtain. If it is not, consider
making that a point of change. This basic information about your AD
infrastructure is critical; not just for a self-audit, but for maintaining
your AD environment. You should have, at a minimum, the following
information:
The number and location of sites. Indicate number of users and

IT staff at each site
The number and names of all domains

The location of all DCs by domain
The Organizational Unit (OU) structure for each domain
External trusts with domains in other forests
Forest trusts
Trust relationships with NT 4.0 domains
Trust relationships with Kerberos realms
Step 2:
Check Physical Security for Domain Controllers
Questions to answer relative to your environment:
Are DCs at headquarters and divisions kept in a secured data center?

Data centers provide protection from physical harm and limit
access to systems. DCs can be further controlled by providing
locked racks.
Are DCs kept on protected network segments?

DCs should be isolated from open areas of networks, yet quickly
accessible to clients.
Are cable closets protected?

Connection points to the Internet or other networks should be
kept behind locked doors, as should routers, switches, and other
devices that define your network infrastructure. Keep cable
closets locked, and do not allow network devices to share space
in telephone cable rooms. The organizations network should
not be accessible to telephone company employees.
13
Are DCs at remote locations physically secured?

Branch offices and other small locations do not need a data
center, but any DCs placed there need to be physically secured.
Steps that should be taken:
They should be in a locked room or cabinet in an area free

from dangers such as heat, fire, water and chemicals
Smartcard, token and/or biometric authentication for logon

should be required
Remove floppy, CD-ROM or other removable drives
Disable USB and serial ports
Put hardware locks on cables and drives
Place additional locks on the computer system unit
Install alarms that warn of computer movement
Are DCs protected from power failures?

UPSs can prevent failures due to power fluctuations. Physically
secure them.
Is access to DCs restricted?

A limited number of people should have access to the DC. Only
those authorized to maintain hardware and those administrators
approved as domain administrators should be allowed physical
access to DCs. If your policy is to remotely administer servers, then
the list of those approved for physical access should be smaller.
Does a specific process for physical access and console access exist?
Standard procedures can prevent attacks because everyone is
alert to abnormal behavior. Standard procedures should also
specify who, and exactly how, DCs are managed, ensuring the
greatest security.
14
Step 3: Check Active Directory Health

AD is more than a static set of security configurations; it is in
constant flux. Information changed at one DC replicates to all others;
security settings are transferred to intended clients. Given the
changing nature of this information, AD health can be quickly
affected by many factors. For example, misconfiguring DNS can
result in clients not being able to find DCs and replication partners
unable to find each other. Weakening permissions on AD objects or
providing untrustworthy people administrative rights makes AD
vulnerable to misconfiguration, accidental destruction and attack. If
AD is sick, your network-wide security subsystem is sick. Start your
self-audit by determining ADs health.
A good place to start your examination is with network functionality,
including connectivity, communications and especially DNS. Many
AD or Group Policy problems are rooted in DNS errors. Next, look at
DC replication and file replication along with Group Policy
operation. There are many tools and many processes that need to be
done to fulfill these tasks. If you know how these tools work and how
to check common configuration settings, proceed with the audit. If
you are an IT auditor, you should ask authorized administrators to
provide the answers to these questions. Information on how to check
configuration settings and use the tools described will be provided in
Chapters 2 and 3.
Check Connectivity
DCs must connect to replication partners to update account
information and changes to security settings. Clients, including
computers used to administer DCs, must also have connectivity to
apply security changes. If security changes cant replicate, security
cant be enforced. Netdiag can test DC/DNS connectivity, and
DNSLint can test connectivity between replication partners.
Does connectivity exist between clients and DCs?

Use netdiag to test client-to-DC/DNS connectivity.
Does connectivity exist between replication partners?

Use DNSLint to determine if SRV records for replication are
present. If SRV records are absent, DCs may not be able to find
their replication partners. Dont forget to check connectivity
between replication partners across firewalls.
15
Is connectivity available for domains in trust relationships?

Use nltest to test trust relationships.
Are directory service and file replication event logs scanned for
errors?
Windows event logs should be periodically scanned for connectivity
errors.
Evaluate DNS Operation

DNS is used by clients to find DCs and by DCs to find replication
partners. Problems with DC operations can spell big problems with
security and often indicate DNS problems. Conversely, problems
discovered with DNS may eventually cause problems with DCs, AD
replication, and client connectivity.
Are DNS configuration and response issues periodically checked?

DNSLint can be used to detect problems with DNS. DNSLint is
described in a Microsoft Knowledge Base (KB) article,
http://support.microsoft.com/default.aspx?scid=kb;en-us;321045,
which also provides a download link. DNSLint will expose DNS
configuration issues and whether or not DNS servers are
responding. If DNS issues are present, they may affect both ADs
operation and network security. Use Portqry to detect DNS
availability. NSLookup can be used to test DNS functioning. (Note
that NSLookup works by doing a zone transfer. You should be
restricting zone transfers, so this will only work if done from a DNS
server with zone transfer rights to the DNS server you are testing.)
Evaluate DNS Security

Given ADs dependence on DNS, its easy to see why you should be
concerned with DNS security.
Are zone transfers restricted to approved secondary DNS servers?

Check zone transfers through manual inspection of DNS
configuration. Use NSLookup to test it. (Many of NSLookups
features will not work without zone transfer. If used from a
machine not approved for zone transfers, NSLookup should fail.)
Is the DNS cache secured against cache pollution?

By default, the DNS server is secured against cache pollution, which
happens when incorrect addresses are added to the DNS server
cache. The server may then redirect clients to the wrong computers.
16
Is DNS integrated with AD?

Integrating DNS with AD secures changes to IP addresses. DNS
information is replicated with AD and encrypted by default.
Mutual authentication of DCs is always used, securing transfers
of zone information.
Are secure dynamic updates configured?

Secure dynamic updates, available with AD-integrated DNS, can
protect DNS from rogue computers attempting to change IP
address information in the DNS zone.
Are external and internal DNS services separated?

Internal DNS information should not be available to the outside
world. A separate DNS implementation can provide records for
Internet-facing systems such as Web and messaging servers.
Are requests for zone delegation carefully reviewed?

A zone delegation should never be approved until you can ensure
the DNS server will be properly hardened and maintained.
Are backups of zone information kept?

Backups of zone information can restore DNS in the event of
data loss.
Evaluate Time Services Operation

All systems should keep the same time. There are two major reasons
for this. First, if time is out of synchthat is, if the time on an AD
client differs from the Key Distribution Center (KDC) by more than the
time recorded in the Kerberos security policyany client request for
authentication will be rejected, even if the credentials are okay.
Second, the time stamp in the logs needs to be correct. It is important
to have a correct time on logs to assist in troubleshooting and forensic
research. Should you need to present evidence of an intrusion, you
must be able to provide proof of accurate time stamps.
Is the root domain of the forest PDC Emulator configured to

synchronize time with an external time server?
The PDC Emulator is used as the source for time synch within
the domain. If it is not properly configured, time will not be
accurate throughout the domain.
Is time synchronization periodically checked?

If a client time is off by a large amount, automatic time synchronization
cannot work. This may be a problem when new systems are
added to the domain or when computer batteries are failing.
17
Evaluate AD Replication
If AD replication is not working correctly, Group Policy information
will not be transferred between DCs.
Are replication links working?

Use Replmon to examine replication and set up notification.
This tool can help you determine if replication links are working
and report on replication latency. The report will tell you if
attempts to connect have been successful and provide statistics
on any errors that have occurred. Replication latency is the time
it takes to replicate changes. This is important because changes
made to GPOs are not immediately available, since the
information must be replicated.
Evaluate FRS Replication

Group Policy data is stored partially in AD and partially in the
SYSVOL folder. The file replication service (FRS) replicates the
template files critical for the success of GPOs.
Is FRS replication occurring normally?

GPOtool can be used to test replication, as can sonar.exe and
ultrasound.exe. Look for backlogs and other error conditions.
Is there adequate space for FRS replication?

Check the space available to the SYSVOL share.
Are FRS event logs reviewed?

FRS logs record replication failures and may provide a reason
such as DNS lookup failures.
18
Step 4: Evaluate AD Infrastructure Design

The details of your AD infrastructure can point to areas where
additional security measures should be applied.
Examine Security Boundaries

Is isolation or autonomy required?
Autonomy is the ability to delegate administration of some part
of your user and computer populations without giving up the
ability to take over management should it become necessary.
Autonomy does not guarantee isolation, nor prevent the
possibility that a rogue administrator might compromise a
domain for which he has no authority. An Active Directory
domain can provide autonomy. Within the forest, you can assign
different administrators the ability to administer different
domains. As long as they play by the rules, their authority within
their domains is sacrosanct.
However, domain administrators are not the only ones who can
administer their domains. A special class of forest-wide
administratorsthose with membership in the Enterprise
Admins grouphas the ability to administer every domain in
the forest. In addition, because domains in the forest are tightly
integrated, all domain administrators have rights and
permissions within AD they might abuse to grant themselves
privileges within other domains. Domains are not isolated from
each other and are not security boundaries.
Isolation is the ability to prevent this type of crossadministration. The forest provides isolation, so an administrator
in forest A cannot administer forest B unless explicitly granted
privileges in that forest. The security boundary is the forest, not
the domain. Isolation is only provided through separate forests.
Of course, in either case, your organization may be vulnerable to
attacks, but isolation provides a security boundary.
Situations that might require isolation include:
Financial institutions
Military and government operations
International organizations spanning multiple countries
Extranets
Demilitarized zones (DMZs)
19
Are extranet domains in separate forests?

Extranets are created to provide spaces to share resources with
partners and should be isolated from your organizations AD.
Are external trusts appropriate?

The reasons for external trusts should be evaluated and their
setup reviewed. External trusts are often established to provide
access for users in a domain in one forest to domain resources in
another. Your review should question whether this is still
necessary; whether it is legitimate; whether it meets your
security policy; whether the risk is acceptable; and if the trust is
correctly configured. Lesson 5 provides more information.
Is SID filtering used by a trusting domain in an external trust?

Security Identifier (SID) spoofing (a difficult process) might be
used to gain unauthorized access within a trusting domain by users
in the trusted domain. SID filtering can be used to block this.
If isolation is required, is it enforced?

When isolation is required, a separate forest is also required.
Is autonomy provided if needed?

The AD domain provides autonomy. Different domains within
the forest can be run by different administrators. OUs can
provide some autonomy within the domain structure, since
administrative ability can be delegated for OUs.
Is access for partner networks secured?

If partner access is provided, it should be secured by creating an
extranet and placing it in a separate forest. A trust relationship
can be established between a domain(s) in the extranet forest
and a domain(s) in the internal forest.
20
Step 5:
Examine Network Infrastructure Design and Defense
AD does not function in isolation. Though the forest provides a
security boundary, all its components sit on networks and use
network infrastructure for communication. A properly-protected
network increases AD security. A full review of network
infrastructure security is beyond the scope of a self-audit, but some
major issues should be reviewed.
Review Network Design

Is the current network infrastructure documented, including
remote locations?
Without a current record, you cannot properly evaluate controls.
Is the network segmented into areas of trust?

Areas of trust include untrusted networks such as the Internet;
partner networks; wireless networks; and trusted networks such
as the organizations LAN and remote locations. Even the
organizations trusted networks should be segmented into areas
of trustworthiness.
Are gateway controls in place between network segments?

Gateway controls include port filtering routers, firewalls,
intrusion detection systems, anti-virus gateways, and so on.
Are the right gateway controls in place in the right places?

Start by considering the strength of controls between trusted
and untrusted network segments. For example, modern, fullyloaded firewalls belong at this juncture, while a port-filtering
router may be sufficient between trusted areas of the network.
Are firewalls configured correctly for DC traffic?

DC traffic, by default, requires the use of numerous ports. This is
not good for AD security. There are alternatives, such as using
IPSec or VPNs for DC communications over firewalls, or
restricting the RPC ports used so as to reduce the number of
ports open by necessity.
21
Review Intrusion Detection and Response

AD security is not complete without a way to detect intrusions and
respond to them.
Are intrusion detection systems (IDS) used?

IDSs monitor networks and hosts. They include commercial and
open-source tools as well as in-house log monitoring programs.
Is training and dedicated staff supplied to tune and manage these

systems?
Without proper configuration and knowledgeable operation, IDS
is worthless.
Are intrusion detection and response teams present?

Once an attack is detected, what happens next? Without a
formal, organized approach, it becomes increasingly impossible
to respond to, and recover from, attacks.
Step 6:
Examine Administrative Roles and Structures
Reviewing the administrative structure of the forest and domain is
important because it can strengthen or weaken your ability to secure
AD. Just as it is not necessary to provide every user administrative rights
on his desktop computer or in the domain, it is not necessary to make
all IT administrators all-powerful in the forest or even in the domain.
Review Default Administrative Groups

Membership in default administrative groups should be reviewed.
How many administrators are assigned to each default

administrative group?
Default administrative groups include Schema Admins,
Enterprise Admins, Domain Admins in the forest root domain,
and Domain Admins in other domains within the forest.
Are there too many administrators?

This is often not an easy question to answer. In a large
environment, many administrators at each level are required to
share the load. In a small environment, a few can handle the job.
22
Many organizations today report averages such as one support

person per 100 or 150 users, but these numbers cannot be used as
the only number in judging whether or not your organization has
enough, or too many, administrators. First, the numbers may not
include administrators who do not directly support users or
maintain equipment. Second, it makes no distinction between
support personnel who may have limited administrative
privileges and those who are members of default administrative
groups. You may have to develop historical information for your
organization, and create your own numbers.
Meanwhile, you should start reviewing administrative group
membership by recording how many users have these privileges.
Its obvious that 1,000 administrators are not needed to manage
1,000 desktop systems, and theres a problem if every one of
your employees holds domain administration privileges.
Is the Schema Admins group empty?

Membership in Schema Admins is necessary in order to modify
the AD schema. Schema modifications should not be
undertaken lightly, and the schema should be protected from
inadvertent modification. Leaving the Schema Admins group
empty will prevent inadvertent changes, and can be used as a
reminder to carefully consider and plan schema changes. If
changes are planned, a trusted administrator can be added to
the Schema Admins group for the duration of that part of the
project. His account should then be removed.
Is membership in Enterprise Admins restricted?

Enterprise Admins have administrative authority throughout the
forest. They have control over every domain, every member
server and workstation, and every bit of data stored on them.
They can bring your information systems, and hence your
business, to utter ruin. Obviously, then, membership in this
group should be restricted.
Evaluate additional administrative roles?

Default administrative groups are defined in the AD domain. In
a large environment, the roles each group represents are not
sufficient. Roles may be created by using custom groups and
assigning them the necessary user rights and/or by using the
Delegation of Control wizard. And example role might be OU
administrator, a group given permission to create and manage
user and computer accounts in a specific OU.
23
Are administrative roles separated into service administration

and data administration roles?
Service administration roles manage infrastructure such as DNS,
DCs and forest configuration such as creating domains and
trusts. Service administrators also manage administrative users.
Data administrative roles manage servers, desktops, groups, and
non-administrative users. Separating these duties provides a
more secure environment for AD, limiting those who might be
able to weaken security measures and modify structures needed
for AD to function.
Are service administrator roles created in the forest root domain?

Service administration is forest-level. A unique OU should be
established in the forest root domain and service administration
groups created there. Data administrators will not be able to
manage these accounts because data administrators have no
rights in the forest root domain.
Are data administrator roles created in appropriate domain OUs?

Data administrators manage domain-level data and therefore
only need administrative rights in the domain or OU.
Evaluate Delegated Permissions on AD Objects

AD object permissions can be used to delegate administrative rights.
Are AD permissions documented?

The permissions granted on AD objects provide users with access
and control beyond their user role. This information should be
documented and reviewed. The command-line tool dsrevoke.exe
can be used to document the AD object permissions granted to a
specific user or group throughout a domain.
Is the Delegation of Control wizard used to granularize

administration?
The ability to provide users just the administrative authority
they need and no more is desirable. Help desk operators can be
given the ability to reset all user passwords or just some users,
without permission to reset administrators passwords or full
administrative rights.
24
Are AD permissions granted to groups instead of users?

Permissions should be granted to groups for ease of
administration. New users can be given rights by adding them to
a group. Accounts of users who leave the company or change
roles within the company can be removed from the groups and
will see their privileges change.
Is the use of the Delegation of Control wizard restricted?

The powerful Delegation of Control wizard can give users and
groups permission on AD objects. These permissions can
provide administrative authority to non-administrative users.
Its a great tool to provide just the administrative ability
required, without giving users rights and permissions they dont
need. However, there are thousands of objects and each one has
multiple permissions. It would not be hard to give the wrong
user access beyond whats needed or to so granularize
administration that you lose control. It is not wise to allow just
any domain administrator the right to use the wizard. It is also
not a good idea to delegate the right to change the
administrative structure of a domain.
Are
AD object permissions correct for your organizations

administrative model, and do they meet acceptable security standards?
Document the delegation of AD object permissions and review
them for correctness. They should meet the objectives of
compliance with your security policy, the principals of
separation of duties, and avoid giving excessive privileges.
Chapter 2 will provide more information on evaluating and
using AD permissions.
Are legacy AD permissions revoked?

When you uncover permissions no longer relevant, they should
be removed; dsrevoke.exe is a good tool for that.
25
Evaluate Group Policy Administration

Those that can administer Group Policy can change security via AD.
Is membership in the Group Policy Creator Owners group limited?

Group Policy changes can harden or weaken AD security. The
nuances of Group Policy and AD must be thoroughly
understood. The role should be restricted to a subset of
administrators. Limit membership in the Group Policy Creator
Owners group to service administrators designated as
administrators of security policy.
Are data administrators prevented from having Full Control over

their OUs?
Full Control implies the ability to administer GPOs linked to the
OU and any OUs in its hierarchy. This right should be restricted
to a subset of data administrators.
Secure Administrative Workstations

Administrative workstations are used to administer all aspects of the
AD environment. Leaving them unprotected weakens your ability to
secure AD.
Are administrative workstations physically secured?

Physical security for workstations can include:
26
BIOS password
Requirements for entering a syskey password, a password

that must be entered before Windows will boot
Smartcard, token and/or biometric authentication for logon
Removal of floppy, CD-ROM or other removable drives
Disabling USB, serial ports
Hardware locks on cables and drives
Physical locks to prevent theft of the workstation
Alarms that warn of computer movement
Secure Administrative Access

In addition to securing administrative workstations, consider
securing communications and other administrative access options.
Are Terminal Services logons restricted to administrators who

must use local tools?
Restrict Terminal Services logons using the Terminal Services
logon rights. Do not add user or group accounts to the Remote
Desktop.
Are extremely sensitive administration tasks restricted to local

administration only?
Some administrative tasks should only be done from the
console. For example, administering the root Certification
Authority (CA) should be done at the CA console. (Best practices
state that the root CA should not be on the network at all.)
Are administrative logons protected by long passwords or smart

cards?
The domain password policy reflects the needs of the entire
community of domain accounts. There is, however, no reason
administrative accounts cannot use longer, more complex
passwords. There is no native technical control that can enforce
this, but it can be audited using third-party tools.
Are administrative logons restricted via logon rights?

Restrict access to administrative workstations by reducing the
number of accounts that can logon locally and preventing
remote logons through user rights.
27
Evaluate the Security of Administrative Communications

between Workstations and DCs
Communications should be secured to prevent attempts at remote
administration of DCs from unauthorized workstations and to
protect the communications themselves.
Are IPSec policies used to protect administrative communications?

IPSec policies should be used on communications between
administrative workstations, DCs, and servers to require mutual
authentication and encryption as well as integrity.
If remote administration is required across the WAN or Internet,

is a VPN used?
Protect communication over other networks by using a Virtual
Private Network (VPN).
Are administrative stations on a dedicated administrative network?

Putting administrative workstations on a network separate from
your primary network makes stations harder to compromise.
Servers are connected to both networks, while administrative
workstations should be on their own. While this arrangement
may not work for every network, it can add a layer of protection
for more sensitive environments.
Is out-of-band administration secured?

If out-of-band administration is provided, it must be secured.
Many out-of-band communications hardware such as modems,
service processors, and terminal concentrators offer little security.
On the positive side, though, they do provide administration
outside of normal TCP/IP communications and therefore are not
subject to TCP/IP attacks. Physically secure the hardware provided
and ensure that features such as logons are used.
Evaluate Administrative Practices

Administrators can weaken security or attack systems by misusing
their privileges.
Are background checks performed on administrative personnel?

Administrators have the kind of access that, if used unwisely or
malignantly, can destroy an organization. Background checks
should be performed on all administrators.
28
Are administrators activities monitored and audited?

Even the most trusted individual should be monitored when his
duties involve activities that can put your organization at
significant risk.
Are PDAs and smart phones used as administration tools?

PDAs and smart phones present unique security challenges and
should not be used for DC or AD administration.
Do administrators receive appropriate security training?

Administrators need constant training to keep their skills
updated. Be sure that security training fits the administrators
required tasks.
Is the role of change approval separated from change implementation?

Management determines the information security policy and
administrators implement it. Changes to information systems,
including those that affect security, should also be approved by
management before being implemented by administrators.
Are DCs taken offline when troubleshooting is necessary?

If there is a possibility that the DC has been compromised,
administrators should not troubleshoot the system online. They
might launch code that would enable attacks on other network
systems. In fact, attack programs may need the administrative
rights to proceed.
29
Evaluate Management of Administrative Tools

Administrative tools are provided to secure and manage Windows
domains. If tools are secured, there is less risk of their use in attacks.
Are special administrative tools and utilities secured?

Many useful administrative tools are provided as support tools, in
resource kits or as third-party products. These tools should not
remain on the DC. Where possible, they should be used remotely.
Leaving tools on DCs might enable an attacker access to
information or processes that could further compromise systems.
Are Windows administrative console tools restricted?

Many of these tools run in the Microsoft Management Console
(MMC). Group Policy can be used to restrict the tools specific
administrative groups can use.
Is the MMC restricted to User Mode where appropriate?

User Mode can prevent changes to the console. This is
appropriate for data administrators with limited roles. Consoles
can be designed that include only the tools he requires.
Step 7: Examine Group Policy Details

Group Policy settings secure DCs and AD. Accurate information and
proper implementation contributes to their success.
Are GPOs documented and backed up?

Document the GPOs for each domain. If this documentation is
available, verify that the information is up to date and complete.
The Group Policy Management Console (GPMC) can document
the existence, location, and content of domain GPOs. In
addition to providing a visual display of GPOs, it can test the
application of a GPO on a specific computer or specific users;
scripts can be used to obtain documentation. You should:
30
List all domain GPOs
List disabled GPOs
Determine that all GPOs are backed up by running the report

List GPOs at a backup location.
Why are GPOs disabled?

If a GPO is disabled it is not being used. Determine the reason
for its disabled status. Legitimate, but temporary, reasons for
disabling a GPO are:
Disabling while changes are made
Disabling due to a GPO problem
However, the GPO should be enabled after changes are made or

problems fixed. If problems cannot be corrected, the GPO should
be deleted, not left. Do not enable disabled GPOs; instead,
determine the reason for the disabling and ask for action.
Why are GPOs not linked?

It is possible to create an unlinked GPO or unlink a GPO.
Unlinked GPOs are not applied. Determine the reason the GPO
is not linked and ask for action.
Is security filtering used correctly?

GPOs are not, strictly speaking, applied to security groups. GPOs
are linked to a site, domain or OU and applied to users and
computers whose accounts lie within that AD object. The
exception is when security group filtering is applied to a GP, to
prevent a GPO from being applied to members of a group. By
default, security group filtering is not used to prevent
application to existing accounts. You can document the results
of any security filtering by running the GPMC report List GPOs
by Security Group. Determine if GPOs are being applied to the
correct security groups and that each security group is getting
properly applied GPOs.
Is every GPO applied to some security group?

If a GPO is not applied to a security group, then why does it
exist? The GPMC report List GPOs without security filtering
provides a list of any GPOs not applied.
31
Check GPO Files and AD Records

GPOs exist in part as records in AD and as files in the SYSVOL share.
Both must be present. Test for inconsistencies.
Are there any orphaned GPOs?

If the files are present but there is no information in AD, the
GPO is said to be orphaned. You must determine if the files
represent a valid GPO and have a situation needing correction,
or if the files are remnants of an invalid GPO. Use the GPMC
report List GPOs orphaned in SYSVOL.
Are GPO files missing or corrupt?

Use GPOtool to check for missing and corrupt files in the
SYSVOL share and its subfolders on DCs.
Are there any GPO inconsistencies between the file system and AD?
GPOtool can be used to check consistency of GPOs between the
file system and AD in Windows 2000 Server and Windows
Server 2003 domains. It compares version numbers between
SYSVOL and AD and looks for other indicators.
Are there file access problems?

Use GPMC to look for file access problems, which may be found
when running the GPMC Group Policy results report. Look for
file access problems recorded in DCs application logs. The
EventCombMT application
(http://www.microsoft.com/technet/security/tools/default.mspx)
can be used to search multiple DC application logs for events
related to file access problems.
Are the correct file versions present?

If the correct file versions are not loaded on the client, GPO
processing may suffer. Use the System File Check (SFC) utility to
check for missing client files and determine whether the right
file versions are present. The following files are located in the
%windir%\system32 folder:
32
Appmgmts.dll
Dskquota.dll
Fdeploy.dll
Gptext.dll
Scecli.dll
Userenv.dll
Evaluate Policy Application

Are DCs tested to see if GPOs are applied?
If GPOs are not applied, security modifications to computers
and users are not applied. Several tools can be used to
determine if policies have been applied:
GPMC
GPResult. This Win2K Resource Kit tool must be run while

logged on to the client computer. It will report a list of the
policy settings applied at that computer for that computer
and for the currently logged on user. The Windows
Server 2003 version provides more information, similar to
those provided by Resultant Set of Policy (RSoP).
Are GPOs monitored during security changes to determine if they

are being applied?
The resource kit tool GPOMonitor can be installed on clients,
and produces a log showing the time of policy application. When
security changes are made, GPOMonitor logs should be checked
to determine if the changes were applied.
Step 8: Review Technical Controls

Technical controls are implemented using object permissions,
authentication, Group Policy and registry settings. The use of many
of these technical controls is coming in Chapter 2.
Evaluate the Domain Security Policy

The domain security policy contains the configuration settings for
the password, account lockout, and Kerberos policies for the
domain. They should be examined for compliance with the
organizations security policy and for comparison with industry best
practices. They are important in securing AD because they control
authentication in the domain. If these controls are weak, they can
easily be subverted. In a properly secured AD environment, technical
controls are based on accounts and group membership and the
rights and permissions granted to those groups. If it is easy to
compromise accounts, all other protections are irrelevant.
33
Is a standard DC security template/GPO used for all domains in

the forest?
Consistency in AD security can be obtained by creating a
standard DC GPO and using it in each domain. A standard
security template should be designed and used as the basis for
the standard GPO to provide a method for auditing the existent
security policy against that approved and set in the template.
Are changes to domain security policy made in the default

domain security GPO?
Policy settings, like changes to password policy, account lockout,
and Kerberos policy, if made in other GPOs linked elsewhere, will
have no impact on these settings for domain accounts.
Does the password policy reflect your security policy?

The password policy should reflect your security policy if at all
possible. (If, for example, your security policy requires that
passwords have numbers in the middle of the password, the
domain policy will not technically support this.)
Is the password policy strong?

Keeping the password policy strong helps defend against password
cracking attacks. If passwords for administrators that can configure
security or administer AD are cracked, AD can be compromised.
Recommendations for a strong password policy include:
Require passwords to include upper and lower case letters,

numbers, and special characters. For more sensitive
accounts, unicode characters that do not represent printable
characters can be used.
Require at least an eight-character password and require

administrators to use a longer password.
Enforce password history. This prevents immediate and

frequent reuse of previously used passwords. A
recommended history setting is 24.
Require passwords to be changed periodically. Every 30 days

is a reasonable interval.
Is the Account Lockout policy set appropriately for the domain?

Account Lockout policies lock out accounts after a set number of
attempts. In a high-risk environment, the policy could be used
as a Denial of Service attack, by rapidly attempting a dictionary
or brute force attack against multiple accounts. In this
environment an account lockout policy may not be a good
solution. In other environments it will be.
34
Is the Kerberos policy kept at the defaults?

The Kerberos policy is set at installation time to protect
authentication. The setting Enforce user logon restrictions
ensures that the user logon rights are evaluated when remote
connections are attempted, and that the right to access the
computer over the network is also evaluated. This setting is
enabled by default and should be left enabled.
Evaluate the DC Security Policy

The DC GPO sets the Audit Policy, Security Options, and User Rights
for the domain. Settings here are critically important in securing AD.
Some of the security options are addressed in steps relevant to them.
The policy also establishes settings for auditing, services and other
policy operation specific to DCs.
Review Audit Policy

It is important to set audit policy in order to log information
necessary for intrusion detection or troubleshooting.
Are audit policies set?

Audit policy should be established, including auditing directory
service access.
Is auditing on AD objects enabled and configured?

Auditing for success should be enabled for Directory Service
access. This allows logging of successful access to directory
objects whose Security Access Control Lists (SACLS) are
configured. Important objects to audit include the schema
directory partition, the configuration partition and the domain
directory partition. The document Best Practices for Securing
Active Directory Installations and Day-to-Day Operations,
(http://www.microsoft.com/technet/prodtechnol/windows2000ser
v/technologies/activedirectory/maintain/bpguide/default.mspx),
provides the SACL settings for these objects.
35
Review User Rights on DCs

User rights determine what users can do on a system. It is critical
that local access and domain user rights are restricted on the DC.
Are user rights minimized?

User rights control what users can do on a system. The user
rights section of Group Policy has the added responsibility of
defining the users rights in the domain.
Are log on locally rights reserved for Administrators, Backup

Operators and Server Operators?
Account Operators and ordinary users should have no need to
log on locally.
Is the Shut Down the System right restricted to Domain Admins

and Server Operators or a subgroup of Domain Admins?
It is not necessary for Account Operators, Print Operators, or
other user groups to shut down DCs.
Are different groups assigned the Backup Files and Directory

and the Restore File and Directory rights?
Separating these rights can help protect the system from a
malicious or inadvertent restore of older backups over the
current system. An individual charged with backing up the DC
cannot accidentally or intentionally restore older files. The
Backup Operators group normally has both privileges, but the
rights can easily be separated by creating two groups, each with
only one privilege.
Is backup and restore restricted to a subset of administrators?

By default, the Backup Operators and the Administrators groups
have the backup and restore rights. It is not necessary that all
administrators have this right. A custom group can be created
for this purpose and a small set of administrators added to the
custom group. The Administrator group should then be removed
from this right.
Are non-essential accounts denied access to DCs from the network?

Add the Guest account and any non-operating system service
accounts used to run local services to the Deny Access to this
Computer from the Network right. This can prevent network
attacks using these accounts.
36
Is the right to debug systems restricted?

Known attacks use the right to debug systems, and by default all
administrators have this right. Remove the Administrators group
and replace with a custom group that may need this right for
troubleshooting or some patch installation.
Is the Guest account disabled?

The guest account should be disabled on all DCs.
Are users prevented from installing printer drivers?

Users should not be installing any type of driver on DCs.
Is the right Load and Unload Device Drivers restricted to

administrators?
The Print Operators group typically has this right, which should
be removed.
Are printers not installed on DCs?

Is the right Allow Server Operators to Schedule Tasks disabled?
Task scheduling should only be done by administrators.
Is the right to Take Ownership granted only at the forest or local

server level?
Administrators have this right by default, but it can be granted to
any user or group. The right to take ownership in the domain
implies the right to take ownership of any object, including any
directory partition in the AD. This grants its holder rights at the
forest levelprobably not something that was intended. If granted
to a local group on a server or workstation, the right implies only
the right to take ownership of the objects on the server.
Evaluate Security Options

Security Options should also be implemented to protect AD.
Are anonymous connections restricted?

The restriction on anonymous connections should be configured
if legacy computers and applications are not part of the domain.
Additional anonymous restrictions can be obtained by restricting
anonymous access to named pipes and to registry keys.
Is task scheduling restricted to administrators?

As previously mentioned, task scheduling should not be turned
on for server operators.
37
Is the Clear virtual memory pagefile when system shuts down

option enabled?
Information stored in the pagefile may be accessible if the
system can be rebooted to another OS.
Are LAN Manager authentication choices restricted?

While Kerberos is the default network authentication protocol,
the LAN Manager protocol may be used by legacy clients, or
when Kerberos cannot be used. LAN Manager should be
restricted to prevent the use of LM or even NTLM
authentication, and the hashes necessary for LM authentication
should be removed from the password database.
Evaluate Services
Every service that runs on the DC may reduce its security because it
increases the attack surface.
Are Unnecessary services disabled?

The Microsoft security templates provided with the Windows
Server 2003 security guide
(http://www.microsoft.com/downloads/details.aspx?FamilyID=8a2
643c1-0685-4d89-b655-521ea6c7b4db&displaylang=en)
recommend services that are required by the DC. Services not
required for its operation should be disabled.
Is the right to reconfigure services startup controlled?

Only service administrators should have the right to modify the
startup status of system services. This right is controlled in
Group Policy by defining the policy in the services node for each
service. When managing the startup mode, use the Edit Security
button and then the object picker to give service administrators
Full Control while ensuring the Interactive groupthe group of
all users locally logged onhas only Read permission.
38
Evaluate Event Log Settings

Are event log sizes adequate?
Event logs should be large enough to accommodate the number of
events recorded between the times they are archived and cleared.
Are event logs archived?

Event logs should be frequently archived to ensure continuity of
log information.
Is the retention method set to overwrite older events?

If you miscalculate the size of the log required or the time to
archive and clear, or if an attack rapidly fills the log, ensure that
the latest events remain in the log.
Evaluate EFS
Is EFS disabled in the domain if not managed?
EFS is a powerful file encryption system, but should not be
enabled unless properly managed. It should not be used to
encrypt system files.
39
Step 9:
Evaluate File and Registry Permissions on DCs
File and registry permissions strengthen or weaken security. Most
security settings created in the GUI are echoed in the registry. If
permissions are weak, registry settings can be manually hacked and
security compromised. The interaction between Group Policy and
the registry is complex; Group Policy refresh may override manual
registry configurations, but the system may already be compromised.
Are drive root permissions hardened?

Root drive permissions provide users with create file and
folder and write data permissions on subfolders. When new
folders are added, these permissions are inherited and may
provide excessive access. Root drive permissions need to be
hardened. Provide Full Control for administrators, and Read and
Execute for everyone else.
Are share permissions on the SYSVOL correct?

When the server is promoted to a DC, its shares the SYSVOL.
Permission on this share and its underlying directory are set to
accommodate connections from other DCs and domain member
computers, as well as allowing users to authenticate.
Permissions should not be changed.
Are object permissions correct for securing AD?

Default permissions on the file system and registry should not
be weakened. Object permissions prevent misuse, deletion or
misconfiguration of AD.
Is 8.3 name generation disabled?

A number of attacks are 16-bit applications that expect 8.3compatible file names. DCs should not be running 16-bit
applications locally and therefore do not need 8.3-compatible file
names.
The
REG_DWORD
registry
value
NtfsDisable8dot3NameCreation should be set to 1 at the location
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
40
Step 10: Review Protection for AD Communications

AD data must be replicated between replication partners within each
domain; some data is also replicated between domains in the forest.
In addition, clients connect to DCs for machine and user
authentication as well. Protection for these communications can be
increased by using VPNs, SSL, IPSec and LDAP signing.
In legacy-free domains, are LAN communications signed?

The security option LDAP Server Signing Requirement
requires the signing of LDAP traffic between AD and clients. This
setting should not be required if legacy clients (Windows NT 4.0,
Windows 9x, Windows ME) still exist in the domain.
Is SMB message signing turned on?

SMB is the basis for NetBIOS communications between
Windows computers. When used, SMB signing guarantees the
origination of the message, helping secure communications. It
cannot be used for some legacy systems and may interfere with
communications between some systems.
Is session security for NTLM configured?

Session security can be configured to provide encryption and
integrity. Legacy systems and applications may not be compatible.
Is IPSec used to secure communications between DCs and also

administrative clients and DCs?
IPSec can be used to control who communicates to what, and
whether approved communications are encrypted. Using IPSec
to secure all communications may not be a practical idea, but
for some uses it is necessary.
Are L2TP/IPSec VPNs used to secure DC communications over

firewalls?
Rather than open the many ports necessary for DC replication
over firewalls, a VPN can be used.
Are event logs reviewed for communication errors?

Review event logs to find evidence of communication errors.
Dont rely on configuration settings to prove current security is
correct and working.
41
Step 11: Review Maintenance Procedures

Securing AD is an ongoing process. It is not enough to test the health of
AD, review security configuration, or evaluate employees trustworthiness
only once. You should do so repeatedly, and address issues such as
logging, updating, patching, and other maintenance issues.
Review Logging Configuration and Management

DC event logs provide information on system health, serve as an
early warning system for attack monitoring and can trace attacks to
determine type and any security compromises. Following an attack,
the logs can forensically support investigation and prosecution.
Are logs adequately sized and frequently archived?

Security logging can create many records.
Is centralized logging in place?

Centralized logging removes log data from the DCs (if the
machine is compromised, the log might be tampered with) and
makes it more easily searchable.
Are logs reviewed and the results acted upon?

Without review, logs only serve as historical data, but they can
be hard to collect and make sense of. There are a number of
commercial products that assist in sorting and collecting events.
In a small environment, a free product such as EventCombMT
(http://www.microsoft.com/technet/security/tools/default.mspx)
can be used to consolidate information from event logs on
multiple systems by event categories.
Do audit settings include success and failure?

If settings are only set to record failures, how do you know if an
attacker has succeeded?
Are account logon and logon events audited for success and failure?
It is critical to monitor logon events for evidence of possible
attacks and account compromise.
Are account management events audited for success and failure?

Users should not have membership in administrative groups
without approval. Monitoring account management events and
comparing them against approved changes can detect variances.
42
Is object access turned on?

If object access is not turned on in Group Policy, you cannot
audit object access on the file, registry, and printer objects.
Are system events audited for success and failure?

Server shutdown and startup event monitoring can provide
evidence of unauthorized shutdowns. Many attacks require
shutting down the system.
Are policy changes logged?

Changes in audit policy should be monitored.
Review Change Management Procedures

Change management is the process
configuration adjustments, and patching.
of
managing
updates,
Are suggested changes and updates reviewed before being made?

The impact of suggested changes should be reviewed and its
impact on AD security considered.
Are changes tested before implementation?

Without testing, you cannot be sure that the effect of a change
will be positive or know what its impact on security will be.
Are changes to DCs made by approved personnel?

Trained, aware personnel should always make or supervise
changes to ensure they are done correctly and that problems are
reported and managed.
Are processes flexible, allowing for triage of changes?

Many changes, upgrades, new products, and so on can and
should be evaluated over time. Others, such as configuration or
patching changes that improve security or patch vulnerabilities,
should be quickly reviewed, tested, and implemented.
43
Review Security Patch Processing

Security patching should have accelerated procedures in place and
not be delayed by cumbersome change management processes.
Is monitoring for alerts of new security patches or configuration

performed?
You have to be aware of problems before you can correct them.
Are new patches reviewed for applicability before application?

Not every patch should be applied. Some are not meant for DCs
or applicable unless specific circumstances exist.
Are patches tested before application?

Any change should be tested.
Is an automated method for patch application in place?

Manual patching hinders the prompt and complete application
of patches when many machines are involved.
Are patched machines evaluated to ensure patch implementation

and continued smooth network operation?
A testing lab is just thata simulation of your environment.
Once a patch is applied, you may find other issues.
Are new DCs patched when built to ensure that they are brought
online as fully patched machines?
A new installation presents an easy target to malicious software.
Installation routines can be modified to include application of
the latest service packs and security patches.
Is anti-virus protection added to DCs?

Servers being promoted to DCs should be scanned first. If DCs
are built from scratch, anti-virus protection should be added
during the install.
Is anti-virus protection prevented from modifying SYSVOL

security descriptors?
Some anti-virus software modifies the security descriptor of SYSVOL
files when scanning. Each modification of these files triggers FRS
replication, creating high volumes of replication traffic.
Is the DCpromo answer file adjusted to provide a more secure

installation of DCs?
The DCpromo answer file should be modified. Note that there
should be a different answer file for the first DC in a domain.
44
Are the AD database and SYSVOL folder on a separate drive from

the system volume?
There are attacks against the system volue that seek to disable
the system by filling up drive space. Having AD on a separate
drive prevents damage from such an attack.
Is pre-Win2K compatibility disabled?

Pre-Win2K compatibility
directory queries.
provides
anonymous
access
to
Is the ability to use cached credentials prevented when accessing

the DC console?
Cached credentials might be used by an administrator whose
account is disabled due to termination.
Is a reserve file provided to protect against disk space attacks?

A reserve file is simply a large file that takes up disk space. In the
event of a disk space attack that fills up the disk, the reserved file
can be deleted to recover the system.
Step 12: Review Non-Technical Controls

Non-technical controls cannot be enforced by configuring security.
Review Security Policy

An information system security policy is a written management
directive that states how information systems should be secured.
Every organization should have one. Questions that should be asked:
Is the policy periodically reviewed for applicability and new

requirements?
Who takes part in the review? In the formation of new policy?

Does the policy reflect security that will enhance the protection
of AD?
Is a computer and Internet acceptable use policy established?
45
Evaluate User Security Awareness

A nave user can do more to ruin information security than many
outsiders who want to attack and damage your systems.
Are users provided information security awareness training?

Awareness training can be as simple as explaining the reason
behind policies such as disallowed password sharing or how to
create a complex password that is less vulnerable to cracking.
Are users provided copies of the acceptable use and other security
policies and given opportunity to study and ask questions about
them?
Understanding does not guarantee compliance, but it does enable
it. It also has the benefit that users understand the penalties for
non-compliance; that may help enhance compliance.
Evaluate Policy and Procedure for DC Administration

All policies and procedures should be reviewed with respect to their
impact on DC and AD security. However, even casual observance
and attitude checks should be made. It should be obvious, for
example, that Internet browsing from the DC is not allowed and a
bad idea; still, some may do so.
Are DCs only used for AD? In other words, no server or user
applications should co-exist on the DC.
Every piece of code introduced onto a DC can weaken its
security. These applications may require access and
configuration changes that weaken security, and they expose the
DC to compromise if they have vulnerabilities.
Is Web browsing prevented and restricted controls left in place?

In addition to having a policy, the Internet Explorer Enhanced
Security Configuration option should be left in place.
46
Review Business Continuity/Disaster Recovery Plans

A business continuity plan details how a business will stay in business
after a major disaster. (Disaster recovery is the process of getting
essential business services up and running again. Business continuity
is concerned with making sure the business can stay in business.)
Is AD recovery a part of the organizations business continuity plan?

In addition to IT backup and recovery practices, the
organization itself must understand and prepare for the return
of a fully functional AD environment.
Are periodic, proper backups of AD made?

While copies of AD exist on each DC, and recovery of a single DC
may be easily accomplish by promoting a new server, you will
not always be able to rely on this strategy. What happens, for
example, if the first DC of the root domain of the forest dies?
Backup and recovery plans should be in place and followed.
Are backups stored on- and offsite?

Recovery when the main site is destroyed, or onsite backups are
destroyed, is possible if offsite storage is also used.
Are offsite recovery operations arranged for?

Is recovery possible if the main data center is destroyed?
Are restoration procedures periodically tested?

Without testing, there is no guarantee that backups or
procedures will work.
Are recovery drills practiced?

It is not enough to test backup media or recovery of a single DC.
All staff should be trained in recovery procedures.
47
SUMMARY
This chapter provides a set of questions that should be asked as part
of a self-audit of AD security. Some may need more details and
background in order to put it to use. Others may want to use it as the
basis for developing their own comprehensive security review plans.
Following this summary, there is a checklist created from the steps
reviewed in this chapter. It may be helpful for you to use this
checklist as a guide in completing the self-audit.
Future chapters of this e-book will delve further into topics.
Although this document can serve as a starting point, reading the
lessons cannot serve as your sole effort. You must put your new
knowledge into practice; once thats done, the next step is to
constantly update those practices. Knowledge of how to protect
systems changes rapidlyjust like the knowledge of those who try to
destroy them. I look forward to your comments, questions,
additions, and suggestions on how I can make this e-book even more
useful to you in succeeding chapters.
48
SELF-AUDIT CHECKLIST
Item
Comments
1) Documentation of AD infrastructure
2) Physical security for DCs
3) Active Directory health
a)
Connectivity
b)
DNS operation
c)
DNS security
d)
Time services operation
e)
AD replication
f)
FRS replication
4) AD infrastructure design, including security

boundaries
5) Infrastructure design and defense

a)
Network design
b)
Intrusion detection and response
6) Administrative roles and structures

a)
Default administrative groups
b)
Delegated permissions on AD objects
c)
Group Policy administration
d)
Administrative workstations
e)
Administrative access
f)
Administrative connections between

workstations and DCs
g)
Administrative practices
h)
Management of administrative tools
49
Item
Comments
7) Group Policy details

a)
GPO files and AD records
b)
Policy application
8) Technical controls
a)
Domain security policy
b)
DC security policy
c)
Audit policy
d)
User rights on DCs
e)
Security options
f)
Services
g)
Event log settings
h)
EFS
9) File and registry permissions on DCs

10) Protection for AD communications
11) Maintenance procedures
a)
Logging configuration and management
b)
Change management procedures
c)
Security patch processing
12) Non-technical controls
50
a)
Security policy
b)
User security awareness
c)
Policy and procedure for DC administration
d)
Business continuity/disaster recovery plans
ABOUT QUEST WINDOWS MANAGEMENT

Quest Software, now including the people and products of Aelita
Software, provides solutions that simplify, automate and secure
Active Directory, Exchange and Windows environments. The Quest
Windows Management group delivers comprehensive capabilities
for secure Windows management and migration. For more
information on Quest Softwares Windows Management group,
please visit http://www.quest.com/microsoft.
ABOUT QUEST SOFTWARE, INC.

Quest Software, Inc. provides business-critical software for 18,000
customers worldwide, including 75 percent of the Fortune 500. Quest
offers products for application performance management for
packaged applications and Java environments; database
management for Oracle, DB2, SQL Server, Sybase and MySQL
environments; and Windows management in Active Directory and
Exchange. These management solutions help customers develop,
deploy, manage and maintain the IT enterprise without expensive
downtime or business interruption. Headquartered in Irvine, Calif.,
Quest Software can be found in offices around the globe and at
www.quest.com.
Quest Software
Windows Management
6500 Emerald Parkway
Suite 400
Columbus, OH 43016
USA
Phone: 614-336-9223
1-800-263-0036
51

Ch1 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ch1 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Five Key Lessons to

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

STEP 12: REVIEW NON-TECHNICAL CONTROLS .............................................................45

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

WHO SHOULD READ THIS BOOK

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

CHAPTER 1: PERFORM A SELF-AUDIT

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

FIRST, LOOK IN THE MIRROR

Ensure that activities and procedures conform to norms and

Apply a systematic, disciplined approach to evaluate current

Assess the adequacy of system controls. (Do the controls work?

Ensure compliance with established security policies and

Recommend necessary changes in controls, policies, and

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

A self-audit is not a substitute for an independent audit by

A self-audit is not a troubleshooting exercise. But it may turn up problems,

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

YOU CAN CHANGE THINGS, SHOULD YOU?

It is felt that only an independent, removed review can provide

Outsiders do not have administrative-level privileges on

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

PERFORM THE AUDIT

Step 1: Document Your Infrastructure

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

The documentation required for a self-audit should be part of your

The number and location of sites. Indicate number of users and

The number and names of all domains

Are DCs at headquarters and divisions kept in a secured data center?

Are DCs kept on protected network segments?

Are cable closets protected?

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

Are DCs at remote locations physically secured?

They should be in a locked room or cabinet in an area free

Smartcard, token and/or biometric authentication for logon

Remove floppy, CD-ROM or other removable drives

Disable USB and serial ports

Put hardware locks on cables and drives

Place additional locks on the computer system unit

Install alarms that warn of computer movement

Are DCs protected from power failures?

Is access to DCs restricted?

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

Step 3: Check Active Directory Health

Does connectivity exist between clients and DCs?

Does connectivity exist between replication partners?

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

Is connectivity available for domains in trust relationships?

Evaluate DNS Operation

Are DNS configuration and response issues periodically checked?

Evaluate DNS Security

Are zone transfers restricted to approved secondary DNS servers?

Is the DNS cache secured against cache pollution?

Securing Your Active Directory. Chapter 1 - Perform a Self-Audit

Is DNS integrated with AD?

Are secure dynamic updates configured?

Are external and internal DNS services separated?

Are requests for zone delegation carefully reviewed?

Are backups of zone information kept?

Evaluate Time Services Operation

Is the root domain of the forest PDC Emulator configured to