securing your active directory. chapter 1 - perform a ......

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

C h a p t e r s

Roberta Bragg

MCSE, CISSP, Author, Columnist,

Speaker, Consultant

Five Key Lessons to

ActiveDirectory

Securing

Sponsored by:

Your

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 3

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

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

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 permissions—all 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-audit—A checklist to assist in determining current Active Directory security status.

Chapter 2: Know and Use Security Tools and Techniques—“How tos” with an emphasis on securing Active Directory.

Chapter 3: Monitor Active Directory Operations—How to monitor and improve Active Directory health.

Chapter 4: Leverage People and Processes—Training, awareness, security policy, accountability, physical security, and business continuity.

Chapter 5: Active Directory Security Maintenance—Auditing 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 that’s 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. Here’s 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 [email protected].


mailto:[email protected]

CHAPTER 1: PERFORM A SELF-AUDIT

Like many complex undertakings, the process of securing AD must be approached as a series of repetitive tasks—steps 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 in—Oh, 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? It’s not intrusive or disruptive like an actual attack, and it’s 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? It’s one thing to have a password policy; it’s 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 organization’s 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 organization’s security policy, and that you haven’t 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.


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 important—for example, you don’t know what a malfunctioning GPO does, I’d continue the audit and make a list of things to do. If your network and AD operations are well-run to begin with, you’re 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.


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 organization’s 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 organization’s 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.


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 organization’s network should not be accessible to telephone company employees.


•

•

•

•

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.


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 AD’s 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 can’t replicate, security can’t 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. Don’t forget to check connectivity between replication partners across firewalls.


•

•

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 AD’s 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 AD’s dependence on DNS, it’s 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 NSLookup’s 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.


http://support.microsoft.com/default.aspx?scid=kb;en-us;321045

•

•

•

•

•

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 synch—that 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 policy—any 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.


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.


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 administrators—those with membership in the Enterprise Admins group—has 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 cross-administration. 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)


•

•

•

•

•

•

Are extranet domains in separate forests?

Extranets are created to provide spaces to share resources with partners and should be isolated from your organization’s 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.


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 organization’s LAN and remote locations. Even the organization’s 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, fully-loaded 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.


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.


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. It’s obvious that 1,000 administrators are not needed to manage 1,000 desktop systems, and there’s 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.


•

•

•

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.


•

•

•

•

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. It’s a great tool to provide just the administrative ability required, without giving users rights and permissions they don’t 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 what’s 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 organization’s 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.


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:

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.


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.


•

•

•

•

•

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 administrator’s 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.


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:

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 GPO’s 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.


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:

Appmgmts.dll

Dskquota.dll

Fdeploy.dll

Gptext.dll

Scecli.dll

Userenv.dll


http://www.microsoft.com/technet/security/tools/default.mspx

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 organization’s 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.


•

•

•

•

•

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.


• 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/windows2000serv/technologies/activedirectory/maintain/bpguide/default.mspx), provides the SACL settings for these objects.


http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/bpguide/default.mspx

http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/bpguide/default.mspx

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 user’s 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.


•

•

•

•

• •

•

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 level—probably 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.


•

•

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=8a2643c1-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 group—the group of all users locally logged on—has only Read permission.


http://www.microsoft.com/downloads/details.aspx?FamilyID=8a2643c1-0685-4d89-b655-521ea6c7b4db&displaylang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=8a2643c1-0685-4d89-b655-521ea6c7b4db&displaylang=en

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.


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.3-compatible 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


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. Don’t rely on configuration settings to prove current security is correct and working.


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.


http://www.microsoft.com/technet/security/tools/default.mspx

•

•

•

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 of managing updates, configuration adjustments, and patching.

•

•

•

•

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.


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


•

•

•

•

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 provides anonymous access to directory queries.

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?


Evaluate User Security Awareness

A naïve 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.


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 organization’s 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.


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 that’s done, the next step is to constantly update those practices. Knowledge of how to protect systems changes rapidly—just 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.


SELF-AUDIT CHECKLIST

Item Comments

Documentation of AD infrastructure

Physical security for DCs

Active Directory health

Connectivity

DNS operation

DNS security

Time services operation

AD replication

FRS replication

AD infrastructure design, including security boundaries

Infrastructure design and defense

Network design

Intrusion detection and response

Administrative roles and structures

Default administrative groups

Delegated permissions on AD objects

Group Policy administration

Administrative workstations

Administrative access

Administrative connections between workstations and DCs

Administrative practices

Management of administrative tools

1)

2)

3)

a)

b)

c)

d)

e)

f)

4)

5)

a)

b)

6)

a)

b)

c)

d)

e)

f)

g)

h)


Item Comments

7) Group Policy details

GPO files and AD records

Policy application

Technical controls

Domain security policy

DC security policy

Audit policy

User rights on DCs

Security options

Services

Event log settings

EFS

File and registry permissions on DCs

Protection for AD communications

Maintenance procedures

Logging configuration and management

Change management procedures

Security patch processing

Non-technical controls

Security policy

User security awareness

Policy and procedure for DC administration

Business continuity/disaster recovery plans

a)

b)

8)

a)

b)

c)

d)

e)

f)

g)

h)

9)

10)

11)

a)

b)

c)

12)

a)

b)

c)

d)



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 Software’s 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

http://www.quest.com/microsoft

http://www.quest.com/

securing your active directory. chapter 1 - perform a ......

Documents