Microsoft Solutions for Security and Compliance Server and Domain Isolation Using IPsec and Group Policy
© 2006 Microsoft Corporation. This work is licensed under the Creative Commons Attribution-NonCommercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
Table of Contents
Table of Contents Chapter 1: Introduction to Server and Domain Isolation.....................1 Executive Summary............................................................................1 Who Should Read This Guide...............................................................2 The Business Challenge.......................................................................3 Creating a Project Team......................................................................6 Guide Overview..................................................................................7 Scenario Outline.................................................................................9 Summary..........................................................................................14 Chapter 2: Understanding Server and Domain Isolation....................15 Chapter Prerequisites.......................................................................15 Who Should Read This Chapter.........................................................16 Identifying Trusted Computers.........................................................20 How Does Server and Domain Isolation Fit into My Overall Network Security Strategy?............................................................................24 Terminology Refresher......................................................................27 How Can Server and Domain Isolation Be Achieved?.........................30 What Does Server and Domain Isolation Protect Us From?................39 How Can We Deploy Server and Domain Isolation?...........................40 Summary..........................................................................................41 Chapter 3: Determining the Current State of Your IT Infrastructure. .43 Chapter Prerequisites.......................................................................43 Who Should Read This Chapter.........................................................44 Identifying Current State..................................................................45 Capacity Considerations ...................................................................56 Predeployment Concerns..................................................................57 Trust Determination..........................................................................59 Capturing Upgrade Costs for Current Hosts.......................................64 Summary..........................................................................................66 Chapter 4: Designing and Planning Isolation Groups.........................69 Chapter Prerequisites.......................................................................69 Creating the Server and Domain Isolation Design..............................70 Group Implementation Methods........................................................86 Group Implementation for Woodgrove Bank.....................................89 Summary..........................................................................................90 Chapter 5: Creating IPsec Policies for Isolation Groups.....................93 Chapter Prerequisites.......................................................................93
iii
iv
Server and Domain Isolation Using IPsec and Group Policy
Summary........................................................................................131 Chapter 6: Managing a Server and Domain Isolation Environment...133 Chapter Prerequisites.....................................................................133 Change Management.......................................................................134 Backup/Restore Considerations......................................................148 Mitigation of Network-Based Infections..........................................149 Summary........................................................................................152 Chapter 7: Troubleshooting IPsec...................................................153 Support Tiers and Escalation...........................................................153 Tier 1 Troubleshooting....................................................................154 Tier 2 Troubleshooting Preparation.................................................162 The IPsec Troubleshooting Process.................................................171 Tier 3 Troubleshooting....................................................................209 Summary........................................................................................210 Appendix A: Overview of IPsec Policy Concepts...............................213 Introduction...................................................................................213 IPsec Policy Filters..........................................................................214 IKE Negotiation Process..................................................................217 Security Methods............................................................................219 IPsec Encapsulation Modes and Protocol Wire Formats...................219 IKE Authentication..........................................................................220 IKE Authentication Methods and Security Method Preference Order 223 Security Negotiation Options...........................................................224 Appendix B: IPsec Policy Summary.................................................227 General Policy Configuration...........................................................227 Isolation Domain Policy..................................................................231 No Fallback Isolation Group Policy..................................................231 Boundary Isolation Group Policy.....................................................232 Encryption Isolation Group Policy...................................................233 Appendix C: Lab Build Guide............................................................235 Prerequisites..................................................................................235 Deployment of the Baseline Policy...................................................237 Implementing the IPsec Policies.....................................................237 Using the Policy Build-up Method to Enable the Baseline IPsec Policy 245 Test Tools and Scripts for the Functionality Tests............................248 Enabling Organization Secure Subnets Filter List on Remaining Policies 250 Enabling Network Access Group Configuration................................251
Table of Contents
Enabling the Isolation Domain........................................................256 Enabling the No Fallback Isolation Group........................................258 Enabling the Encryption Isolation Group.........................................260 Enabling the Boundary Isolation Group...........................................262 Configuring the Isolation Domain as the Default Isolation Group. . . .264 Final Functional Tests—All Isolation Groups Enabled.......................265 Summary........................................................................................270 Appendix D: IT Threat Categories....................................................271 Threats Identified by STRIDE..........................................................271 Other Threats..................................................................................274 Summary........................................................................................275 Links...............................................................................................277 Acknowledgments...........................................................................283
v
Feedback The Microsoft Solutions for Security and Compliance team would appreciate your thoughts about this and other security solutions. Please direct questions and comments about this guide to
[email protected]. We look forward to hearing from you.
Chapter 1: Introduction to Ser ver and Domain Isolation The practice of physically isolating computers and networks to protect data or communications from being compromised has been used for many years. The problem with physical isolation is that the information technology (IT) infrastructures of many enterprise organizations cannot easily be protected behind hard physical boundaries. The prevalence of mobile clients and the nature of distributed network environments make such physical limitations too inflexible to implement and operate. Server and domain isolation make it possible to create a layer of security to achieve logical isolation of the network traffic that moves between computers or networks. If an attacker manages to gain physical access to a company's internal network and attempts to access a server that contains valued data assets, server and domain isolation can block access simply because the computer that the attacker is using is not a trusted company device, even if the attacker used a valid user account and password. The logical isolation approach using server and domain isolation techniques enables the development of a flexible, scalable, and manageable isolation solution that provides the security of isolation without the cost or inflexibility of physical boundaries.
Executive Summary Microsoft recognizes that large organizations face increasing challenges in securing the perimeter of their networks. As organizations grow and business relationships change, controlling physical access to the network can become impossible. Every day, customers, vendors, and consultants connect mobile devices to your network for valid business reasons. The advent of wireless networks and wireless connection technologies such as General Packet Radio Service (GPRS) and Bluetooth has made network access easier than ever. This increased connectivity means that domain members on the internal network are increasingly exposed to significant risks from other computers on the internal network, in addition to breaches in perimeter security. Although personal or host-based firewalls help secure clients when connected to the Internet, they are not yet well-suited for protecting internal servers and clients. Server and domain isolation provide a number of business benefits. Most importantly, it provides a layer of network security that can significantly reduce the threat of untrusted hosts accessing trusted domain members on an organization's internal network. Server and domain isolation can be an important strategy in the defense against virus propagation, internal hackers, employee misuse of technology assets, and information theft. In addition, it can be used to require domain membership of all clients that seek access to trusted resources, either clients or servers, so that they can be better managed by professional IT staff. Server and domain isolation can also be used either as a primary or an additional strategy for meeting data privacy or other protection requirements for data in network traffic, without modifying existing Microsoft® Windows® applications or deploying virtual private networking (VPN) tunneling hardware on the network. At its core, server and domain isolation allows IT administrators to restrict TCP/IP communications of domain members that are trusted computers. These trusted
computers can be configured to allow only incoming connections from other trusted computers, or a specific group of trusted computers. The access controls are centrally managed by using Active Directory® Group Policy to control network logon rights. Nearly all TCP/IP network connections are able to be secured without application changes, because Internet Protocol security (IPsec) works at the network layer below the application layer to provide authentication and per-packet, state-of-the-art security endto-end between computers. Network traffic can be authenticated, or authenticated and encrypted, in a variety of customizable scenarios. The Group Policy and IPsec configurations are centrally managed in the Active Directory. The concept of logical isolation presented in this guide embodies two solutions—domain isolation to isolate domain members from untrusted connections, and server isolation to ensure that a server accepts network connections only from trusted domain members or a specific group of domain members. These solutions can be used separately or together as part of an overall logical isolation solution. The tested solution provided in this guide requires the following minimum platform configuration: •
Windows 2000 with Service Pack 4 or later
•
Microsoft Windows Server™ 2003
•
Windows XP with Service Pack 2 or later
These configuration requirements ensure that the IPsec components are at the required revision level. Communication with non-Windows platforms or untrusted systems is controlled by the IPsec configuration having a list of exemptions and/or being allowed to fall back to clear text (non-IPsec) communication. Network address translators are no longer a barrier to using IPsec on the local area network (LAN) with the new network address translation (NAT) traversal capabilities. This guidance uses the Woodgrove National Bank scenario to demonstrate the implementation of both server and domain isolation in a representative lab environment. It also presents the experience that Microsoft gained in implementing both of these solutions internally as well as in customer environments. A Microsoft team of subject matter experts developed this guidance, and both Microsoft professional IT staff and a number of customers through a Beta program have reviewed it. Because both server and domain isolation scenarios exist within Microsoft's global internal network, Microsoft's business depends on the security of these solutions. Furthermore, in recommending these solutions to its customers, Microsoft supports the long-term direction they take toward a highly secure and manageable infrastructure for trustworthy computing.
Who Should Read This Guide This guide is designed to support a server and domain isolation solution through all stages of the IT lifecycle, starting at the initial evaluation and approval phase and continuing through to deployment, testing, and management of the completed implementation. For this reason, the various chapters that comprise this guide have been written to meet the needs of a variety of readers. This chapter is designed primarily for the business decision maker who is trying to determine whether his organization will benefit from a server and domain isolation project. Understanding the contents of this chapter requires no specific technical knowledge beyond the comprehension of the organization's business and security needs. The planning chapters of this guide (Chapters 2, 3, and 4) are intended to be most helpful to the technical architects and IT professionals who will be responsible for designing a
Chapter 1: Introduction to Server and Domain Isolation
3
customized solution for an organization. A good level of technical understanding of both the technologies involved and the organization's current infrastructure is required to get the most benefit from these chapters. Chapter 5 and the appendices are designed for the support staff that is responsible for creating the deployment plans for the organization's solution. Included in this guidance are a number of recommendations about the process of completing a successful solution deployment as well as practical implementation steps to create the test lab environment. Chapter 6 of the guide is intended as a reference for the staff that is responsible for the day-to-day operations of the solution after it is implemented and fully operational. A number of operating processes and procedures highlighted in this chapter should be built into the organization's operations framework. Chapter 7 provides information about troubleshooting an IPsec deployment. Because IPsec fundamentally affects network communications, troubleshooting information and techniques can significantly help organizations that choose to implement IPsec.
The Business Challenge The nature of today's highly-connected organizations and mobile network devices can introduce many risks into your organization's IT infrastructure. These risks can come from a variety of sources, including mobile employee, vendor, and customer computers, in addition to remote computers in small branch offices or in employees' homes. In many cases, these risks come from malicious software (also known as malware), such as viruses and worms, that has been inadvertently downloaded or installed onto an innocent person's computer. Although logical isolation cannot be considered an antivirus defense on its own, it can be part of a broader antivirus solution, because it provides an additional layer of security that can reduce the likelihood of an attack and minimize its scope should one occur. For example, a visiting customer who connects a mobile computer to your network to provide you with a spreadsheet introduces a risk to your organization's IT infrastructure. By connecting directly to your physical network, the customer has bypassed any perimeter defenses that are in place to protect against network-based attacks. If the internal network to which the customer connects did not allow direct access to your organization's servers, however, this risk would be mitigated. The question is how to limit such access to the organization's resources to only those computers that need it. The answer is server and domain isolation, a technique that identifies and authenticates the computer itself to determine which resources it is allowed to access. The authentication occurs before the user logs on and is effective while the computer is connected. This approach makes it possible to reduce the potential risk to important business data from unidentified and unmanaged computers that connect to your network. Note For more information about malware and specific ways that your organization can defend itself, see The Antivirus Defense-in-Depth Guide.
The Business Benefits The benefits of introducing a logical isolation defense layer include the following: •
Additional security. A logical isolation defense layer provides additional security for all managed computers on the network.
•
Tighter control of who can access specific information. By using this solution, computers will not automatically gain access to all network resources simply by connecting to the network.
4
Server and Domain Isolation Using IPsec and Group Policy
•
Lower cost. This solution is typically far less expensive to implement than a physical isolation solution.
•
Increase in the number of managed computers. If an organization's information is only available to managed computers, all devices will have to become managed systems to provide access to their users.
•
Improved levels of protection against malware attacks. The isolation solution will significantly restrict the ability of an untrusted computer to access trusted resources. For this reason, a malware attack from an untrusted computer will fail because the connection will not be allowed, even if the attacker obtains a valid user name and password.
•
A mechanism to encrypt network data. Logical isolation makes it possible to require encryption of all network traffic between selected computers.
•
Rapid emergency isolation. This solution provides a mechanism to quickly and efficiently isolate specific resources inside your network in the event of an attack.
•
Protect publicly available network connections. Certain network connection points, such as those in a lobby, will not provide direct access to all resources on your network.
•
Improved auditing. This solution provides a way to log and audit network access by managed resources.
The Technology Challenge Defending a modern IT infrastructure from attackers while simultaneously allowing employees to work in the most agile and productive manner is not an easy task. Simply understanding the wide range of technologies that can help secure an environment is difficult enough for many people. It might help to see exactly where the solution fits within a typical IT infrastructure and how it is designed to complement existing network defenses.
Chapter 1: Introduction to Server and Domain Isolation
5
The following figure, which shows a typical network infrastructure consisting of a number of network defense layers, illustrates where logical isolation fits within a typical environment:
Figure 1.1 Infrastructure areas and network defense layers Figure 1.1 is designed to provide a simple illustration of the various technologies that you can use to provide a defense-in-depth security design for a typical network infrastructure. Such an infrastructure is typically made up of the following elements: •
Remote workers and networks. These remote entities typically use VPNs to connect to the organization's internal network and access the organization's IT infrastructure.
•
Internet. The organization's internal network is often connected to the Internet through one or more perimeter firewall devices. These devices often reside in a perimeter network that provides a higher level of protection from the external threats that Internet connectivity poses.
•
Perimeter network. This network is specifically set aside for servers and devices that require direct access to or from the Internet, which means they are exposed to higher risk of attack.
•
Internal network. Typically, this network represents the grouping of the organization's networks that are physically located on the sites owned and managed as part of the IT infrastructure.
6
Server and Domain Isolation Using IPsec and Group Policy
•
Quarantine network. This network is a relatively new component that provides limited connectivity to computers that fail to meet the minimum required security standards that the organization prescribes. After successfully passing the necessary tests, the computer and user will be authorized for full connectivity to the internal network. If they fail to pass the tests, the quarantine network will provide them with enough connectivity to download and install the required elements that will allow them to pass the tests. Microsoft provides new capabilities for quarantining remote access computers using Network Access Protection (NAP). For more information, see the Network Access Protection page.
•
Partner networks. Because these networks are not owned or managed by the organization, a highly controlled level of access is usually granted to allow specific business applications or processes to occur through a VPN tunnel or perimeter router that provides extranet communications.
Figure 1.1 illustrates that logical isolation is focused directly on the communications of internal network hosts. VPNs are managed by Remote Access Services (RAS) to allow traffic from remote workers or networks to connect securely from remote locations. Network edge firewalls protect communications between the Internet and the internal networks. RAS in combination with NAP provides the functionality to manage remote worker connections using a quarantine network. Currently, these various network defenses are typically installed and managed as separate components of a defense-in-depth network design. However, over the next few years these components will likely converge into a common network defense solution that can be implemented and managed as a single end-to-end solution. What is missing in many current network designs is the ability to protect computers on the internal network from one another. Large internal networks sometimes support many organizations, and in some cases multiple IT departments must manage the computers and physical access points. Consequently, you should not view the internal network as simply one network where all physically connected computers are trusted to have full network access to one another. The goal of logical isolation is to allow the internal network to be segmented and isolated to support a higher level of security without requiring hard physical boundaries. The real technology challenge with logical isolation is implementing it in a manner that is both manageable and scalable for your organization. Producing a design that is so complex and restrictive that it impairs users' abilities to perform necessary business tasks could be worse than having no isolation solution at all. It is essential that you complete appropriate planning and testing both before and during the solution deployment. This guide makes it possible to design a solution that is both scalable and manageable and that can also be deployed in a manner that is controlled and allows for testing at various points in the deployment phase. After logical isolation has been achieved, the additional layer of security will help reduce the risk to the various information assets on the network without restricting the functionality of authorized clients.
Creating a Project Team This solution will potentially affect all areas of the organization's internal network communications, which will in turn affect all departments and users that rely on these communications. For this reason, it is vital that all the needs and expectations of the organization are communicated, documented, understood, and considered at all stages of this project.
Chapter 1: Introduction to Server and Domain Isolation
7
Because it is not realistic to expect a single person to be able to perform all the tasks required in a project of this scope in a typical organization, a project team is recommended. This project team should consist of representatives from all departments within the organization in addition to the key technical areas of the current IT infrastructure. Because it is beyond the scope of this guide to explain how a project team should work within your organization, it is assumed that a suitable project team will be in place during the lifetime of this project and that the requirements and goals of the solution will be adequately communicated to the project stakeholders and solution users at various stages of the project. For more information about how to organize a project such as this, see the Microsoft Solutions Framework (MSF) web site.
Guide Overview This section provides a brief synopsis of the contents of each chapter in the Server and Domain Isolation Using IPsec and Group Policy guide.
Chapter 1: Introduction to Server and Domain Isolation The first chapter (this chapter) provides an executive summary and a brief introduction to the content of each chapter in the guide. It introduces the concept of logical isolation and the server and domain isolation approaches for an organization, discusses business justification, and shows how they fit in a typical IT infrastructure. This chapter also provides information about the Woodgrove National Bank scenario, which was adopted for proof-of-concept, design, and testing purposes.
Chapter 2: Understanding Server and Domain Isolation Chapter 2 defines the concept of trusted hosts and discusses how trust can be used to create domain or server isolation solutions. It explores the relationship between the concept of server and domain isolation, IPsec, and Group Policy. The technical content of this guide provides a detailed technical explanation of what can be expected from the solution in terms of both the security threats it will help defend against and the technical issues that could be faced when using IPsec to create a domain or server isolation solution.
Chapter 3: Determining the Current State of Your IT Infrastructure Before a project is undertaken, it is imperative that the designers of the solution have upto-date and accurate information about the current IT infrastructure. This information includes the current state of all network devices, server and workstation configurations, and domain trusts. It also covers the potential impact of other networking technologies, such as NAT, IPsec-based remote access VPN clients, internal firewalls and proxies, and internal port-based filtering. This chapter provides guidance on the information that is required for planning, along with the steps required to obtain the information.
8
Server and Domain Isolation Using IPsec and Group Policy
Chapter 4: Designing and Planning Isolation Groups This chapter provides guidance on how to link the business requirements of the organization to the server and domain isolation design that will help achieve the requirements. A step-by-step approach is provided to help you create an isolation group design to achieve your organization's security requirements with regard to isolation. This chapter also describes different deployment approaches that you can use to help minimize the impact on the organization during deployment and to help maximize the chances of a successful implementation. All of the steps and processes in this chapter are illustrated with examples from the Woodgrove Bank scenario.
Chapter 5: Creating IPsec Policies for Isolation Groups IPsec policy is the mechanism that you use to enforce the rules by which each computer communicates with its peers. These rules are assigned and delivered to members of the trusted domain using Group Policy objects. This chapter provides the information required to understand how to create these IPsec policies and how to deploy them to the recipient computers.
Chapter 6: Managing a Server and Domain Isolation Environment After the solution is in place and operational, there are a number of processes that you should understand and document to help ensure that the solution is managed correctly and supported on a day-to-day basis. This chapter presents a model for supportability and various management processes and procedures that you should use as part of a broader operations framework such as the Microsoft Operations Framework (MOF). For more information about MOF, see the Microsoft Operations Framework web site.
Chapter 7: Troubleshooting IPsec As the solution is deployed and used, it is almost inevitable that problems will arise. This chapter details a number of IPsec troubleshooting procedures, tasks, tools, and tips that you can use to help identify whether IPsec is the cause of such problems and, if it is, how to troubleshoot the problem.
Appendices In addition to the main chapters, this guide includes a number of reference materials, job aids, and scripts that were used in the planning, testing and deployment of the test lab environment at Microsoft during the development of this guide. You can use the information in these appendices to help in the implementation of your own server and domain isolation solutions. The materials provided here are designed to be of assistance in all phases of the project, from the initial envisioning right through to the day-to-day operations of a fully-deployed solution.
Chapter 1: Introduction to Server and Domain Isolation
9
Scenario Outline Both the server and domain isolation solutions have been deployed internally within Microsoft's internal network. However, a representative physical lab implementation was tested based on the Woodgrove Bank customer scenario to provide a concrete and public model for this solution. The business and technical requirements of this fictitious organization, in addition to those of Microsoft, were used to develop this solution. This guidance incorporates many of the support and management techniques that Microsoft internal IT administrators use routinely. However, the guide makes special note where Woodgrove Bank requirements and staffing may differ from Microsoft's unique considerations.
What Is Woodgrove Bank? Woodgrove National Bank is a fictitious proof-of-concept organization that Microsoft uses to provide a tangible customer example for demonstrating public deployment guidance. The requirements of Woodgrove Bank are derived from the many experiences that Microsoft has had with enterprise customers. As a bank, the Woodgrove organization is highly reliant on security to ensure the safety of both their monetary assets and their customers' private data. Woodgrove Bank also must comply with a number of regulatory requirements from government and industry groups. Specific legislative and regulatory requirements are not discussed here to avoid making the solution specific to one country or region. Woodgrove Bank is a leading global investment bank that serves institutional, corporate, government, and individual clients in its role as a financial intermediary. Its business includes securities underwriting, sales and trading, financial advisory services, investment research, venture capital, and brokerage services for financial institutions. Woodgrove Bank is a fully owned subsidiary of WG Holding Company, which is a leading global financial services company headquartered in London, England. WG owns five companies: Woodgrove National Bank, Northwind Trading, Contoso, Ltd., Litware Financials, and Humongous Insurance. All of the companies owned by WG are large organizations, each employing more than 5,000 people.
Geographical Profile Woodgrove Bank employs more than 15,000 people in more than 60 offices worldwide. They have corporate headquarters (hub locations) with large numbers of employees in New York (5,000 employees), London (5,200 employees), and Tokyo (500 employees). Each hub location supports a number of small, secondary sites. (For example, New York supports sites in Boston and Atlanta.) In addition to the hub locations, there are two other primary corporate locations, Sydney and Johannesburg, each with its own dedicated file, print, and application servers.
Connectivity Between Sites Tokyo and London are connected to enterprise headquarters in New York through private Internet connections, with committed bandwidth of 6 megabits per second (Mbps) and 10 Mbps connectivity, respectively. All regional hub locations are connected to enterprise headquarters with 2-megabyte (MB) to 10-MB connectivity. The autonomous branch locations have 2-MB connectivity. The micro branch offices typically have 1-MB wide area network (WAN) connectivity. The details of this connectivity are illustrated in Figure 3.1 of Chapter 3, "Determining the Current State of Your IT Infrastructure," in this guide.
10
Server and Domain Isolation Using IPsec and Group Policy
Enterprise IT Challenges Woodgrove Bank faces the same challenges that most enterprises do; they want to increase revenue and reduce costs while decreasing the cost of fixed assets. These challenges have an ongoing affect on IT. Woodgrove Bank has a number of additional corporate initiatives that also affect IT, including the following: •
Diversify into new markets through mergers and acquisitions
•
Exceed customer satisfaction
•
Improve employee productivity
•
Improve processes and operations
•
Provide a secure environment
Not only do these initiatives affect IT, there are additional specific challenges that IT decision makers face, including the following: •
•
Reduce the overall cost of IT •
Reduce operational costs; improve manageability and reduce the cost of management; reduce the number of servers in the environment; and consolidate heterogeneous applications and services onto single servers
•
Capitalize on existing IT investments
•
Create an agile IT infrastructure
Increase the return on investment •
Increase utilization
•
Improve availability and reliability
•
Exploit new hardware platforms
•
Ensure that employees, partners, and customers operate in the most secure environment
•
Deliver the ability to have service level agreements (internally and externally)
•
Increase business agility by providing meaningful real-time access to information from everywhere
IT Organization Profile Although Woodgrove Bank has a mixed server environment that uses Windows and UNIX, their infrastructure runs on a Windows Server backbone. They have a total of 1,712 Windows-based servers, most of which are running Windows 2000 or later: •
File and print servers
785
•
Web servers
123
•
Infrastructure servers
476
•
Microsoft Exchange servers
98
•
Microsoft SQL Server™ servers 73
•
Development servers
73
•
Monitoring servers
33
•
Other (Lotus Notes, Oracle)
51
Chapter 1: Introduction to Server and Domain Isolation
11
The majority of servers are located in the three corporate headquarter locations (New York, London, and Tokyo).
PC Environment Most employees at Woodgrove Bank have at least one personal computer system. Most employees have desktop PCs, and sales representatives have mobile computers. In total, Woodgrove Bank has more than 17,000 end-user PCs. Approximately 85 percent of those PCs are desktop computers, and 15 percent are mobile computers. More than 95 percent of the end user PCs are Intel-based PCs running some version of Windows. There are some Mac workstations and a few UNIX workstations being used by specific departments for Line of Business (LOB) applications.
System and Management Architecture Overview The Woodgrove Bank network consists of several IT zones: one corporate data center, two hub locations, two satellite offices, and a perimeter network to support remote users. As illustrated in the following diagram, Woodgrove Bank implements a centralized management model to manage servers and desktops centrally from New York City.
Figure 1.2 The Woodgrove Bank centralized IT management model
12
Server and Domain Isolation Using IPsec and Group Policy
Directory Service Woodgrove Bank elected to adopt a service provider forest model for their Active Directory design. The reason was that this model provides the flexibility of having one forest for the perimeter and a separate shared forest for internal resources. This capability meets the isolation requirements of the servers in the perimeter network. Woodgrove did not choose the single forest model because it does not allow the perimeter servers to be isolated from critical corporate data. The following figure illustrates the Active Directory logical structure that Woodgrove Bank uses:
Figure 1.3 The Woodgrove Bank directory service design The perimeter forest uses the single forest domain model, which is sufficient for management of perimeter servers. Replication requirements are minimal in the perimeter, so there is no need to provide replication boundaries or use the multiple regional domain model to segment the forest. It is crucial to note that Woodgrove chose this design for management of the perimeter servers only. If user accounts were placed in the perimeter and the perimeter was in multiple locations, a different domain design would have been required. The internal forest is based on a multiple regional domain model. Woodgrove created three regional domains: Americas, Europe, and Asia. In addition, Woodgrove implemented a dedicated forest root to manage the forest level functionality. This model provides a means of managing the replication topology as well as delegating administration of domain level autonomy to each region. Site topology for Woodgrove Bank is divided into three regional areas: Americas, Europe, and Asia (Asia Pacific). New York, London, and Tokyo are the central hubs to the entire topology. The designers at Woodgrove Bank chose to go with an organizational unit (OU) design that is primarily object-based. The OU structure is replicated in its entirety in each of the regional domains, and a subset of the OU structure is created in the forest root. Figure 3.2 in Chapter 3 of this guide provides a detailed diagram of the OU structure that Woodgrove Bank uses.
Chapter 1: Introduction to Server and Domain Isolation
Woodgrove Strategy for Server and Domain Isolation Rollout To help the organization understand the design that best meets their requirements, Woodgrove Bank created a proof-of-concept lab project. This project used a small lab implementation in which to test Woodgrove's proposed design, which is shown in the following figure.
Figure 1.4 Woodgrove Bank pilot design This diagram shows the subset of computers that were used in the Woodgrove Bank scenario to test the scenarios that this guide presents. The goal of the proof-of-concept project was to provide enough diversity in the lab design to ensure that the solution functioned as expected, while avoiding impact to production servers and the company users.
13
14
Server and Domain Isolation Using IPsec and Group Policy
The examples provided throughout this guide are based on the findings of the pilot design infrastructure illustrated in Figure 1.4. Note Because isolation changes many aspects of computer networking, Microsoft strongly recommends testing each isolation scenario in a lab environment first to avoid impact to production environments. IT administrators should review chapters 6 and 7 for supportability issues, operational procedures, and troubleshooting.
After a successful lab implementation project, a group of servers were identified to implement a basic server isolation scenario. These servers are ones that have low business impact if connectivity is affected. The IT administrators and support staff were trained in troubleshooting techniques. These servers were carefully monitored for performance and support call impact. Organizational management roles, processes, and support methods were tested. Next, one of Woodgrove's smaller domains was chosen to pilot domain isolation. The impact of this domain-isolation project was minimized by using IPsec only for the network subnets where most of the domain members were located. Impact was further reduced by allowing non-IPsec communication when these domain members communicated with other computers not involved in the pilot. After completing these pilots, the project team had all the information it needed to create and implement a complete design for the entire organization.
Summary This chapter provided an introduction to logical isolation and explained how server and domain isolation can be used to create an enterprise level solution using IPsec and Group Policy. In addition, this chapter provided an executive overview and a brief description of each chapter within this guide. From this information it is possible to understand what this solution will provide to your organization, where it will fit within a typical IT infrastructure, and what skills will be required to make the solution a success.
Chapter 2: Understanding Ser ver and Domain Isolation In the time since local area networks (LANs) became prevalent, information technology (IT) professionals have struggled to provide resilient, highly available services while maintaining adequate security. Many different technologies have been introduced to work with TCP/IP to address the issue of implementing security at the network and transport layers. These technologies include IPv6, 802.1X, network switches, virtual LAN (VLAN) segmentation, Internet Protocol security (IPsec), and many more. The unintentional result of the introduction of these technologies is a multi-layered approach to network security. These layers can be used to separate, segment, or isolate one or more hosts or networks from other hosts or networks. The purpose of this chapter is to organize the layer of security that IPsec provides with respect to other layers and explain how it is used with Group Policy in a solution that will achieve isolation in a manageable and scalable manner in an enterprise-class environment.
Chapter Prerequisites Before using the information provided within this chapter, you should be completely familiar with the following concepts and technologies. Although you might benefit from this guidance without meeting these prerequisites, a successful implementation will be far more likely if you meet all these prerequisites.
Knowledge Prerequisites Familiarity with Microsoft® Windows Server™ 2003 is required in the following areas: •
Active Directory® directory service concepts (including Active Directory structure and tools; manipulating users, groups, and other Active Directory objects; and use of Group Policy).
•
Authentication concepts including use of the Kerberos version 5 protocol and public key infrastructure (PKI).
•
Microsoft Windows® system security; security concepts such as users, groups, auditing, and access control lists (ACL); the use of security templates; mutual authentication concepts; standard name resolution methods and concepts such as Domain Name System (DNS) and Windows Internet Naming Service (WINS); standard Windows diagnosis tools and troubleshooting concepts; and using Group Policy or command-line tools to apply security templates.
•
Knowledge of TCP/IP concepts, including subnet layout, network masking, and routing. Also, knowledge of low-level functionality, protocols, and terms such as Internet Control Message Protocol (ICMP), Address Resolution Protocol (ARP), and Maximum Transmission Unit (MTU).
•
Knowledge of security risk management principles.
Note Chapter 6, "Deploying IPsec," of the Windows Server 2003 Deployment Kit discusses certain scenarios for IPsec transport mode that were not recommended at the time. However, the work that Microsoft has done for its own internal deployment of IPsec, along with the availability of additional guidance, means that the recommendation can now be changed.
While multicast and broadcast traffic still cannot use IPsec, all types of unicast IP traffic should be able to be secured with IPsec. Each customer must evaluate the benefits of deploying IPsec in domain or server isolation scenarios against the costs, impact, and other tradeoffs. However, Microsoft now recommends and supports the wider use of IPsec on customer networks in accordance with this guidance.
Organizational Prerequisites Planning the security for an organization is unlikely to be the responsibility of a single individual. The information that is necessary to determine the exact requirements for an organization will often come from a number of sources within the organization. You should consult with other people in your organization who may need to be involved in the isolation planning, including those people who perform the following roles: •
Business sponsors
•
User group representatives
•
Security and audit personnel
•
Risk management group
•
Active Directory engineering, administration, and operations personnel
•
DNS, Web server, and network engineering, administration and operations personnel
Note Depending on the structure of your IT organization, these roles may be filled by several different people, or fewer people may span several roles.
The scope of a server and domain isolation project requires a comprehensive team to understand the business requirements, technical issues, user impact, and the overall project process. It is often beneficial to have a high-profile individual who can act as the primary point of contact for this project when wider input is required, such as with the support staff or the users who will be affected during the deployment. Two leading causes of failure in complex projects are poor planning and poor communications. The project team must understand these potential risks and ensure that steps are taken to mitigate them.
Who Should Read This Chapter This chapter is designed for technical decision makers and technical architects who will be responsible for designing a customized server and domain isolation solution for an organization. Technical understanding of both the technologies involved and the organization's current infrastructure is required to obtain the greatest benefit from this chapter.
Chapter 2: Understanding Server and Domain Isolation
17
Business Requirements It is important to understand that the business requirements of your organization should drive the solution. Isolation is defined as a logical or physical separation of one or more computers from network communication with other computers. Security restrictions will always have an impact on the day-to-day operations of employees within an organization. The changes introduced as part of the solution will alter the way that computers in the domain communicate with one another and with untrusted computers. This solution will require time for a project team to plan and investigate feasibility and will also require training of IT support staff and the provision of, at least, a minimal employee awareness program. The additional security services being provided for network traffic may also require additional server memory or hardware acceleration network cards in some cases. Also, other solutions may be available to accomplish the same or similar isolation goals. Therefore, it is important to assess the monetary value that the solution is intended to deliver to the business.
Ensuring Regulatory Compliance As more personal information is stored on computers, the focus on data privacy has also increased. Controlling access to customer and employee information is no longer just good business practice. Depending on the local laws for the countries in which it operates, an organization that fails to protect confidential information can be open to significant financial and legal liability. For example, organizations that operate in the United States may need to meet the requirements of one or more of the following regulations: •
Federal Information Security Management Act (FISMA)
•
Sarbanes-Oxley Public Company Accounting Reform and Investor Protection Act
•
Gramm-Leach-Bliley Financial Services Modernization Act (GLBA)
•
The Health Insurance Portability and Accountability Act (HIPAA)
HIPAA has a security rule that specifies strict guidelines about how healthcare organizations must handle electronic personal healthcare information (ePHI). Although HIPAA does not mandate or recommend specific technology, it does specify what capabilities are required for compliance and how to mitigate risks to ePHI. You should evaluate the use of domain or server isolation with IPsec protection as a technical safeguard to help address requirements of the following HIPAA sections: •
Access control 164.312(a)(1) by protecting inbound network access to trusted computers using Group Policy authorizations, and to use encryption to protect EPHI from disclosure in network traffic.
•
Audit controls 164.312(b) by auditing which computers communicate with one another.
•
Integrity 164.312(c)(1) by restricting inbound network access to computers that have ePHI to only a specific group of authorized and trusted computers and users. Also, by preventing alteration of ePHI during network transmission by providing integrity and authenticity for all network packets in application connections.
•
Person or entity authentication 164.312(d) by requiring authentication and authorization of trusted computers for inbound network access to other trusted computers.
•
Transmission security 164.312(e)(1) by providing authenticity, integrity, and encryption.
18
Server and Domain Isolation Using IPsec and Group Policy
Frequently, you can meet these requirements by using Secure Sockets Layer (SSL) and Transport Layer Security (TLS). For example, applications can use Microsoft .NET technology with SSL/TLS to help meet HIPAA security regulations. See the white paper "Healthcare Without Boundaries: Integration Technology for the New Healthcare Economy". However, application communications must properly integrate SSL/TLS usage and algorithm controls. The main advantages of an IPsec isolation solution are that it protects all applications as well as the host computer operating system and can provide network traffic security for existing applications without changing them. For more details, see the "Comparison of SSL/TLS and IPsec" section later in this chapter.
Compliance of This Solution with U.S Government Regulations On December 16, 2003, the U.S. Office of Management and Budget (OMB) released a memorandum on the subject of "E-Authentication Guidance for Federal Agencies," which is available as a PDF file format. This memorandum specifies that the level of risk of an authentication compromise corresponds to the level at which electronic authentication (eauthentication) is required. NIST Special Publication 800-63, "Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology," identifies the technical requirements of authentication levels 1-4. In many cases, strong levels (3 and 4) of user authentication require applications to be rewritten or replaced. If the overall security risks can be reduced, you can use a less costly level of user authentication for access to highly sensitive information. On the Windows platform, server and domain isolation solutions add an initial layer of trusted computer authentication, access controls, network traffic authentication, and encryption prior to user authentication at the application layer. Thus, using a server and domain isolation solution might reduce or delay the requirement for application changes and help comply with risk management mandates. To enable compliance with government regulations for information assurance products, Microsoft is committed to several certification processes. Windows 2000, Windows XP with SP2, and Windows Server 2003 with SP1 have been certified to meet the Common Criteria for IT Security Evaluation (ISO Standard 15408) evaluation assurance level 4 (EAL4) augmented with ALC_FLR.3 Systematic Flaw Remediation. This certification applies to both the operating system and sensitive data protection categories. Also, Windows 2000, Windows XP, and Windows Server 2003 IPsec cryptographic components have been certified to meet FIPS 140-1 cryptographic requirements. Thus, server and domain isolation solutions can be used in military, government, and related IT environments. For more information, see the following links: •
National Information Assurance Acquisition Partnership
•
Overview: Windows 2000 Common Criteria Certification
•
FIPS 140 Evaluation
The information that this section provides is specific to organizations operating in the United States. However, related regulation is emerging all over the world, as demonstrated by statutes such as the European Union Data Protection Directive of 1998 and Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), both of which impose strict guidelines regarding identity management and data privacy.
Chapter 2: Understanding Server and Domain Isolation
19
Business Risk Assessments of IT Infrastructure Business risk assessments should identify how the business is dependent on the IT infrastructure. An IT security risk assessment should identify and prioritize risks to the integrity of information and stability of services. The security risk assessment should provide clear justification for why these risks must be addressed and should estimate the costs associated with not addressing the risks. The cost estimates are extremely important for evaluating different technical solutions for each problem. Because no single solution will address 100 percent of the risk, compare each solution against the others and their associated costs. Decision makers may want to evaluate the cost of an isolation solution in terms of how it will reduce the risk of degraded or lost service due to network propagation of virus and worm infections. For some organizations, the business impact and costs of a successful hacker attack against their high-value data are of more concern. Note In some countries and states, laws require that all security breaches be reported to customers that may be affected. Refer to your local government agencies or legal counsel for specific legislative issues that pertain to your organization.
Consider the following categories as a guide for estimating the total cost of a security incident: •
•
•
•
Cost incurred by loss of service. To determine the total cost incurred by the loss of service on a network server, add together the individual cost of each of the following: •
Incident response time required by support personnel
•
Lost revenue due to application service interruption
•
Lost internal productivity
Cost incurred by theft of information. To determine the total cost incurred by the theft of information from an internal network server, add together the individual cost of each of the following: •
Loss of intellectual property required to develop information
•
Loss of future revenue across all products due to customer mistrust, if the theft is publicized
•
Loss in market value due to investor mistrust, if the theft is publicized
•
Internal response time required by marketing and development
•
Loss of revenue opportunity due to internal response effort
•
Time required to mitigate the malicious use of information against business, employees, or customers by outsiders
Cost incurred by compromise of administrative credentials on the server. To determine the total cost incurred by the compromise of administrative credentials on an internal network server, add together the individual cost of each of the following: •
Internal effort required to respond to the attack and replace the server
•
Internal mitigation of attacks on other computers that were made possible by the compromise of administrative credentials on the server
Cost incurred by subsequent legal or regulatory action. To determine the total cost incurred by the requirement for subsequent legal action, add together the individual costs of each of the following: •
Cost of legal action if the attacker can be identified but your company loses the court decision
20
Server and Domain Isolation Using IPsec and Group Policy
•
Cost of legal action if the attacker can be identified and your company wins the court decision, but the defendant cannot pay the court-awarded damages
•
Cost of regulatory fines, audits, restrictions, and other good faith efforts to reestablish current business environment
Invest in Long-Term Directions for Information Security The Microsoft Network Access Protection (NAP) initiative establishes the long term direction to firmly control policy compliance of devices connecting to the network and to one another. Remote access quarantine and server and domain isolation are two parts of this direction that can be implemented now with current Windows 2000 and later platforms. By combining both perimeter and internal isolation capabilities, the organization has significant defenses against infection and other attacks from untrusted computers and from compromised user credentials. For more information about the NAP initiative, see the Network Access Protection Web site. For more information about virtual private networking (VPN) and quarantine access controls, see the Virtual Private Networks Web site. In future releases of Windows, Microsoft plans to deliver more manageable and comprehensive network access protection. For more information, see the "Introduction to Network Access Protection" white paper.
Identifying Trusted Computers A discussion of trust and how it relates to computers is an important part of the topic of server and domain isolation. At its core, isolation is the ability for any particular trusted host to decide who can have network-level access to it. Thus, regardless of how the remote computers are connected at the remote end of the connection (for example, wireless, LAN, Internet), the remote computer must use IPsec to negotiate trust and to secure TCP/IP traffic end-to-end with the destination computer. This end-to-end security model provides a level of protection of network communications that other link-based network access control and security technologies cannot (for example, VPN, 802.1x, 802.11 WEP). There is significant value in trusting the remote computer first to protect against stolen, compromised, or misused user credentials. In the context of this solution, trust is the ability for an organization to be reasonably assured that a particular computer is in a known state and that it meets the minimum security requirements that the organization has agreed on. These requirements can be technical in nature, security-focused, business-related, or any combination. These requirements also dictate the state that a computer should be in before establishing communications with other computers. Microsoft recommends that the specification for trusted computers includes a regularly updated list of security updates and service packs that are required. Ideally, you should manage and enforce these updates by using a patch management system such as the Windows Update Service or Microsoft Systems Management Server (SMS). How frequently these updates are applied will depend on the length of time your organization needs to test and deploy each update. However, for optimal security, you should apply updates as soon as is possible for your environment. Untrusted computers are computers that cannot be assured of meeting these security requirements. In general, a computer is considered untrusted if it is either unmanaged or unsecured.
Chapter 2: Understanding Server and Domain Isolation
21
The purpose of the server and domain isolation solution is to mitigate the risk posed to trusted resources by implementing tools, technologies, and processes that will safeguard the organization's assets. The solution ensures that: •
Only those computers that are considered trusted (those that meet specific security requirements) can access trusted resources.
•
Computers that are untrusted are denied access to trusted resources unless a specific business reason is identified to justify the risk.
You should allow trusted resources, by default, network-level access only from other trusted resources. In addition, control access at the network layer by using permit or deny permissions and ACLs for specific users and computers within the trusted environment. By creating this trusted environment and restricting the permitted communications inside and outside of this environment, the business can reduce the overall risk to its data assets. Additional business benefits may include: •
A high level of understanding of data flow across specific areas of the network.
•
Improved adoption of security programs that are used to obtain "trusted" status.
•
Creation of an up-to-date host and network device inventory.
For example, in the Woodgrove Bank scenario, trusted computers include all computers running Windows 2000 Service Pack (SP) 4, Windows XP SP2 or higher, or Windows Server 2003 or later in any of the domains that Woodgrove owns and manages. In addition, trusted assets, which include all computers running Windows 2000 or later that use Group Policy to provide security settings, are periodically examined by IT staff to ensure that they continue to meet the minimum requirements. IT also examines trusted assets to ensure that the installation and configuration of specialized security software (such as antivirus software) is centrally controlled according to Woodgrove's own security requirements. For more information about which computers are considered trusted within the context of the solution, see the "Trust Determination" section of Chapter 3, "Determining the Current State of Your IT Infrastructure," in this guide.
Unmanaged Computers An unmanaged computer is one whose security settings the IT department does not centrally control. In addition, a computer that does not provide the required security management capabilities is also considered unmanaged. Unmanaged computers are considered untrusted because the organization cannot be assured that they will meet the security requirements of the trusted computers they seek to access.
Unsecured Computers Untrusted computers also include those computers that use an operating system that has not or cannot be configured to the required level of security. Unsecured computers may fall into one of the following four groups: •
Low operating system security rating. This grouping applies to computers running an operating system that lacks the required security infrastructure rating. Such operating systems include Windows 9x, Microsoft Windows NT®, and Windows CE. Generally, the features required for the security infrastructure are found in more modern operating systems, such as Windows XP and Windows Server 2003. These features include access controls (for example, file permissions), the network security features of packet encryption and strong authentication and authorization, differing levels of privilege (user and administrative), support for central management of security settings, support for ensuring confidentiality and integrity of data, and support for other security technologies (such as the Kerberos authentication protocol and certificate services).
22
Server and Domain Isolation Using IPsec and Group Policy
•
Incorrectly configured. Even the most secure operating systems can be configured in a manner that will leave them open to an attack. Such computers must be considered to be unsecured devices.
•
Lacking the required level of updates. Because IT security is a constantly evolving area, most software vendors will issue software updates to ensure that the latest vulnerabilities are properly addressed. An organization might identify a minimum level of updates that a host must have to be considered trusted. In such a case, those computers that lack the updates would be considered unsecured devices.
•
Trusted computers that might have been compromised. It is possible that a trusted computer could be compromised, usually by a trusted attacker. When a trusted computer has been compromised, it is no longer considered trusted until some remediation effort has been performed on the computer to return it to a trusted state. It is important to understand that if you cannot trust the user of a computer, you cannot trust that computer.
Those devices that fall into one of these four groups are categorized as untrusted because the organization cannot be certain that they have not been compromised in some manner. Therefore, they represent a significant risk to the trusted computers that they attempt to access.
Goals Directly Achievable Using Server and Domain Isolation Overall, the goal of server and domain isolation is to mitigate the threat posed by unauthorized access to a trusted computer by an untrusted computer. With current platforms, the ability to isolate a remote computer by restricting inbound network access is based on the ability to successfully authenticate as a domain member computer using the IPsec Internet Key Exchange (IKE) security negotiation protocol. User authentication is involved only after successful computer authentication has been achieved and IPsec security associations protect all upper layer protocol and application connections between the two computers. Thus, you can achieve the following goals by using server and domain isolation: •
Isolate trusted domain member computers from untrusted devices at the network level.
•
Ensure that inbound network access to a trusted domain member on the internal network requires the use of another trusted domain member.
•
Allow trusted domain members to restrict inbound network access to a specific group of domain member computers.
•
Focus network attack risks on a smaller number of hosts, which provides a boundary to the trusted domain, where maximum risk mitigation strategies (such as logging, monitoring, and intrusion detection) can be applied more effectively.
•
Focus and prioritize proactive monitoring and compliance efforts prior to an attack.
•
Focus and accelerate remediation and recovery efforts before, during, and after an attack.
•
Improve security by adding strong per-packet mutual authentication, integrity, antireplay and encryption, without the need to change applications and upper layer protocols (such as server message block [SMB] or NetBT).
Server and domain isolation seeks to protect all network services on the trusted host from untrusted network access and attacks. Server and domain isolation makes hosts less vulnerable to weaknesses and mistakes in the other types of network-based security, and to weaknesses in user credential protection. Lastly, server and domain isolation solutions
Chapter 2: Understanding Server and Domain Isolation
23
address similar network threats but provide different levels of network access control and traffic protection than other types of network-based security technology. For example, a server and domain isolation solution can authorize inbound access for specific trusted host computers based on host and user domain identity, thus ensuring end-to-end protection for that authorized communication. Most network-based security technologies, however, only support the user identity.
Risks Addressed Using Server and Domain Isolation The number one risk that server and domain isolation addresses is the risk posed by unauthorized access to a trusted computer by an untrusted computer. Certain security risks cannot be mitigated fully using the solution alone. Failure to address these security risks with additional security processes and technology could ultimately negate the security benefits of the isolation solution. Examples of serious security risks that will not be directly mitigated by this solution include: •
The risk of trusted users stealing or disclosing sensitive data. Although the isolation solution can control where computers communicate within the internal network, administrative users can subvert these controls. It is not possible for this solution to eliminate the risk of trusted users inappropriately copying or disseminating sensitive data.
•
The risk of compromise of trusted user credentials. Although an administrator can choose to encrypt most traffic with IPsec to protect network logon information, IPsec protection of user logon traffic to domain controllers is not supported. Server and domain isolation can force an attacker to use a trusted host to attack other trusted hosts. An attacker may also attack trusted hosts by using compromised credentials from hosts that are exempted from using IPsec with trusted hosts (for example, domain controllers and DNS servers), or hosts that accept inbound connections from untrusted computers. Although an administrator can control whether trusted hosts communicate outbound to untrusted hosts, this solution cannot mitigate the risk of trusted users losing their credentials to an attacker who tricks them to reveal their passwords.
•
Rogue users. Legitimate users who abuse their access also fall into this category. For example, this solution cannot mitigate the risk of a disgruntled employee deciding to steal information using trusted hosts to which they have access because of their job role. Physical access to a trusted host computer can enable an attacker to gain unauthorized and administrative access to it. Because administrators can disable server and domain isolation protection, it is vital to limit the default scope of access and the number of administrators (including enterprise administrators, domain administrators, and local administrators on workstations or member servers).
•
The risk of untrusted computers accessing other untrusted computers. This solution cannot mitigate the risk of untrusted computers being used by an attacker to attack other untrusted computers.
•
The risk of untrusted computers attacking certain trusted computers. Server and domain isolation solutions are designed to protect trusted hosts. However, as a practical deployment matter, this solution identifies trusted domain members that for various reasons do not use IPsec to negotiate trusted access to other trusted hosts. These trusted, but non-IPsec enabled, computers are members of an exemption list (for example, domain controllers). Also, this solution identifies certain trusted hosts to be accessed by untrusted computers to provide boundary services for the isolation domain. An attacker who gains control of an exempted or boundary host can then attack all other trusted hosts inside the isolation domain.
24
•
Server and Domain Isolation Using IPsec and Group Policy
Assuring security compliance of trusted hosts. This solution suggests how trusted hosts might be defined and in particular requires that they be members of a Windows 2000 or Windows Server 2003 domain. This solution depends only upon successful IPsec IKE domain-based (Kerberos) authentication to establish trust and thus IPsec-protected connectivity. Over time trusted hosts may for various reasons not meet the full criteria of being a trusted host yet still be able to authenticate successfully as a domain member. It is the responsibility of the organization's IT management systems and processes to ensure that domain members comply with the definition of trusted hosts.
To address these issues, the recommended security hardening configurations and templates were applied to all systems in the Woodgrove lab environment. For more information about Windows platform security technologies and management procedures, see the TechNet Security Center.
How Does Server and Domain Isolation Fit into My Overall Network Security Strategy? Server and domain isolation is employed in addition to other proactive and reactive mechanisms to defend the network and its connected devices, including computers. Because security is a multi-faceted problem that requires multiple layers, it is helpful to review the concept of defense-in-depth and the high-level ideas behind it. A comprehensive network security strategy applies the appropriate technologies to mitigate the highest priority risks without significant dependence on single points of failure. For example, if perimeter security failed due to a misconfiguration or a malicious employee, what other layer of defense would stop network attacks and infections on internal trusted hosts? What stops attacks on all trusted hosts in Europe or Asia when the attacker connects to the Ethernet port in a conference room in any U.S. office?
Defense in Depth Defense in depth is best described as a layered approach to protecting a computer instead of reliance on a single mechanism for that protection. To successfully layer defenses, it is necessary to first understand the infection sources and adversaries who stand ready to attack an organization, as well as to have some idea what their targets might be. For example, an adversary could be a competitor who hires a corporate espionage firm to steal information about a new product or service that is under development. After gaining an understanding of the attackers and their possible targets, it is then necessary to apply incident response procedures for computers that could be compromised. These methods include authentication, authorization, confidentiality, and non-repudiation. An organization that follows the industry best practice of protect-detectreact realizes that attacks will occur and understands that detecting them quickly and minimizing service interruptions or loss of data is paramount. Practicing protect-detectreact makes it possible to recognize that because the probability of an attack is high, more effort should be spent on protecting data and assets rather than on preventing an attack from occurring. Generally speaking, it is more cost-effective to defend against an attack than it is to clean up after one has occurred. All information assurance mechanisms focus on people, processes, and technologies. Isolation involves all three of these areas: it is achieved through a thorough understanding of the risks, requirements, and assets that demand protection, an understanding that encompasses the people and process elements. In addition, isolation requires knowledge of the current state of the network and its devices, the
Chapter 2: Understanding Server and Domain Isolation
25
communication requirements that define how computers should interact with one another, and the security requirements that may limit those requirements to achieve the appropriate balance between security and communication. A more detailed discussion of this subject can be found in the U.S. National Security Agency's “Defense in Depth” white paper in PDF format. For information and practical design examples for this process, see the Enterprise Design chapter of the Security Architecture Blueprint within the Windows Server System Reference Architecture. The following figure illustrates how a logical isolation solution would fit into the defensein-depth approach used in the Windows Server System Reference Architecture:
Figure 2.1 Defense in depth with logical isolation One important point to understand from this figure is that the logical isolation layer of security is aimed directly at securing the host computer through controlling network communications. This role is most similar to that of a host-based firewall. However, instead of the host firewall providing permit and block services for ports, IPsec provides permit and block services and negotiates trusted network access services. After access is granted, IPsec can secure all packets between the two computers. As defined within the context of this solution, a "logical isolation" solution such as server and domain isolation: •
Does not secure network devices, such as routers.
•
Does not provide physical network access control, such as specifying which computer is allowed to establish a remote access VPN connection, or provide protections supplied by network-based firewalls.
•
Does not secure network links, such as 802.1x for access control and 802.11 WEP encryption for wireless links. However, IPsec does provide protection end-to-end across all network links in the path between source and destination Internet Protocol (IP) address.
26
Server and Domain Isolation Using IPsec and Group Policy
•
Does not provide security for all hosts on the network—only those participating in the isolation solution.
•
Does not secure application level paths, such as the end-to-end path through which e-mail and .NET messaging flows, and Hypertext Transmission Protocol (HTTP) requests that can be proxied several times between the client and the Web server destination.
You should consider security at each layer as part of IT security risk mitigation analysis. For example, if a certain computer is not allowed access to a server at the logical isolation layer, it does not matter which user logs on at that computer. Any users—even an administrator—will be denied access to the server.
Comparison of SSL/TLS and IPsec IPsec is not intended as a replacement for application level security, such as SSL/TLS. One of the advantages of using IPsec is that it can provide network traffic security for existing applications without having to change them. Using IPsec in environments in which applications use SSL/TLS can provide the following benefits: •
Help protect all applications and the operating system against network attacks by untrusted computers and other devices.
•
Establish a defense-in-depth approach against potential improper or non compliant use of SSL/TLS (for example, if all eHPI data is not encrypted and authenticated).
•
Help prevent user credentials from being entered into untrusted computers—because users are not prompted to log on to an internal SSL/TLS Web site until IPsec establishes mutual trust between client and server.
•
Provide security when you cannot use Windows registry settings to select regulatory compliant SSL/TLS algorithms. Windows 2000, Windows XP, and Windows Server 2003 provide registry key controls for SSL/TLS algorithms, which Microsoft Knowledge Base article 245030, "How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll," describes.
•
Provide security where certificates are not available.
IPsec secures traffic between source and destination IP addresses. SSL/TLS can secure traffic through the entire application path (for example, from a Web browser through a Web proxy to a Web server). The National Institute for Standards and Technology (NIST) is developing guidance on using TLS. Special Publication 800-52, "Guidelines on the Selection and Use of Transport Layer Security," is a guideline for implementing TLS in the federal government. For more information about this guidance, see the NIST Computer Security Division Web site. Similar guidelines do not exist for the use of IPsec. However, the U.S. National Security Agency has released guides for using Windows 2000 IPsec. These guides are available from the NSA Security Recommendation Guides download site. Organizations that need to meet NSA guidelines should evaluate the design of this solution in addition to the NSA guides. IPsec with certificate authentication provides protection that is similar to SSL/TLS, but there are some differences. Windows IPsec supports a small subset of the cryptographic algorithms supported by TLS and recommended by NIST 800-52 (for example, 3DES, SHA-1, and 1024-bit ephemeral Diffie-Hellman). The solution presented in this guide uses Kerberos protocol signatures for IKE authentication between domain members instead of certificate-based signatures. Windows IPsec IKE negotiation establishes mutual trust between computers using the Kerberos protocol and certificate-based authentication. Because IKE is not integrated with applications, it cannot verify that the destination computer name is the one to which the application is expected to connect,
Chapter 2: Understanding Server and Domain Isolation
27
thereby allowing a sophisticated man-in-the-middle attack from another trusted host. But because the application integrates with SSL/TLS, the destination name is not only authenticated (trusted), the name can also be verified against the name that was expected.
Terminology Refresher Before continuing with this chapter, it would be a good idea to review a number of the terms that are often used in the context of this solution. If you are already familiar with these terms, you can skip this section. However, if you do not understand these terms adequately, you may find that some of the explanations in this guide will be confusing.
Isolation Terms The following terms are unique to the concept of logical isolation. Ensure that you understand these terms fully before continuing with this chapter: •
Isolation. A logical separation of one or more computers from other computers.
•
Domain isolation. This term defines the type of isolation that separates trusted computers from untrusted computers. A computer need only present valid credentials and successfully authenticate with IKE to be isolated. The domain is any domain in the trust path that is accessible via a two-way trust between the two hosts that are attempting to secure their communications.
•
Server isolation. This term defines how servers can restrict inbound access using IPsec and the "Access This Computer From the Network" right to a specific group of trusted computers.
•
Logical isolation. The broader term for isolation technologies that can include Domain Isolation, Server Isolation, and Network Access Protection (NAP) to isolate computers at the network layer.
•
Isolation group. A logical grouping of trusted host computers that share the same communications security policy, essentially the same inbound and outbound network traffic requirements. You can implement an isolation group's inbound and outbound access controls by IPsec policy alone using permit/block actions, or with IPsec negotiating security in combination with Group Policy network logon rights (and potentially with other network configuration or connection settings). Individual applications, network services, and protocols should have a specified configuration to meet traffic requirements at their layer. For example, a group of Exchange servers require a client or server computer to be a trusted domain member in order to make an inbound TCP/IP connection. This group, which is not allowed to make outbound TCP/IP connections to non-domain members (with certain exceptions) would be called an Exchange Server isolation group.
•
Isolation domain. An isolation group where the membership in the group is the same as the membership of the Windows domain. If the domain has bidirectional trusted domains, members of those domains would be part of the isolation domain. As an isolation group, the inbound and outbound requirements are simple: Inbound connections can only be from other trusted host domain members. A server that is in a server isolation group might have clients that are part of the isolated domain.
•
Network access group. This term refers to the Windows domain security group that is used to control network access to a computer, by using Group Policy security settings for network logon rights. These are specifically created to enforce the inbound access requirements for isolation groups. For each isolation group, there may be an Allow network access group (ANAG) and a Deny network access group (DNAG).
28
Server and Domain Isolation Using IPsec and Group Policy
•
Trust. This term is used to define the fact that a computer is willing to accept the identity validated through the authentication process. Domain trust implies that all members of the domain trust the domain controller to establish identity and properly provide group membership information for that identity. Trust is necessary to communicate with a remote computer by using IPsec. Trust also means that a user or computer is considered to be an acceptable and presumably low risk with which to communicate.
•
Trustworthy host. This term is used to identify a computer that is capable of being configured to meet the organization's minimum security requirements but may or may not currently be a trusted host. Knowing which computers are trustworthy is important when planning the membership of any trusted isolation group.
•
Trusted host. This term refers to a platform computer running Windows 2000, Windows XP, or Windows Server 2003 that is at least a member of a Windows 2000 security domain and is capable of enforcing an IPsec policy. Trusted hosts are typically defined to meet certain additional management and security requirements. The configuration of the host is controlled such that the host's security risks are considered low and managed. Trusted hosts are less likely to be the source of an infection or malicious act. See Chapter 3, "Determining the Current State of Your IT Infrastructure," of this guide for detailed discussion of this topic.
•
Untrusted host. A host computer that is not a trusted host. This computer has an unknown or unmanaged configuration. There is little or no assurance that the host (or the user of the host) will not be the source of an infection or malicious act if it is connected to the network.
•
Boundary host. A trusted host that is exposed to network traffic from both trusted and untrusted hosts and therefore must have closer monitoring and stronger defenses against attacks than other trusted hosts. There should be as few boundary hosts as possible, because they represent a higher risk to the rest of the trusted hosts.
•
Exemption. A computer, either domain joined or not, which does not use IPsec. There are two types of exemptions. There are computers using a static IP address whose addresses are included in the IPsec policy "exemption list" so that trusted hosts do not use IPsec with these computers. And there are computers that are exempt from using IPsec policy to negotiate secured connections. The latter may or may not appear in the exemption list. An exemption may meet the requirements of a trusted host, but does not use IPsec protected communication with other trusted hosts in the isolation domain.
Security Terms Ensure that you thoroughly understand the following security-related terms: •
Authorization. The process of granting a person, computer, process, or device access to certain information, services, or functionality. Authorization is dependent on the identity of the person, computer, process, or device requesting access, which is verified through authentication.
•
Authentication. The process of validating the credentials of a person, computer process, or device. Authentication requires that the person, process, or device making the request provide a representation of credentials that proves it is what or who it says it is. Common forms of credentials are private keys for digital certificates, a secret configured administratively on two devices (preshared key), a secret password for user or computer domain logon, or a biological object such as a person's fingerprint or retina scan.
Chapter 2: Understanding Server and Domain Isolation
29
•
Spoofing. In this guide, spoofing is taken to mean the act of impersonating a legitimate IP address by an attacker in an attempt to disrupt communication or intercept data.
•
Nonrepudiation. A technique used to ensure that someone performing an action on a computer cannot falsely deny that they performed that action. Nonrepudiation provides sufficiently undeniable proof that a user or device took a specific action such as transferring money, authorizing a purchase, or sending a message.
•
Ciphertext. Data that has been encrypted. Ciphertext is the output of the encryption process and can be transformed back into a readable form plaintext by using the appropriate decryption key.
•
Plaintext (sometimes called cleartext). Communications and data in their unencrypted form.
•
Hash. A fixed-size result that is obtained by applying a one-way mathematical function (sometimes called a hash algorithm) to an arbitrary amount of input data. If there is a change in the input data, the hash changes. Hash functions are chosen so that there is an extremely low likelihood of two inputs producing the same output hash value. The hash can be used in many operations, including authentication and digital signing. Also called a message digest.
Network Terms The following terms refer to the network elements of this solution: •
Initiator. A computer that is starting a network communication with another computer.
•
Responder. A computer that replies to a request to communicate over the network.
•
Communication path. The connection path that is established for network traffic that passes between an initiator and a responder.
Group Policy Terms The following terms relate to Windows Group Policy: •
GPO. The Group Policy settings that you create are contained in a Group Policy object (GPO). By associating a GPO with selected Active Directory system containers—sites, domains, and organizational units (OUs)—you can apply the GPO's policy settings to the users and computers in those Active Directory containers. Use the Group Policy Object Editor to create an individual GPO and the Group Policy Management Console to manage GPOs across an enterprise.
•
Domain policy. A policy that is stored centrally in Active Directory.
•
Local policy. A policy that is stored on an individual computer.
Basic IPsec Terms Ensure that you thoroughly understand the following IPsec terms: •
IPsec policy. A group of security rules for processing network traffic at the IP layer. A security rule contains packet filters that are associated with a permit, block, or negotiate action. When negotiation is required, the IPsec policy contains authentication and security methods to negotiate with the peer computer.
30
Server and Domain Isolation Using IPsec and Group Policy
•
Persistent IPsec policy. A type of IPsec policy introduced in Windows XP and Windows Server 2003 that allows IPsec policy settings to be applied in a persistent manner. Persistent policy is applied first on IPsec service startup, so it overrides settings in local or domain IPsec policy.
•
IKE negotiation. This is the process that occurs at the start of a network connection to determine whether a computer using IPsec will allow the connection to occur.
•
Security associations (SA). The agreements that two hosts make about how to communicate using IPsec and the various parameters that define this negotiation. •
Main mode SA. These SAs are the first to be established during the IKE negotiation between the initiator and responder computers.
•
Quick mode SA. These SAs are negotiated after the main mode SA is established for each session of communication between the hosts.
•
Fall back to clear. This option allows an IKE initiator to allow normal TCP/IP traffic (not IKE or IPsec) if there is no IKE response from the responder. This is the Allow unsecured communication with non-IPSec-aware computer option on the filter action properties page of the IPsec Policy Management tool.
•
Inbound passthrough. This option allows an IPsec-enabled computer to accept a normal TCP/IP (not IKE or IPsec) inbound packet from a remote computer. The normal upper layer protocol response will be an outbound packet that then triggers an IKE initiation back to the remote computer. This is the Accept unsecured communication, but always respond using IPSec option on the filter action properties page of the IPsec Policy Management tool.
Note If you have Inbound passthrough enabled, but not Fall back to clear on a responder, the responder will not successfully communicate with a non-IPsec-aware initiator.
Additional terms are important to understand that refer to elements of IPsec specifically. Appendix A, "Overview of IPsec Policy Concepts," of this guide provides an overview of these IPsec terms and explains the overall IPsec process that the computers in the isolation groups created in this solution will use.
How Can Server and Domain Isolation Be Achieved? The concept of isolating computers from risk is not new. Techniques such as using firewalls to provide segmentation, applying access control and filtering to routers, and physically segmenting network traffic all provide a level of isolation. The solution presented in this guide is designed to work with the existing devices and techniques in your network infrastructure. The key point is that isolation is implemented by making changes to existing host software in Windows 2000 and later platforms. Technologies and procedures such as network segmentation, VLANs, perimeter network access controls, network quarantine, and network-based intrusion detection are achieved by implementing or changing the configuration of network devices. Server and domain isolation complement all of these existing techniques and provides a new protection level for managed Windows domain members. Windows IT administrators can implement server and domain isolation with little or no change in the existing network paths and connection methods, with little or no change to applications, and with an existing Windows 2000 or Windows Server 2003 domain infrastructure.
Chapter 2: Understanding Server and Domain Isolation
31
Server and Domain Isolation Components The server and domain isolation solution is made up of a number of important components that collectively enable the solution. The following subsections describe these components.
Trusted Hosts Trusted hosts are computers that the IT organization can manage to meet minimum security requirements. Very often, you can achieve this trusted status only if the computer is running a secure and managed operating system, antivirus software, and current application and operating system updates. After the computer is determined to be trusted, the next component of the solution is to confirm the computer's status through authentication. For more information about determining status, see Chapter 3, "Determining the Current State of Your IT Infrastructure." Note IPsec cannot make any determination of a computer's compliance to particular host criteria by itself. Monitoring technology will be required to determine the computer's baseline configuration and report any changes from that configuration.
Host Authentication The host authentication mechanism determines whether the computer attempting to initiate a session has a valid authentication credential, such as a credential from the Kerberos ticket, a certificate, or perhaps a preshared key. Currently there are two technologies that can provide this type of authentication mechanism on Windows-based computers. The following sections explain these two technologies.
The 802.1X Protocol 802.1X is a standards-based protocol for authenticating users and devices so that they can be authorized to gain connectivity through a link-layer network port, such as an 802.11 wireless link or an 802.3 Ethernet port. This allows for control of the user experience (for purposes such as billing), control of authorization, and additional features. This protocol requires one or more dedicated servers (for example, the Remote Authentication Dial-In User Service [RADIUS]) and a network infrastructure that supports the protocol. 802.1X is designed to provide controls over network access and cryptographic keys for 802.11 Wired Equivalent Privacy (WEP) encryption of wireless traffic between the client and wireless access point. After the device is granted network access, it typically has open connectivity to the rest of the internal network. After data is decrypted at the wireless access point, it is forwarded in normal plaintext TCP/IP form to the end destination, perhaps secured by various application-layer mechanisms. Woodgrove security requires protection of all trusted hosts from untrusted computers on the internal network. Although 802.1X could enforce that only trusted computers be granted access through wireless and some wired links, the switches used for most internal 802.3 Ethernet ports is not capable of 802.1X authentication. A significant hardware purchase and installation cost would be required to upgrade every physical LAN access wall port and all buildings worldwide. Thus, Woodgrove decided to use 802.1X for wireless security, but not for hard-wired Ethernet ports. Another Woodgrove security requirement was to encrypt traffic end-to-end between trusted clients and the encryption servers. 802.1X has not been developed to provide encryption for wired connections, only wireless. Even when wireless connections are encrypted, the data is not protected after packets are forwarded onto the internal LAN after decryption by the wireless access point. Consequently, 802.1X is not able to meet the end-to-end encryption requirement.
32
Server and Domain Isolation Using IPsec and Group Policy
Although 802.1X does not meet all of Woodgrove's security requirements, it is still used for wireless security. Microsoft recommends 802.1X to secure wireless networks and to provide access control for wired networks where possible. For more information about the use of 802.1X, see Wireless Networking.
IPsec IPsec is the IETF standard security protocol for the Internet Protocol. It provides a general, policy-based IP layer security mechanism that is ideal for providing host-by-host authentication. An IPsec policy is defined to have security rules and settings that control the flow of IP traffic inbound and outbound on a host. Policy can be managed centrally in Active Directory using Group Policy objects for policy assignment to domain members. IPsec provides that ability to establish secure communications between hosts. IPsec uses the Internet Key Exchange (IKE) negotiation protocol to negotiate options between two hosts for how to communicate securely by using IPsec. The agreements that two hosts make about how to communicate using IPsec and the various parameters that define this negotiation are called security associations or SAs. The IKE negotiation establishes a main mode SA (also called the ISAKMP SA) and a pair of quick mode SAs (called IPsec SAs—one for inbound traffic, the other for outbound traffic). IKE requires mutual authentication to establish the main mode SA. Windows IKE can use one of the following three methods: •
The Kerberos version 5 authentication protocol
•
X.509 digital certificate with corresponding public and private Rivest, Shamir, & Adleman (RSA) key pair
•
A preshared key (a passphrase, not exactly a password)
The most common reason for not deploying IPsec is the misperception that it requires public key infrastructure (PKI) certificates, which are often difficult to deploy. To avoid the need for a PKI, Microsoft integrated Windows 2000 domain authentication (Kerberos) in the IKE negotiation protocol. Windows IKE negotiation can be configured to allow communication with a computer that does not respond to the IKE negotiation request. This capability is referred to as Fall back to clear and is a practical necessity during rollout of IPsec. It is useful in normal operations to allow trusted hosts to talk to untrusted computers and devices only when the trusted host initiates the connection request. IPsec uses the term soft security association to describe a communication that IPsec cannot protect with either Authentication Header (AH) or Encapsulating Security Payload (ESP) formats. IPsec logs this communication with a Security Log success audit containing the destination IP address and monitors the traffic flow activity. When traffic flow ceases after an idle time (5 minutes by default), a new attempt to negotiate security is required when new outbound connections are made. IPsec does not support stateful filtering of outbound traffic either for traffic within an AH or ESP security association or for plaintext traffic involved with a soft SA. Thus, when you use the IPsec policy designs presented here for server and domain isolation, the trusted host is able to receive inbound connections from the untrusted computer to any open port through the soft SA. This is a potential window of vulnerability to attack. But it is also a design that supports certain protocols that negotiate open ports to receive inbound connections. Stateful filtering for outbound connections can be added in addition to IPsec protection by using a host-based firewall product, such as Windows Firewall. Network traffic that is protected by IPsec AH or ESP without encryption is not considered to be in plaintext form because it is does have authentication and protection against spoofing and modification. Because IPsec encapsulates normal IP packets in a secure format, the packets no longer appear as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)
Chapter 2: Understanding Server and Domain Isolation
33
packets when traversing the network. The attempt to deploy IPsec inside Woodgrove Bank identified that most network management tools assumed that applications can be readily identified by their TCP or UDP port numbers (for example, port 25 for e-mail traffic and port 80 for Web traffic). When you use IPsec, the traffic becomes opaque, and the routers and network intrusion detection system cannot distinguish which application is being used or inspect the data in the packet. This factor creates a network management issue, because it reduces the value of the tools currently used for traffic monitoring, security filtering, weighted fair queuing, and quality of service classification. Unfortunately, the assumption about traffic visibility is not entirely accurate, and it is becoming rapidly obsolete, even in the absence of IPsec. The relationship between port numbers and applications is becoming increasingly weak. It is possible, for example, to run a Web server at an arbitrary port number and to document the port number in the URL of the site. It is also possible to bypass the e-mail filtering efforts of some Internet service providers (ISPs) by running a mail service on an alternate port number. Many peer-to-peer (P2P) applications are port agile; that is, they use port numbers picked at random in an attempt to avoid detection. Applications based on remote procedure call (RPC) services are also port agile, because RPC services pick random ports in the ephemeral range (above 1024) for various services. The increasing use of Web services will likely accelerate traffic identification issues, because the traffic for these services runs on top of HTTP or HTTPS, using either port 80 or port 443. Clients and servers then use the HTTP URL to identify the traffic. All applications that move to a Web service architecture will appear as a single undifferentiated data stream to the routers, because the traffic for these Web services will run on a single port or a few ports instead of each application or service running on its own discrete port number. The use of SSL and TLS for HTTPS connections and RPC encryption decreases the value of network-based inspection as a defense against attacks. Because the network management applications could still analyze the addresses of the packets, and had visibility for all other traffic that was not IPsec-protected, Woodgrove decided that the loss of some network management functionality was not significant enough to affect the plans for the project. Additionally, some network management tool vendors were willing to modify their tools to inspect inside nonencrypted forms of IPsec packets. Most host-based applications do not need to be modified to work properly with IPsec securing all traffic between IP addresses. This solution does not attempt to use IPsec only for specific applications or protocols because of the risk of network attacks on other network services. If applications do not work properly with IPsec, the administrator may be able to choose to permit this traffic outside of IPsec protection based on the IP addresses used for servers. It is not recommended to permit applications based on a well-known port because doing so opens a static inbound hole for attackers to make inbound connections to any open port, defeating the purpose of isolation. Applications that use dynamically allocated ports cannot be permitted outside of IPsec protection. Applications that use multicast and broadcast IP addressing may have problems working with the IPsec design for server and domain isolation. Windows IPsec supports the ability to permit all multicast and broadcast traffic, but not certain types. If there are application compatibility problems, investigate with the vendor to determine whether or when a fix or upgrade will be available to address this issue. If the application cannot be upgraded or replaced with a compatible one, computers that must use this application might not be able to participate in the isolation domain or group.
34
Server and Domain Isolation Using IPsec and Group Policy
In addition to its authentication capabilities, IPsec can provide two other useful services for host communication: ensuring address integrity and encrypting network traffic: •
Ensuring address integrity. IPsec can use AHs to provide data and address integrity for each packet. Windows AH uses a keyed hashing mechanism in the Windows IPsec driver. Using AH prevents replay attacks from occurring and provides strong integrity by confirming that each received packet was not modified from the time it was sent until it was successfully received. AH will not function correctly when passing through a device that performs network address translation (NAT) because NAT replaces the source address in the IP header, therefore violating the security that IPsec AH provides.
•
Encrypting network traffic. IPsec ensures data integrity plus confidentiality through encryption by using the Encapsulating Security Payload (ESP) option for the IP protocol. Although ESP does not provide address integrity (unless it is used with AH), it can be made to successfully traverse a NAT device using UDP encapsulation. If internal networks are segmented with devices that are using NAT, ESP is the logical choice because ESP does not force packets to be encrypted. Windows IPsec supports RFC 2410 that defines the use of ESP with null encryption (ESP/null). ESP/null allows for data authenticity, integrity, and anti-replay without requiring encryption. Windows Server 2003 Network Monitor is capable of parsing ESP that is not encrypted to expose the normal TCP/IP upper layer protocols. If ESP encryption is used, monitoring of packets is possible only when the computer uses an IPsec hardware acceleration network card that decrypts the incoming packets first.
Note ESP with encryption or using null encryption provides strong IPsec peering relationships with authentication, just like AH. It also provides replay protection and will properly traverse a NAT device. For these reasons, Woodgrove decided not to implement AH and instead uses only ESP/null and ESP with encryption on its corporate network.
There are two modes in which IPsec can operate—tunnel mode or transport mode: •
IPsec transport mode. IPsec transport mode is the recommended way to secure traffic between end-to-end hosts. The IPsec driver simply inserts an IPsec header after the original IP header. The original IP header is preserved, and the rest of the packet is secured in by either AH or ESP cryptographic processing. The IPsec filters control what traffic is blocked, permitted, or encapsulated by IPsec. The IPsec filters specify source and destination IP address (or subnets), protocol (such as ICMP or TCP), and source and destination port. Thus, filters can apply very specifically to one computer, or they can apply for all possible destination addresses and protocols. Transport mode was designed to accommodate dynamic IP addresses by automatically updating filters configured with "My IP Address." It has less overhead and is overall much easier to use than IPsec tunnel mode. Thus, IKE negotiating transport mode is an effective way to authorize inbound IPsec-protected connections. Issues with using IPsec transport mode include: •
An initial delay. There is a 1-2 second initial delay required for IKE to start and complete the full successful negotiation. While continuous communication is happening, IKE attempts to refresh cryptographic keys that protect traffic automatically.
•
Predefined priority order for filters. IPsec policy filters can overlap and so have a predefined priority order, most specific first. This requires both sides in a communication to have a compatible set of IPsec transport mode filters for IKE negotiation. For example, this solution uses a more general filter for "all traffic" that negotiates IPsec security, in combination with a more specific filter to permit only ICMP traffic instead of securing that traffic with IPsec.
Chapter 2: Understanding Server and Domain Isolation
•
•
35
Computational expense. IPsec ESP transport mode encryption can be computationally expensive. CPU utilization may peak at 80-100 percent during encrypted file copies. Windows 2000, Windows XP, and Windows Server 2003 have interfaces for network cards to be able to accelerate IPsec cryptographic operations in hardware.
IPsec tunnel mode. IPsec tunnel mode is typically used for gateway-to-gateway VPN tunnels between static IP addresses of VPN gateways. Thus, tunnel mode creates a new IP header with an IPsec header. The original packet with original IP header is encapsulated entirely to form a tunnel packet. For server and domain isolation scenarios, tunnel mode could be used to secure traffic from a static IP server to an IPsec-capable router. This might be necessary if the destination host does not support IPsec. Woodgrove did not have a scenario in which tunnel mode was required.
For more information about the technical details of both transport mode and tunnel mode in IPsec, see Determining Your IPSec Needs.
Host Authorization After a host determines that the communication it is receiving is from a verifiable source, the host needs to determine whether to allow access to the source computer and user. This step is important, because the fact that a device is capable of authenticating is no guarantee that it is also allowed to access a given host. The approach that Microsoft recommends is to use standard Windows groups to limit the users' and computers' abilities to access the resources on other computers in the design. This method creates a new layer of authorization for both the computer accounts and the user accounts at the network and application level by using permissions on the user rights assignments of the local policy on the host being accessed. Using both the "Access this computer from the Network" (ALLOW) and the "Deny access to this computer from the network" (DENY) user right assignments, it is possible to restrict the ability of a computer and a user to access a resource even though they share common IPsec policy parameters and the logged-on user has the right to access the resource. This extra level of control is fundamental to the isolation approach that this solution describes. The group capabilities of Active Directory organize the computers and users in such a way as to allow the required authorization levels to be assigned in a manageable and scalable manner. To help differentiate the groups that were specifically created to achieve the host access permission from those of the standard share access permissions, this guide uses the term network access groups.
36
Server and Domain Isolation Using IPsec and Group Policy
The following figure illustrates the main steps in the overall host and user authorization process of the solution.
Figure 2.2 User and host authorization process Figure 2.2 shows a five-step process, as detailed in the following list, that is followed for all network communications after the isolation solution is in place. 1. User attempts to access a share on a departmental server. A user that is logged on to the client computer attempts to access a share on a trusted host within the logical isolation solution. This action causes the client computer to attempt to connect to the trusted host using the file sharing protocol (Server Message Block protocol using TCP destination port 445, typically). The client has IPsec policy assigned as part of the solution. The outbound TCP connection request triggers an IKE negotiation to the server. The client IKE obtains a Kerberos ticket to authenticate to the server. 2. IKE main mode negotiation. After the server receives the initial IKE communication request from the client computer, the server authenticates the Kerberos ticket. During the authentication process, IKE checks that the client computer has the required host access rights as assigned in the ALLOW or DENY users rights in the Group Policy. If the client computer has the required user right assignment, the IKE negotiation will complete, and an IPsec main mode SA will be established. 3. IPsec security method negotiation. After the IKE main mode SA negotiation has completed, the security methods of the IPsec policy are checked to negotiate a connection by using security methods for IPsec SAs that are acceptable to both hosts.
Chapter 2: Understanding Server and Domain Isolation
The following flowchart illustrates the complete process from steps 2 and 3:
Figure 2.3 Computer host access permissions-checking process
37
38
Server and Domain Isolation Using IPsec and Group Policy
4. User host access permissions checked for user. After IPsec-protected communication is established, the SMB protocol authenticates using the client user account. On the server, the user account is checked to see if it has the required host access permissions as assigned in the ALLOW and DENY user rights in the Group Policy for the trusted host. The following flowchart illustrates this process:
Figure 2.4 User host access permissions checking process If the user account has the required user right assignment, the process completes, and the user logon token is created. After this process is complete, the logical isolation solution has finished conducting its security checks. 5. Share and file access permissions checked. Finally, the standard Windows share and file access permissions are checked by the server to ensure that the user is a member of a group that has the required permissions to access the data that the user requested. The use of network access groups makes it possible to achieve an extremely high level of control in the solution. The following scenario provides a practical example of how the steps in the logical isolation solution work: During a meeting, a contractor plugs her mobile computer into a network connection point in a conference room to copy some data to a share on the HR server of an employee. Donna, a member of the HR department, provides the contractor with the path for the share on the HR server. Because the contractor's computer is not a known or trusted host, the IT department does not manage the computer, and the level of security precautions in place on the mobile computer is unknown. So, potentially, the files can contain malware that could infect internal computers. When the contractor's computer attempts to connect to the HR server, the computers fail at step 2 in the process. The
Chapter 2: Understanding Server and Domain Isolation
39
computers cannot negotiate an IKE main mode SA because the mobile computer is unable to provide the required Kerberos ticket to allow the computer's credentials to be checked; it is not part of a trusted domain. The IPsec policy requirements of the isolation group that the HR server is a member of do not allow the server to communicate with a host that does not use IPsec, so all communication attempts are blocked from this untrusted computer. In summary, the logical isolation solution helps protect the IT infrastructure from the threat of untrusted and unmanaged computers even if those computers have physical access to the internal network. This example explains how isolation can be achieved on a host-by-host basis. Another important requirement of the solution is to provide isolation at reduced administrative costs. It is possible to group computers in the same manner as you do users and then assign those groups the ALLOW or DENY user rights assignment in each computer's local policy. However, this approach will be difficult to manage and does not scale well without using the centralization capability of Group Policy and Active Directory, and without a thorough understanding of the required communication paths. In addition, this approach alone does not provide strong authentication or the ability to encrypt data. When these host access permissions are coupled with IPsec and the hosts are organized into isolation groups, it is easier to understand the relationships between the groupings and simpler to define the communication paths (after the requirements have been clearly documented). For more information about the design and framework for isolation groups, see Chapter 4, "Designing and Planning Isolation Groups."
What Does Server and Domain Isolation Protect Us From? Server and domain isolation are about placing limits on how computers communicate with each other and with devices that attempt to initiate communications. These limits or boundaries are used to restrict communications by depicting the level at which a device is trusted. Placing boundaries such as authentication, authorization, and network location around a host by using IPsec policy is an effective way to mitigate many threats. Although IPsec is not a complete security strategy, it does provide an additional layer of defense in an overall security strategy. The following section describes some typical threats and briefly discusses threat modeling. For more information about trusted devices within the Woodgrove Bank scenario and the design process that Woodgrove used to identify and classify computers as trustworthy, see the "Trust Determination" section of Chapter 3, "Determining the Current State of Your IT Infrastructure."
Modeling and Categorizing Threats In recent years, the frequency and complexity of attacks on network-based applications and servers have significantly increased. Interestingly, both the types and styles of attacks and the basic methods used to counter them have remained relatively static. However, some features and methods of implementing these defenses are different. Before you can begin to understand the planning that a server and domain isolation solution requires, your organization should conduct a detailed risk analysis of the threats that are present and how you can counter them by using various technologies and processes. Processes that can identify, categorize, and enumerate threats to an organization have been documented over the years. This documentation often presents a methodology that can be used for modeling common business, environmental, and technical threats to an
40
Server and Domain Isolation Using IPsec and Group Policy
organization. Microsoft uses the STRIDE method for threat modeling. STRIDE stands for categories of threats to guard against. These categories are: S
spoofing
T
tampering
R
repudiation
I
information disclosure
D
denial-of-service
E
elevation-of-privilege
It is essential that adequate time and resources be devoted to defining as detailed a threat model as possible to ensure protection for all assets that need to be protected. For an explanation of particular threats and attacks that server and domain isolation can help mitigate, see Appendix D, "IT Threat Categories," of this guide. For detailed discussions about threat models, see Securing Windows 2000 Server: Chapter 2, Defining the Security Landscape.
How Can We Deploy Server and Domain Isolation? After you gain an understanding of the threats to your organization and realize how the solution mitigates these threats, the next thing to do is to examine the manner in which such a solution can be deployed. This section describes how this deployment process can take place.
Information Gathering The very first step, even before beginning the design process, is to ensure that you have an up-to-date and accurate picture of the current state of your organization's network that includes workstation and server configurations as well as communication paths. It is not possible to develop an effective logical isolation solution without knowing exactly what the solution is expected to protect. Chapter 3, "Determining the Current State of Your IT Infrastructure," provides a detailed explanation and rationale for obtaining information about the current state of your network and the devices on it. This process will provide all of the requisite information for the subsequent chapters of this solution in addition to providing value to other projects undertaken in the organization. Most importantly, it will enable the organization to closely analyze and scrutinize the required communication paths for its information systems and to make informed choices about the compromises that may exist among risk, communication requirements, and business requirements.
Chapter 2: Understanding Server and Domain Isolation
41
IPsec Deployment Process Overview After you have decided upon and created a design, the next priority is establishing a process for implementing the design into the organization in a manner that is both manageable and of minimal impact to users. Chapter 4, "Designing and Planning Isolation Groups," discusses in detail a number of different approaches that you can use to achieve this. However, the basic process can be summarized as follows: 1. Test the design and IPsec polices in a proof-of-concept lab. You should test the proposed IPsec policies in an isolated, non-production environment to ensure that the design works as expected and to test any issues that might arise in the policy settings or deployment mechanisms. 2. Pilot the tested and approved design. When the team is confident that the design will work as expected in the lab environment, the next step in the process is to identify a limited number of computers to include in a pilot deployment of the solution into a production environment. The identified computers and users should be given proactive support to ensure that any issues that emerge during testing have minimal effect on users' abilities to perform their job roles. 3. Implement a phased roll out of the solution. The final step in the process is to have a plan that can be used to deploy the design to the rest of the organization. This is not a trivial process! You should take a great deal of care in the planning of this step. It is possible to engineer a design that can (with a single setting change in an IPsec policy) disable many computers' abilities to access network resources. You should test and organize your deployment plan to enable the changes that the solution introduces to be implemented in a way that will allow for a rapid return to a known good state in the event that a configuration or design error somehow remains undetected during the testing phase. Chapter 4, "Designing and Planning Isolation Groups," provides detailed information on the isolation domain design process and presents options for a phased roll out approach to the solution.
Summary This chapter discussed the goals and processes behind the solution presented in this guide. Although IT professionals have well understood the benefits of IPsec for many years, the complex nature of the technology has led many people to avoid implementations. With IPsec implementation, potential exists for serious consequences if the solution does not have in place a solid design, a well-planned deployment, and a reliable test methodology. The guidance in this chapter should convey that logical isolation is an additional layer of security that uses server and domain isolation techniques with the capabilities of the Windows platform, IPsec, Group Policy, and Active Directory to provide a manageable and scalable enterprise solution that can minimize the risk to which data assets are exposed. The information presented in the remaining chapters focuses on the stages that are required to plan and implement this solution. Chapter 6, "Managing a Server and domain Isolation Environment," provides procedures that you can implement for the day-to-day running of an operational environment that is using server and domain isolation. Chapter 7, "Troubleshooting IPsec," provides supportability and troubleshooting information.
Chapter 3: Determining the Current State of Your IT Infrastructure This chapter provides information about how to obtain the necessary information to plan for and deploy a server and domain isolation solution. Successfully deployment requires an accurate and up-to-date picture of the information technology (IT) infrastructure. After reading this chapter, you will have a good understanding of the information that is required for you to complete the design of a server and domain isolation solution. The final part of this chapter discusses the process of understanding and documenting which identified computers are likely to be able to work as "trusted" computers within the solution. The design team will require this information when they create the plans for the solution.
Chapter Prerequisites Before using the information in this chapter, ensure that you and your organization meet the following prerequisites. The guidance that this chapter provides is specifically tailored to meet the needs of an organization that is closely aligned with these prerequisites. Failure to meet all the prerequisites will not necessarily have a negative impact on your project, but you will maximize the value of this guidance if you meet them.
Knowledge Prerequisites You should be familiar with concepts of IPsec, and also have a solid understanding of the following: •
Microsoft® Windows® authentication (specifically, the Kerberos version 5 authentication protocol)
•
Active Directory® directory service concepts, including Active Directory structure and tools; manipulating users, groups, and other Active Directory objects; and use of Group Policy
•
Windows system security, including security concepts such as users, groups, auditing, and access control lists (ACL)
•
Your organization's system naming conventions
•
Your organization's physical and logical locations
•
Risk management practices used in the organization
•
Core networking concepts, including port filtering using firewalls
Before proceeding with this chapter, you should also read the previous chapters in this guide and have a thorough understanding of the architectural and design concepts of the solution.
Organizational Prerequisites Planning the isolation groups for an organization is a task that usually involves many different people. The information that is needed to determine the exact requirements will often come from a number of sources throughout the organization. You should consult with those members of your organization who may need to be involved in the planning of these groups, including the following people: •
Executive sponsors
•
Security and audit personnel
•
Active Directory engineering, administration, and operations personnel
•
DNS (Domain Name System), Web server, and application owners
•
Network administration and operations personnel
•
Internal education and help desk personnel
Note Depending on the structure of your IT organization, these roles may be filled by a number of people, or there may be fewer people spanning several roles.
In addition to requiring information from the listed teams, it is important to understand that current operational practices will need to be updated with the introduction of IPsec into the environment. It is also possible that software and hardware will need to be updated, such as BIOS and firmware updates for network devices. Finally, additional network tools may be required to help support and troubleshoot the IPsec environment.
IT Infrastructure Prerequisites This chapter also assumes that the following IT infrastructure exists: •
A Microsoft Windows Server™ 2003 Active Directory domain running in mixed or native mode. This solution uses universal groups for Group Policy object (GPO) application. If the organization is not running in mixed or native mode, it is still possible to apply the GPO through the use of standard global and local group configurations. However, because this option is more complex to manage, this solution does not use it. Note Windows Server 2003 introduced a number of improvements that affect IPsec policies. There is nothing specific to this solution that would keep it from working with Windows 2000. However, the solution was only tested using Windows Server 2003 Active Directory.For more information about the enhancements made to IPsec in Windows Server 2003, see New features for IPSec.
•
The capability and expertise to perform network monitoring, analyze monitoring data, and make capacity planning decisions based on that data. Note In many organizations, use of network monitoring tools is restricted, so care should be taken to ensure that the correct operational procedures are followed when using these tools.
•
A tool is in place that can capture network configuration data about hosts on the network. For example, existing asset management systems can be used to collect this information. For more information, see the "Host Discovery" section in this chapter.
Who Should Read This Chapter This chapter is designed for IT professionals who are responsible for creating the IT infrastructure inventory that solution architects and designers will use. These IT professionals will usually be members of the organization's support or operations staff. A
Chapter 3: Determining the Current State of Your IT Infrastructure
45
good level of technical understanding of both the tools and technologies involved in the information-gathering process and the organization's current infrastructure is required to get the most benefit from this chapter.
Identifying Current State The process of obtaining and maintaining a reliable record of an organization's computers, software, and network devices is a classic IT challenge. A successful project will depend on the information obtained from such a process. Before starting the planning process for a server and domain isolation project, you need to collect and analyze up-todate information about the computers, the network, and the directory services that are already deployed in the organization. This information will allow you to create a design that accounts for all possible elements of the existing infrastructure. If the gathered information is not accurate, problems can arise when devices and computers that were not considered during the planning phase are encountered during implementation. The following sections outline the required information in each area and provide examples of the information that was gathered for the Woodgrove Bank server and domain isolation solution.
Network Discovery Perhaps the most important aspect of planning for server and domain isolation is the network architecture, because IPsec is layered on the Internet Protocol itself. An incomplete or inaccurate understanding of the network will prevent any isolation solution from being successful. Understanding subnet layout, IP addressing schemes, and traffic patterns are part of this effort, but the following two components are vital to completing the planning phase of this project: •
Documentation of network segmentation
•
Documentation of the current network traffic model
The goal is to have enough information to identify an asset by its location on the network in addition to its physical location. It is better to start with a network architecture that is very well thought out, has easily identifiable address ranges, and has as few overlaps or discontinuous ranges as possible. There may be specific business requirements or circumstances (such as mergers and acquisitions) that do not allow for a "streamlined" network, but if the current state is documented and understood, the task of identifying the network and its managed assets is simpler. Do not use a complex and poorly documented network as a starting point for the design, because it can leave too many unidentified areas that are likely to cause problems during implementation. This guidance helps obtain the most relevant information for planning server and domain isolation but does not attempt to address other issues, such as TCP/IP addressing and variable length subnet masking, virtual local area network (VLAN) segmentation, or other network optimization methods and techniques. The obtained information will be used to formulate the implementation and operational components of the server and domain isolation solution.
46
Server and Domain Isolation Using IPsec and Group Policy
Documentation of Network Segmentation If your organization does not have its current network architecture documented and available for reference, such documentation should be obtained as soon as possible before proceeding with the solution. If the documented information is not current or has not been validated recently, you have two basic options: •
Accept that the information can cause undue risk to the project.
•
Undertake a discovery project, either through manual processes or with a network analysis tool that can provide the information that is required to document the current network topology.
Although the required information can be presented in a number of different ways, a series of schematic diagrams is often the most effective method of illustrating and understanding the current network configuration. When creating network diagrams, try to avoid flooding them with too much information. If necessary, use multiple diagrams showing different layers of detail. For example, in the Woodgrove Bank scenario, the team created the following diagram to illustrate the high-level view of its existing wide area network (WAN) and site environment:
Figure 3.1 Woodgrove Bank WAN and site network diagram After the team created this diagram, it proceeded to create more detailed diagrams for each site, and ultimately each subnet within each site.
Chapter 3: Determining the Current State of Your IT Infrastructure
47
While documenting your network you may find some network applications and services that will not be compatible with IPsec. Current examples of such incompatibility include the following: •
Cisco NetFlow on routers cannot analyze packets between IPsec members based on protocol or port.
•
Router-based Quality of Service (QoS) cannot use ports or protocols to prioritize traffic. However, using specific IP addresses to prioritize traffic will not be affected. For example, a rule that says "From anyone to anyone using port 80 prioritize" would not function, whereas a rule that says "From anyone to 10.0.1.10 prioritize" would be unaffected.
•
Devices that do not support or permit IP protocol 50, the port used by Encapsulating Security Payload (ESP).
•
Weighted Fair Queuing and other flow-based router traffic priority methods may fail.
•
Network monitors may be unable to parse ESP packets that are not encrypted (ESPNull). Note Microsoft Network Monitor added an ESP parser for version 2.1 to help troubleshoot unencrypted IPsec packets. Network Monitor is included with Microsoft Systems Management Server (SMS). For more information, see Microsoft Systems Management Server.
•
If the device cannot parse ESP, any ACLs that specify port or protocol rules will not be processed on the ESP packets.
•
If the device has an ESP parser and uses encryption, ACLs that specify port or protocol rules will not be processed on the ESP packets.
IPsec breaks network-based prioritization and port/protocol-based traffic management when ports and protocols are used. Unfortunately, there is no workaround for encrypted packets. If traffic management or prioritization must be based on ports or protocol, the host itself must be capable of any traffic management or prioritization functions. Next, it is important to record exactly what information is needed for the various devices in the network.
Network Infrastructure Devices The devices that make up the network infrastructure (routers, switches, load balancers, and firewalls) will communicate using IPsec after the solution is implemented. For this reason, it is important to examine the following characteristics of these devices on the network to ensure that they will be able to handle the technical and physical requirements of the design: •
Make/model. You can use this information to determine the features that the device supports. In addition, you should check BIOS or software running on the device to ensure that IPsec is supported.
•
Amount of RAM. This information can be useful when making determinations about capacity or about the impact of IPsec on the device.
•
Traffic analysis. This information (peak utilization in addition to daily/weekly trends that show daily use of the device) is always helpful to have. In relation to IPsec, the information helps provide a snapshot of the device and how it is used over a period of time. If problems arise after IPsec is implemented, the information can help determine whether the root cause is related to high utilization of the device.
48
Server and Domain Isolation Using IPsec and Group Policy
•
ACLs that affect IPsec directly. ACLs directly affect the ability of certain protocols to function. For example, not allowing the Kerberos protocol (User Datagram Protocol [UDP] and TCP port 88) or IP protocol (not port, but protocol) 50 or 51 will prevent IPsec from working. Devices must also be configured to pass Internet Key Exchange (IKE) traffic (UDP 500 and 4500) if using network address translation traversal (NAT-T).
•
Networks/subnets connected to device interface(s). This information helps provide the best possible analysis of what the internal network looks like. Defining the boundary of the network based on an address range is very straightforward and helps identify whether other addresses are either unmanaged or foreign to the internal network (such as Internet addresses). This information is necessary for IPsec policy decisions that are made in subsequent chapters of this guide.
•
Whether the device is performing network address translation (NAT). Network address translation is commonly used to present an entire address range as a single IP to a connected network, or to the Internet. The solution planner should know where this process is taking place on the network. Note Microsoft Knowledge Base article 818043, "L2TP/IPSec NAT-T update for Windows XP and Windows 2000," provides NAT-T functionality as a downloadable fix for Windows XP Service Pack (SP) 1 and Windows 2000 SP4. However, an IPsec responder will not function properly unless you have installed Windows XP SP2 or Windows Server 2003 SP1.
•
VLAN segmentation. Determining how VLANs are currently implemented on the network will help you understand the traffic patterns or security requirements that currently exist, as well as to determine how IPsec will augment or potentially interfere with these requirements.
•
The links to which the device is connected. This information will help you to depict the connections that the device maintains between which networks. It also helps identify the logical network and connections to various locations on a particular interface.
•
The maximum transmission unit (MTU) size on device interface(s). The MTU defines the largest datagram that can be transmitted on a particular interface without being divided into smaller pieces for transmission (a process also known as "fragmentation"). In IPsec communications, the MTU is needed to determine areas where fragmentation will occur. Packet fragmentation must be tracked for the Internet Security Association and Key Management Protocol (ISAKMP) by the router. IPsec will configure the MTU size on the session to the minimum-discovered MTU along the communication path being used, and set the do not fragment bit (DF bit) to 1. Note If Path MTU (PMTU) discovery is enabled and functioning properly, you do not have to gather the MTU size on device interfaces. Some sources, such as the Windows Server 2003 Hardening Guide, recommend disabling PMTU discovery. However, PMTU discovery must be enabled to allow IPsec to function properly.
Also note that IPsec can affect an intrusion detection system (IDS), because a specific parser will be required to interpret data inside of packets. If the IDS does not have a parser, it cannot examine data in those packets to determine whether a particular session is a potential threat. In this case, deciding to use IPsec indicates that your organization needs IPsec more than it needs the IDS. The information identified in this section is critical for the success of the project, because it helps you to understand the current configuration and "health" of the network infrastructure before configuring those devices to use IPsec (or placing additional load on them if they are already configured to pass IPsec traffic). By studying peak use information, you can determine whether the device is capable of using IPsec in its current state or if it requires a memory or firmware upgrade to support the expected load. The make and model information will prove useful when obtaining hardware to upgrade the devices (if necessary). Information about other configuration parameters or features that might be peculiar to that make and model may also be helpful. The number of ACLs
Chapter 3: Determining the Current State of Your IT Infrastructure
49
configured on devices will help you estimate the effort that will be required to configure the devices to support IPsec. If no device on the network is configured to allow IPsec traffic, and your network has a large number of routers, device configuration could be a significant effort. After you obtain this information, you can quickly determine whether it is necessary to upgrade the devices to support the requirements of the project, change the ACLs, or take other measures to ensure that the devices will be able to handle the loads that will be expected of them.
Analysis of Current Network Traffic Model After you gather the addressing and network infrastructure information, the next logical step is to carefully examine the communications flow. For example, if a department such as Human Resources (HR) spans several buildings, and you want to use IPsec to encrypt information in that department, you need to know how those buildings are connected to determine the level of "trust" to place in the connection. A highly secured building that is connected by copper cable to another building that is not protected can be compromised by an eavesdropping or information replay attack. If such an attack were a threat, IPsec could assist by providing strong mutual authentication and traffic encryption for trusted hosts. However, the solution cannot account for the fact that a lack of physical security on trusted hosts will remain a threat. When you examine traffic flow, look closely at how all managed and unmanaged devices interact, including non-Windows based devices such as Linux, UNIX, and Mac in addition to versions of Windows that are earlier than Windows 2000 SP4. Ask yourself such questions as, Do certain communications occur at the port/protocol level, or are there many sessions between the same hosts across a wide array of protocols? How do servers and clients communicate with each other? Are there any current security devices or projects that are implemented or planned that could impact the isolation project? For example, using Windows XP SP2 and Windows Firewall to "lock down" certain ports such as UDP 500 would cause the IKE negotiation to fail. When you use the threat modeling process performed in Chapter 2, "Understanding Server and Domain Isolation," to examine the different types of network traffic, you can easily find those protocols and applications that generate traffic that should be secured from untrusted or unmanaged devices. Some of the more common applications and protocols are: •
NetBIOS over TCP/IP (NetBT) and server message block (SMB). On a LAN, it is common to have ports 137, 138, and 139 enabled for NetBT and port 445 enabled for SMB. These ports provide NetBIOS name resolution services in addition to other features. Unfortunately, they also provide for the creation of what are known as null sessions. A null session is a session that is established on a host that does not use the security context of a known user or entity. Frequently, these sessions are anonymous.
50
Server and Domain Isolation Using IPsec and Group Policy
•
Remote procedure call (RPC). Typically, RPC operates by presenting an application with a listening port (also known as the endpoint mapper, TCP port 135) which then advises the "caller" (often another application) to begin communication on another port in the ephemeral range. In a network that is segmented by firewalls, this RPC communication presents a configuration challenge because it means opening the RPC listener port and all ports above 1024. Opening so many ports increases the attack surface of an entire network and reduces the effectiveness of the firewalls. However, the advantage of RPC is that it presents an abstraction of the functionality in layers 1-4 of the Open Systems Interconnection (OSI) model for the applications that use it so that developers do not need to provide low level calls to the network for their distributed applications. Because many applications depend on RPC for basic functionality, the IPsec policy will need to account for RPC. For more information about creating IPsec policy, see Chapter 5, "Creating Isolation Policies for Isolation Groups."
•
Other traffic. IPsec can help secure transmissions between hosts by providing authentication of the packets in addition to encrypting the data that they contain. The important thing to do is to identify what needs to be protected, and the threats that must be mitigated. Other traffic or traffic types that need to be secured should be examined and modeled appropriately. For example, a special-purpose database that only a few clients are allowed to access, or a specialized application for the HR team that is only used by HR managers.
After documenting the physical and logical network, the next step is to examine current traffic patterns and answer the following questions: ● Do you currently have subnets that are dedicated to specific types of traffic (for example, Mac workstations and UNIX workstations, or mainframe-to-terminal connections)? ●
Do you need to separate different types of traffic or traffic between locations?
Active Directory After the network, Active Directory is the second most important item from which to gather information. You should understand the forest structure, including domain layout, organizational unit (OU) architecture, and site topology. This information makes it possible to know where computers are currently placed, their configuration, and the impact of making changes to Active Directory as a result of implementing IPsec. The following list describes the necessary information for completing this portion of the discovery effort. •
Number of forests. Because the forest is the security boundary in an Active Directory implementation, it is necessary to understand the current Active Directory architecture to determine which hosts should be isolated and how to accomplish that isolation.
•
Names and number of domains. IPsec authentication happens as a result of the IKE negotiation process. In this solution, the method of authentication is the Kerberos protocol. This protocol assumes that computers are domain-joined and that they meet the operating system version prerequisites (Windows 2000, Windows XP, or Windows Server 2003).
•
Number and types of trusts. Capturing the number and types of trusts is important because the trusts affect the logical boundaries of isolation and also define how IKE authentication can (or should) occur in the solution.
•
Names and number of sites. Site architecture is usually aligned with the network topology. Understanding how sites are defined in Active Directory will help provide insight into replication and other details. For this solution, site architecture provides a deeper understanding of the Active Directory implementation as it currently exists.
Chapter 3: Determining the Current State of Your IT Infrastructure
51
•
OU structure. A significant amount of operational efficiency can be gained with a little planning when creating an OU structure. OUs are logical constructs and can, therefore, be molded to fit many different requirements and goals. The OU structure is an ideal place to examine how Group Policy is currently used and how the OUs are laid out. Chapters 4 and 5 of this solution discuss the OU architecture and provide details about how this architecture can be used to apply IPsec policy.
•
Existing use of IPsec policy. Because this project will culminate in the implementation of IPsec policy, it is very important to understand how your network currently uses IPsec (if at all). Whether you are using simple IPsec filters (such as filters prescribed in a hardening guide) or implementing complete policies, understanding your current usage and requirements will ensure smoother integration with this solution.
The Woodgrove Bank scenario uses a single forest (corp.woodgrovebank.com) that contains four domains spread across five sites. Each site may contain a domain controller (DC), primary domain controller (PDC), or global catalog (GC) server as shown in the following table: Table 3.1 Woodgrove Bank Active Directory Information Physical site
Domain
Users
Domain controller type
New York, NY
corp.woodgrovebank.com americas.corp.woodgrovebank.com
5,000
Forest root global catalog PDC Americas regional GC Europe regional DC Asia regional DC
Chicago, IL
americas.corp.woodgrovebank.com
750
Americas regional GC
Atlanta, GA
americas.corp.woodgrovebank.com
1,450
Americas regional GC
Boston, MA
americas.corp.woodgrovebank.com
480
Americas regional GC
San Francisco, CA
americas.corp.woodgrovebank.com
250
Americas regional GC
Pittsburgh, PA
americas.corp.woodgrovebank.com
50
Americas regional GC
Phoenix, AZ
americas.corp.woodgrovebank.com
50
Americas regional GC
Miami, FL
americas.corp.woodgrovebank.com
50
Americas regional GC
Washington, DC
americas.corp.woodgrovebank.com
75
Americas regional GC
Cambridge, MA
americas.corp.woodgrovebank.com
36
Americas regional GC
Toronto, Canada
americas.corp.woodgrovebank.com
25
Americas regional GC
52
Server and Domain Isolation Using IPsec and Group Policy
Physical site
Domain
Users
Domain controller type
London, U.K.
europe.corp.woodgrovebank.com corp.woodgrovebank.com
5,200
Forest root GC PDC emulator Europe regional GC Americas regional DC Asia regional DC
Geneva, Switzerland
europe.corp.woodgrovebank.com
350
Europe regional GC
Amsterdam, Netherlands
europe.corp.woodgrovebank.com
295
Europe regional GC
Munich, Germany
europe.corp.woodgrovebank.com
149
Europe regional GC
Rome, Italy
europe.corp.woodgrovebank.com
80
Europe regional GC
Dublin, Ireland europe.corp.woodgrovebank.com
79
Europe regional GC
Edinburgh, Scotland
europe.corp.woodgrovebank.com
40
Europe regional GC
Johannesburg, europe.corp.woodgrovebank.com South Africa
37
Europe regional GC
Tokyo, Japan
asia.corp.woodgrovebank.com corp.woodgrovebank.com
500
Forest root GC PDC emulator Asia regional GC Europe regional DC Americas regional DC
Hong Kong, China
asia.corp.woodgrovebank.com
100
Asia regional GC
Bangkok, Thailand
asia.corp.woodgrovebank.com
150
Asia regional GC
Singapore
asia.corp.woodgrovebank.com
210
Asia regional GC
Sydney, Australia
asia.corp.woodgrovebank.com
45
Asia regional GC
Bangalore, India
asia.corp.woodgrovebank.com
35
Asia regional GC
Taipei, Taiwan asia.corp.woodgrovebank.com
65
Asia regional GC
The Woodgrove Bank Active Directory design used the two-way trust relationships that are automatically created by the forest. No additional cross forest or external trusts were in place.
Chapter 3: Determining the Current State of Your IT Infrastructure
53
The following figure shows an example of the high-level OU structure that Woodgrove Bank used. This structure was used consistently across the three main regional domains of Americas, Europe, and Asia.
Figure 3.2 Woodgrove Bank OU structure example Because the server and domain isolation project was Woodgrove Bank's first IPsec implementation, there were no existing active IPsec policies in place.
Host Discovery The most valuable benefit of conducting an asset discovery project is the large amount of data that is obtained about hosts (workstations and servers) on the network. In Chapter 4, "Designing and Planning Isolation Groups," decisions are made that require accurate information about the state of all hosts to ensure that they are able to participate in the design's IPsec communications.
Host Data Requirements This section describes the host information that is needed and discusses how to represent this information physically and logically. •
Computer name. This name is the computer's NetBIOS or DNS name that identifies the computer on the network. Because a computer can have more than one media access control (MAC) and/or IP address, the computer's name is one of the criteria that can be used to determine uniqueness on the network. Computer names can be duplicated under some circumstances, so the uniqueness should not be considered absolute.
•
IP address(es) for each network interface card (NIC). The IP address is the address that is used with the subnet mask to identify a host on the network. It should be noted that an IP address is not an effective way to identify an asset because it is often subject to change.
•
MAC address for each NIC. The MAC address is a unique 48-bit address that is used to identify a network interface. It can be used to help differentiate between different network interfaces on the same device.
54
Server and Domain Isolation Using IPsec and Group Policy
•
Operating system, service pack, and hotfix versions. The operating system version is a key factor in determining the ability of a host to communicate with IPsec. It is also important to track the current state of service packs and hotfixes that may be installed, because these are often used to determine that the minimum security standards have been met.
•
Domain membership. This information is used to determine whether a computer can obtain IPsec policy from Active Directory or whether it will need to use a local IPsec policy.
•
Physical location. This information is simply the location of the device in your organization. It can be used to determine whether a device should participate in a particular isolation group based on its location or the location of the devices that it communicates with regularly.
•
Hardware type/role. It may not be possible to gather this information from an automated process. Some tools that perform host discovery can provide this information by querying the hardware information and running applications to determine its type, such as server, workstation, or tablet PC. You could use this information to determine the eligibility of a particular computer to participate in isolation and in which isolation group to place the computer. Note The hardware type information is derived by data interpolation or by a software product that performs queries to provide this information. For example, it is well known that an HP Evo n800 is a mobile computer, and if you can query to the hardware level (or have an asset tag that identifies it as such), you can more readily determine the appropriate IPsec policy to assign to the device.
After collecting all this information and consolidating it into a database, perform regular discovery efforts at periodic intervals to keep the information current. You will need the most complete and up-to-date picture of the managed hosts on their networks to create a design that will match your organization's requirements. You can use various methods to gather data from the hosts on the network. These methods range from high-end, fully automated systems to completely manual data collection. Generally, the use of automated methods to gather data is preferred over manual methods for reasons of speed and accuracy. However, the information that is required is the same, regardless of which method is used; only the amount of time spent obtaining the information is different. Typical problems that manual processes encounter include having duplicate information, ensuring that the scope of the effort is accurate (such as whether all networks were scanned and host information captured or just the client subnets), and obtaining the information in a timely manner so that it is useful to the project. A discussion of all elements of a complete IT system's audit is outside the scope of this project. However, it is important to understand that this audit information should be available to the organization for many more reasons beyond the needs of this solution. Asset tracking and security risk management are just two important examples of processes that require a current and accurate system inventory.
Automated Discovery Using an automated auditing network management system such as SMS will provide much valuable information about the current state of the IT infrastructure. One problem with automated systems, however, is that hosts that are offline, unplugged, or otherwise physically (or logically) unable to respond to queries for information will not show up in the final database. Even the most automated systems require an element of manual management to ensure that the hosts are accessible and accounted for correctly. Many products and tools are available from a variety of vendors. Some methods use a central scanning mechanism, and some use agents that are installed on the client computers. It is outside of the scope of this guide to compare or recommend products for
Chapter 3: Determining the Current State of Your IT Infrastructure
55
purchase, but the solution requires that the discovery data highlighted in this chapter is present for the design considerations made in chapters 4 and 5. For more information about how SMS 2003 can help perform asset management (or can help gather the information that this project requires), see the demonstration and the asset management datasheet on the SMS 2003 Asset Management page.
Manual Discovery The biggest difference between manual discovery methods and automated methods is time. It could take a few dozen people days or weeks to manually gather the information required for this project, and possibly longer in a larger enterprise. If you plan to use a manual method to audit the current state of your infrastructure, it is important that the obtained information be available in an electronic format such as a spreadsheet or database. The sheer volume of data that can be generated can make the process of filtering and analyzing very difficult if you cannot quickly and accurately generate specific queries that return the required information. In addition, you can use local IT administrators to obtain the information or validate any information that was collected previously. Even if your organization does not possess an automated auditing tool, there is still an element of automation that you can obtain by using the standard remote management and scripting interfaces that are available on the Windows platform. The primary issue with using these tools is ensuring that clients are not missed simply because they are not compatible with the management tool or script. You can use the Windows Scripting Host (WSH), Microsoft Visual Basic® Scripting Edition (VBScript), and Windows Management Instrumentation (WMI) to create a script file that can collect the system configuration information. The following table shows the availability of both VBScript and WMI by platform. Table 3.2 VBScript and WMI Availability by Platform Platform
VBScript
WMI
Windows 95
Install WSH 5.6
Install WMI CORE 1.5
Windows 98
Built-in
Install WMI CORE 1.5
Windows Millennium
Built-in
Built-in
Microsoft Windows NT® version 4.0
Install WSH 5.6
Install WMI CORE 1.5
Windows 2000
Built-in
Built-in
Windows XP
Built-in
Built-in
Windows Server 2003
Built-in
Built-in
Note You can download the Microsoft Windows Script 5.6 Update from the Microsoft Windows Script Downloads page. You can download the Windows Management Instrumentation (WMI) CORE 1.5 installation package from the Microsoft Download Center.
An example VBScript called Discovery.vbs is provided in the Tools and Templates folder of this solution. This script uses WMI to retrieve all of the information listed in the "Host Data Requirements" section of this chapter, with the exception of role and physical location. The information is collected in the text file C:\Discovery\_info.txt on the local computer. You could modify the script to collect additional information or to place the collected information on a remote file share.
56
Server and Domain Isolation Using IPsec and Group Policy
If WMI or VBScript is not available on the host computer, you can collect some information by using a batch script and external tools. The difficulty is that the batch language is extremely limited in functionality, and configuration information is not easily obtained from the command line in earlier versions of Windows. To perform a host discovery, it is necessary to query hosts and provide a place to store the results of those queries. Whether you use an automatic, manual, or hybrid option to gather the information, one of the biggest issues that can cause problems to the design is capturing the changes between the original inventory scan and the point at which the implementation is ready to start. After the first scan has been completed, you should make support staff aware that all further changes need to be recorded and the updates noted in the inventory. This inventory will be critical for planning and implementing IPsec policies, which subsequent chapters discuss.
Capacity Considerations After information-gathering is complete, the impact of IPsec (including some capacity planning) will be your next area of focus. This section describes some of the essential aspects of properly planning for IPsec in your environment.
Impact of IPsec Because IPsec uses various cryptographic techniques, it can consume significant overhead on a computer. The scenarios that require closer analysis will be those that require encryption. For example, one might use the Triple Data Encryption Standard (3DES) and Secure Hash Algorithm (SHA-1) to check integrity in situations that require the strongest available encryption and key exchange protection. Another scenario involves security association (SA) negotiation. You could use a shorter lifetime for the main mode SA such as three hours, but as with many security considerations you should expect to have to make tradeoffs. Each main mode SA occupies approximately 5 KB of RAM. A situation in which a server is expected to broker tens of thousands of concurrent connections could lead to overutilization. Other factors include CPU utilization on network infrastructure servers, increased overhead on servers and workstations running IPsec (especially servers, because they will contain more main mode SAs than clients in most cases), and increased network latency as a result of IPsec negotiation. Note In Microsoft's own deployment of this solution it was found that it is normal to expect a one to three percent increase in utilization on your network as a direct result of using IPsec.
Another primary concern is networks that are connected with an NAT device between them. The problem is that NAT does not allow Authentication Header (AH) conversations between hosts, because NAT violates the very principle that AH is designed to provide: the authentication of an unchanged packet, including the header. If NAT devices exist on the internal network, ESP would need to be selected instead of AH. ESP provides for the ability to encrypt data, but does not require encryption. This factor is important from a capacity consideration perspective because encryption has overhead that must taken into account during the planning and design phases of the project. ESP can also be implemented with null encryption, which provides the strongest IPsec peer-to-peer communication possible without breaking communications with NAT. And because it does not use encryption, it would have a lower impact than ESP with encryption.
Chapter 3: Determining the Current State of Your IT Infrastructure
57
Impact of Policy IPsec policy and Group Policy will both have an impact on computers' startup times as well as the time that it takes for users to log on. While you are in the information gathering phase, it is useful to note the computer startup times and logon times of users before implementing the solution. Recording these times here will provide a baseline to which you can compare the test systems during the pilot to determine the impact on the overall time that it will take for a user to be logged on.
Predeployment Concerns The preceding sections described information that you should gather from the network, Active Directory, and the hosts to help make an isolation effort succeed. This section lists areas of concern that you should examine closely before deploying IPsec.
Network Infrastructure Information gathering enables you to plan for IPsec isolation in a network. After gathering this information, careful analysis of the data will reveal most of the problems that you will face during pilot and deployment. Although the following items do not comprise a comprehensive list, they are important to consider when beginning your analysis of gathered information prior to testing and deployment.
Overused Devices You might need to upgrade or reconfigure switches or routers that currently exceed 75 percent utilization to allow for increased traffic on the device and still provide some extra utilization for bursts of traffic. Proper capacity planning for the implementation of IPsec is more about testing and anticipated traffic loads than exact calculations. Because it is extremely unlikely that the scenario, traffic patterns, user concentrations, and applications are exactly the same for any two customers, proper planning and considerations for how network devices will be affected is imperative. For example, certain aspects of IPsec are completely predictable. Each packet using IPsec with ESP will be exactly 36 bytes larger than the same packet that does not use IPsec. Because there are six messages required to establish a single main-mode SA, it is easier to account for how utilization might be affected on a particular device. You can use tools such as the Tivoli Switch Analyzer from IBM or other network analyzer solutions to assist in capacity planning for IPsec in your IT environment.
Incompatible Devices Devices that are not compatible with IPsec cannot participate in IPsec communications. If such devices need to communicate with a managed device, you should place them in the IPsec exemption list. One alternative is to either upgrade device hardware or software to support IPsec. Another alternative is to allow those unmanaged devices to communicate with boundary computers when they fall back to clear for their outbound communications.
Devices Configured Incorrectly Incorrectly configured devices can increase the possibility of failed communications and increased load on the device, and they can even lead to compromised devices. Following best practices for configuration, administration, and security of the devices will help alleviate this concern.
58
Server and Domain Isolation Using IPsec and Group Policy
IP Addressing Because IP addresses are the fundamental building block of an IPsec solution, it is important that the addressing be as "clean" as possible. Things such as overlapping address spaces, duplicate addresses, incorrect subnet masks, and other problems can complicate normal network operations. Adding IPsec to such a network will only complicate troubleshooting and cause people to suspect IPsec as the source of the problems. Organizational growth, mergers and acquisitions, and other factors can quickly lead to an outdated and inaccurate picture of IP addressing on a network. To eliminate the biggest issues with IPsec, ensure that the network is divided into subnets that do not overlap, the route tables are nicely summarized, and address aggregation is easily determined.
Active Directory Information If the current Active Directory implementation is functioning properly (that is, name resolution, Dynamic Host Configuration Protocol [DHCP], application of Group Policy, trust relationships, and so on), nothing should affect IPsec. You should scrutinize any changes made between the time Active Directory was examined and the time that the isolation project begins to ensure that you will not encounter any compatibility problems.
Host Information The previous sections have helped you gather sufficient information about the hosts on your network. After you determine which clients and servers are able to use IPsec, note how you need to isolate them and what applications you need to closely examine for the impact that the isolation solution may have on them.
Determining Client/Server Participation After gathering information about the hosts, it is relatively straightforward to determine which hosts would be eligible for integration into the isolation solution. For example, only Windows 2000-, Windows Server 2003-, and Windows XP-based computers can communicate with IPsec. However, perhaps not all of the clients that can participate should do so. An important part of the design process is to determine from the information gathered in this chapter which computers and devices will be included in the solution and in which group they will reside.
Determining Services That Need to Be Isolated In the context of the server and domain isolation project, a service is an application, such as Microsoft Exchange Server, Microsoft SQL Server™, or Internet Information Services (IIS) that provides its services to clients on the network. You should evaluate these services individually to determine whether they are candidates for server and domain isolation. There are a number of reasons why these services may have to be included in the solution, such as organizational policy, government regulation, or other business requirements. For example, there may be an organizational policy that dictates that all communications between mail servers must be secured by using IPsec, but the communications between clients and servers do not need to be secured in this manner. Chapter 4, "Designing and Planning Isolation Groups," discusses the isolation process in greater detail. When attempting to isolate services, carefully consider those servers that operate multiple services, such as a file server that provides Web services and File Transfer Protocol (FTP) and is also a mail server.
Chapter 3: Determining the Current State of Your IT Infrastructure
59
Network Load Balancing and Clustering Organizations that are using server and domain isolation may choose to exempt computers that use Network Load Balancing (NLB) and clustering. IPsec is not compatible with NLB in "no affinity" mode because IPsec prevents different computers from using the same client connection. Because of this incompatibility, you should not attempt to use NLB in "no affinity" mode with IPsec.
Managing Exceptions Managing exceptions is an important part of IPsec planning. Determining where to use computers that will allow access from untrusted hosts and controlling access between managed and unmanaged computers is a crucial element of isolation. It is considered a best practice to keep the number of exceptions to the minimum number possible. Technical needs may dictate that some computers or services are exempted from IPsec, such as domain controllers and DHCP, DNS, and WINS servers. Because these computers should still be managed, the potential risk is lower than allowing unmanaged computers to communicate with managed, trusted computers.
Non-Windows-Based Devices Most enterprise networks are not homogenous. You must account for diversity of elements such as operating systems, network infrastructure, and hardware platforms when planning an IPsec deployment. If your organization has non-Windows-based computers, you should understand that the consumption of IPsec policy outside of the Windows realm is not currently possible. An organization might decide to address this limitation by treating some platforms as trusted, but because these platforms cannot consume IPsec policy, the server and domain isolation solution will not protect them. The following section addresses how to determine trust.
Management and Monitoring Devices One aspect of IPsec that is often overlooked during initial planning is its impact on management and monitoring of traffic on the network. Because IPsec requires authentication and can allow for encryption, some devices will no longer be able to monitor or manage IPsec enabled computers. In cases where encryption is required, an organization is asserting that security is more important than the operational need to monitor the data as it transits the network. In other cases, it will be necessary to evaluate what changes you can make to an application or device to enable IPsec monitoring (such as an ESP parser that can look at ESP traffic). If it is not possible to upgrade monitoring or management devices to support IPsec, it is vital that you record this information. The solution architect or architecture team will need to use this information in Chapter 4 "Designing and Planning Isolation Groups."
Trust Determination After obtaining information about the host devices that are currently part of your IT infrastructure, you must make a fundamental determination that will directly affect the ability of a host to participate in the solution. This determination is to decide at what point a host can be considered trusted. The term trusted can mean many different things to different people, so it is important to communicate a firm definition for it to all stakeholders in the project. Failure to do so can lead to problems with the security of the trusted environment, because the overall security cannot exceed the level of security set by the least secure client that is allowed to achieve trusted status.
60
Server and Domain Isolation Using IPsec and Group Policy
To understand this concept, consider the four basic states that are applicable to hosts in a typical IT infrastructure. These states are (in order of risk, lowest risk first): 1. Trusted 2. Trustworthy 3. Known, Untrusted 4. Unknown, Untrusted The remainder of this section defines these states and how to determine which hosts in your organization belong in which states.
Trusted State Classifying a host as trusted does not imply that the host is perfectly secure or invulnerable. Fundamentally, trusted implies that the host's security risks are managed. The responsibility for this managed state falls to the IT administrators and users who are responsible for the configuration of the host. A trusted host that is poorly managed will likely become a point of weakness for the entire solution. When a host is considered trusted, other trusted hosts should be able to reasonably assume that the host will not initiate a malicious act. For example, trusted hosts should expect that other trusted hosts will not execute a virus that attacks them, because all trusted hosts are required to use mechanisms (such as antivirus software) to mitigate the threat of viruses. Communication between trusted hosts should not be obstructed by the network infrastructure. For example, because a trusted host can assume that other trusted hosts have no malicious intent, the blocking of IP-level packets to restrict access by other trusted hosts is not generally required. You should implement any restrictions that are needed to control host communications by port or protocol by using a host-based firewall on the computer itself, not by using IPsec. In the Woodgrove Bank scenario, the security team defined the following five key goals that were used to plan what technologies would be required by a host to allow it to achieve trusted status: •
The computer's or user's identity has not been compromised.
•
The required resources are secure and available, regardless of where they reside in the managed environment. •
A resource that is designated as secure is tamper-free, virus-free, and free from unauthorized access.
•
A resource that is designated as available meets or exceeds promised levels of uptime and is free of security vulnerabilities.
•
An environment that is designated as managed has computers that are running Windows 2000 SP4 or later and that are properly configured and patched.
•
Data and communications are private, meaning that information is read and used only by intended recipients.
•
The device owner/operator understands and will comply with policies and procedures to ensure that the environment remains trustworthy.
•
There is a timely response to risks and threats.
The support team at Woodgrove Bank used these goals to define a set of technology requirements to determine whether a host could be considered trusted.
Chapter 3: Determining the Current State of Your IT Infrastructure
61
When defining the trusted status, ensure that asset owners are free to impose additional security requirements to meet the business needs of a specific asset. For example, your HR department may require an additional biometric logon mechanism for specific servers. This requirement will have no bearing on the ability of the servers to be trusted in the context of this solution. However, you should take care to ensure that the requirements of a specific asset do not conflict with the requirements of the trusted status. Spend some time defining the goals and technology requirements that your organization would consider suitable as the minimum configuration for a host to obtain trusted status. For example, the design team used the following list of technology requirements in the Woodgrove Bank scenario: •
Operating system. A trusted host should run Windows XP SP2 or Windows Server 2003, or, at a minimum, Windows 2000 SP4.
•
Domain membership. A trusted host will belong to a managed domain, which means that the IT department needs security management rights.
•
Management client. All trusted hosts must run a specific network management client to allow for centralized management and control of security policies, configurations, and software.
•
Antivirus software. All trusted clients will run antivirus software that is configured to check for and automatically update the latest virus signature files on a daily basis.
•
File system. All trusted hosts will be configured with the NTFS file system.
•
BIOS settings. All trusted mobile computers will be configured with a BIOS-level password that is under the management of the IT support team.
•
Password requirements. Trusted clients must use strong passwords.
It is important to understand that the trusted state is not constant; it is a transitive state that is subject to changing security standards and compliance with those standards. New threats and new defenses emerge constantly. For this reason, it is imperative that the organization's management systems continually check the trusted hosts to ensure ongoing compliance. Additionally, these systems should be capable of issuing updates or configuration changes if required to help maintain the trusted status. A host that continues to meet all these security requirements can be considered trusted. However it is very likely that most host computers that were identified in the discovery process discussed earlier in this chapter will not currently meet these requirements. Therefore, it is important to identify which hosts can become trusted and which ones cannot (and therefore must be considered untrusted). To help with this process, you can define an intermediate trustworthy state. The remainder of this section discusses the different states and their implications.
Trustworthy State It is useful to identify as soon as possible those hosts in your current infrastructure that will be able to achieve a trusted state, if necessary. A trustworthy state can be assigned to indicate that the current host is physically capable of achieving the trusted state with required software and configuration changes. For each computer that is assigned a trustworthy status, you should make an accompanying configuration note that records what would be required to allow the host to achieve trusted status. This information is especially important to both the project design team (to estimate the costs of adding the host to the solution) and the support staff (to enable them to apply the required configuration).
62
Server and Domain Isolation Using IPsec and Group Policy
Generally, trustworthy hosts will fall into one of the following two groups: •
Configuration required. The current hardware, operating system, and software allow the host to achieve a trustworthy state. However, additional configuration changes are required before the prerequisite security levels can be achieved. For example, if the organization requires a secure file system before a host can be considered trusted, a host with a FAT32-formatted hard disk would fail to meet this requirement.
•
Upgrade required. This group of computers will require system upgrades before it can be considered trusted. The following list provides some examples of the type of upgrade that computers in this group might require: •
Operating system upgrade required. If the host's current operating system cannot support the security needs of the organization, an upgrade would be required before the host could achieve a trusted state.
•
Software required. A host that is missing a required security application, such as an antivirus scanner or a management client, cannot be considered trusted until these applications are installed and active.
•
Hardware upgrade required. In some cases, a host may require a particular hardware upgrade before it can achieve trusted status. This type of host usually needs an operating system upgrade or additional software that forces the required hardware upgrade. For example, security software that requires additional storage space on the computer would prompt a requirement for more hard disk space.
•
Computer replacement required. This category is reserved for hosts that are unable to support the security requirements of the solution because their hardware cannot support the minimum acceptable configuration. For example, a computer that was unable to run a secure operating system because it has an old processor (such as a 100-megahertz [MHz] x86-based computer).
Use these groups to assign costs for implementing the solution on the computers that require upgrades.
Known, Untrusted State During the process of categorizing an organization's hosts, you will identify some hosts that cannot achieve trusted status for certain well-understood and well-defined reasons. These reasons may include the following types: •
Financial. The funding is not available to upgrade the hardware or software for this host.
•
Political. The host may have to remain in an untrusted state as a result of a political or business situation that does not allow it to comply with the stated minimum security requirements of the organization. It is highly recommended that you contact the business owner or independent software vendor (ISV) for the host to discuss the added value of server and domain isolation.
•
Functional. The host needs to run an insecure operating system or needs to operate in an insecure manner to perform its role. For example, the host may be required to run an older operating system because a specific line of business application will only work on that operating system.
Chapter 3: Determining the Current State of Your IT Infrastructure
63
There can be a number of functional reasons for a host to remain in the known untrusted state. The following list includes a few examples of functional reasons that may lead to a classification of this state: •
Computers that run Windows 9x or Windows Millennium Edition. Computers that run these particular versions of the Windows operating system cannot be classified as trustworthy because these operating systems do not support a basic security infrastructure. In fact, these operating systems have no security infrastructure by design. In addition, these operating systems have only rudimentary central management capabilities for user-specific computer configurations (through System Policy and user logon scripts). Finally, these operating systems provide none of the required security management capabilities.
•
Computers that run Windows NT. Computers that run Windows NT cannot be classified as trustworthy in the context of server and domain isolation because this operating system does not fully support a basic security infrastructure. For example, Windows NT does not support “deny” ACLs on local resources, any way to ensure the confidentiality and integrity of network communications, smart cards for strong authentication, or centralized management of computer configurations (although limited central management of user configurations is supported). Nor does Windows NT provide any way to protect the confidentiality of data and ensure its integrity (such as the Windows 2000 Encrypting File System).
In addition, Windows NT does not support all of the required security capabilities. For example, it does not support Group Policy or IPsec policies or provide a mechanism that ensures that local Administrator-level access can be obtained if needed. Also, its security configurations are not reapplied on a regular basis to ensure that they remain in effect. Note The discussion of Windows NT being untrustworthy is strictly in relation to the implementation of server and domain isolation and is not a reflection on its use as an operating system at large. For the servers in this project, upgrading to the Windows Server 2003 platform presents the most secure and manageable solution.
•
Stand-alone computers. Computers running any version of Windows that are configured as stand-alone computers or as members of a workgroup are usually unable to achieve a trustworthy state. Although these operating systems may fully support the minimum required basic security infrastructure, the required security management capabilities are unlikely to be achievable when the computer is not a part of a trusted domain.
•
Computers in an untrusted domain. A computer that is a member of a domain that is not trusted by an organization's IT department cannot be classified as trusted. An untrusted domain is a domain that cannot provide the required security capabilities to its members. Although the operating systems of computers that are members of this untrusted domain may fully support the minimum required basic security infrastructure, the required security management capabilities cannot be fully guaranteed when computers are not in a trusted domain. For example, in an untrusted domain, there is no available mechanism to ensure that local Administratorlevel access by a trusted user can be obtained if needed. Also, security configurations (even those that can be centrally managed) can be easily overridden by the untrusted domain’s administrators. Additionally, adherence to security configuration, software, policies, and standards cannot be assured, and measures to effectively monitor compliance are not available.
•
Computers in a Windows NT domain. Computers that are members of a domain based on Windows NT cannot be classified as trusted. Although their operating systems may fully support the minimum required basic security infrastructure, the required security management capabilities are not fully supported when the computers are in a Windows NT domain.
64
Server and Domain Isolation Using IPsec and Group Policy
However, if the host has to be accounted for in the design because it provides a required role for the organization, you should assign it a status of known, untrusted. What this means is that a risk has been identified that the solution cannot mitigate. You must use additional techniques to mitigate this known threat. Because of the varied nature of hosts in this category, specific guidance on these techniques cannot be provided. However, the goal of these mitigation techniques should be to minimize the risk posed by this host.
Unknown, Untrusted State The unknown, untrusted state should be considered the default state for all hosts. Because hosts in this state have a configuration that is unknown, you can assign no trust to them. All planning for hosts in this state should assume that the host has been or is capable of being compromised and is therefore an unacceptable risk to the organization. Designers of the solution should strive to minimize the impact that the computers in this state can have on their organizations.
Capturing Upgrade Costs for Current Hosts The final step in this chapter is the process of recording the approximate cost of upgrading the computers to a point that they are capable of participating in the solution. You must make several key decisions during the design phase of the project that require answers to the following questions: •
Does the computer meet the minimum hardware requirements necessary for isolation?
•
Does the computer meet the minimum software requirements necessary for isolation?
•
What configuration changes need to be made to integrate this computer into the isolation solution?
•
What is the projected cost or impact of making the proposed changes to allow the computer to achieve a trusted state?
By answering these questions, you can quickly determine the level of effort and approximate cost of bringing a particular host or group of hosts into the scope of the project. It is very likely that no single person—or even several people within one role—will gather all of this data. Some of it may be gathered by help desk or field service technicians, whereas other data will need an architect or business sponsor-level input. It is important to remember that the state of a computer is transitive, and that by performing the listed remedial actions you can change the state of a computer from untrusted to trusted. After you decide whether to place a computer in a trusted state, you are ready to begin planning and designing the isolation groups, which Chapter 4, "Designing and Planning Isolation Groups" in this guide discusses.
Chapter 3: Determining the Current State of Your IT Infrastructure
65
The following table is an example of a data sheet that you could use to help capture the current state of a host and what would be required for the host to achieve a trusted state. Table 3.3 Sample Host Collection Data Host name
Hardware reqs met
Software reqs met
Configuration Details required
Projected cost
HOSTNYC-001
No
No
Upgrade hardware and software.
Current operating system is Windows NT 4.0. Old hardware is not compatible with Windows XP SP2.
$XXX.
SERVERLON-001
Yes
No
Join trusted domain and upgrade from Windows NT 4.0 to Windows 2000 SP4 or later.
No antivirus software present.
$XXX.
The following list explains each column from Table 3.3: •
Host name. The name of the host device on the network.
•
Hardware requirements met. Reflects whether a computer meets the minimum hardware requirements to participate in the solution.
•
Software requirements met. Reflects whether a computer meets the minimum software requirements to participate in the solution. At Woodgrove Bank, the minimum was Windows 2000 SP4, Windows XP SP2, or Windows Server 2003, as well as all critical security patches for each operating system. In addition, computers had to be in a trusted domain (that is, a domain centrally managed by Woodgrove Bank IT staff) and must specifically provide IT administrators with access to the computer.
•
Configuration required. Indicates what action must be taken for the computer to achieve a trusted state.
•
Details. Describes why the computer is not currently in a trusted state.
•
Projected cost. Indicates the projected cost for the device to achieve a trusted state. This cost should include estimates for software, hardware, lost productivity, and support. This information will help determine whether it is practical or worthwhile from a business perspective to add a particular computer into the solution as a trusted computer.
In the previous table, the host HOST-NYC-001 is currently "known, untrusted." However, it could be considered trustworthy if the required upgrades are possible. However, if a large number of computers require the same upgrades, the overall cost of the solution would be considerably higher.
66
Server and Domain Isolation Using IPsec and Group Policy
The host SERVER-LON-001 meets the hardware requirements but needs to be upgraded to an operating system that is capable of consuming IPsec policy and is domain-joined. It also requires antivirus software. The projected cost is the amount of effort that is required to upgrade the operating system and install antivirus software combined with the cost of the operating system and antivirus software licenses. After obtaining the information described in Table 3.3, save it with the other information that you have gathered in this chapter so that it the architect or architecture team can use it. This information will be the foundation of the efforts undertaken in Chapter 4, which focuses on designing the isolation groups. It should be noted that the costs identified in this section only capture the projected cost of the host upgrades. There are many additional design, support, test, and training costs that will be associated with the project. These additional costs will need to be accounted for in the overall project plan if an accurate project cost is to be identified.
Summary This chapter provided an overview of the information that is required to conduct a server and domain isolation project, including impact considerations. You can use the guidance in this chapter to perform the following tasks: •
Identify assets on the network
•
Gather network information
•
Gather host information
•
Determine current traffic information
•
Examine the current Active Directory architecture and obtain pertinent information from it
•
Examine IPsec capacity considerations
•
View the pre-deployment considerations for IPsec
•
Explain what trustworthy and untrustworthy devices are and how they were categorized in the Woodgrove Bank scenario
Accomplishment of these tasks will gather all of the information that you need to begin the isolation group design in the following chapter.
Chapter 3: Determining the Current State of Your IT Infrastructure
67
More Information This section provides links to areas of additional information that may prove helpful in implementing this solution: •
For more information about configuring firewalls to support IPsec for Windows Server 2003, see Configuring Firewalls.
•
You can download the Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0) from the Microsoft Download Center.
•
For more information about WMI, see Windows Management Instrumentation.
•
You can download the Microsoft Windows Script 5.6 for Windows 2000 and XP from the Microsoft Download Center.
•
You can download the Microsoft Windows Script 5.6 for Windows 98, Windows Millennium Edition and Windows NT 4.0 from the Microsoft Download Center.
•
You can download the Windows Script 5.6 Documentation from the Microsoft Download Center.
Chapter 4: Designing and Planning Isolation Groups This chapter provides complete guidance for defining isolation groups that fulfill the business security requirements discussed in Chapter 2, "Understanding Server and Domain Isolation." This solution uses a combination of the computer identity in the Active Directory® directory service domain, IPsec policy to authenticate this identity, and Microsoft® Windows® security policy to define and enforce isolation groups. Information technology (IT) administrators can use the concept of isolation groups to manage network traffic within their internal networks in a secure manner that is transparent to applications. This capability can significantly reduce the threat of damage from networkborne infections and attacks. Through the Woodgrove Bank scenario, this guide shows the essential details of how an organization can turn its security requirements into deployed isolation groups. In addition, this guide shows how IPsec can be combined with other security settings to build a detailed, manageable, and scalable server and domain isolation solution. Every business will have unique requirements for their solution, and the models in this guidance are not designed to be followed without question or modification. Organizations that use this guide will need to determine what is required and achievable for their own environments and make appropriate changes to the isolation group model design to ensure the best fit for their own business requirements.
Chapter Prerequisites This section contains information that will help you determine your organization's approach to the server and domain isolation solution. Successful completion of such a solution for your organization is dependent on the prerequisites identified in this section.
Knowledge Prerequisites You should be familiar with concepts and terminology of IPsec. Familiarity with Microsoft Windows Server™ 2003 is also required in the following areas: •
IPsec policy, IPsec filters, filter actions, and filter lists
•
Active Directory concepts (including Active Directory structure and tools; manipulating users, groups, and other Active Directory objects; name resolution services; and use of Group Policy)
•
Authentication concepts including the Windows logon process and the Kerberos version 5 protocol
•
Windows system security (including security concepts such as users, groups, auditing, and access control lists [ACL]; the use of security templates; and the application of security templates using Group Policy or command-line tools)
Before proceeding with this chapter, you should also have read the previous chapters in this guide.
Organizational Prerequisites You should consult with other members of your organization who may need to be involved in the implementation of this solution, including the following people: •
Executive sponsors
•
Security and audit personnel
•
Active Directory engineering, administration, and operations personnel
•
Domain Name System (DNS), Web server, and network engineering administration and operations personnel
Note Depending on the structure of your IT organization, these roles may be filled by a number of people, or fewer people may span several roles. However, it is important to identify a single point of contact to help coordinate the efforts of cross-organization teams through the various phases of the project.
This chapter also assumes that you have met the requirements listed in Chapter 2, "Understanding Server and Domain Isolation," and Chapter 3, "Determining the Current State of Your IT Infrastructure." These requirements include gathering information from the hosts, the network, and Active Directory. The gathering of business requirements and obtaining business sponsorship are also discussed. Finally, you must have in place a plan to train the various help desk and support staff on the new concepts, terminologies, and technologies of this solution. Because this solution will affect many areas of the organization, support staff should be trained to handle any issues that arise during deployment.
IT Infrastructure Prerequisites This chapter assumes that a Windows Server 2003 Active Directory domain infrastructure exists, running in mixed or native mode. This solution uses universal groups for Group Policy object application. If the organization is not running in mixed or native mode, it is still possible to apply the Group Policy object (GPO) through the use of standard global and local group configurations. However, because this option is more complex to manage, this solution does not use it. Note Windows Server 2003 introduced a number of improvements that affect IPsec policies. There is nothing specific to this solution that would keep it from working with Windows 2000. However, the solution was only tested using Windows Server 2003 Active Directory.
For more information about the enhancements made to IPsec in Windows Server 2003, see New features for IPSec.
Creating the Server and Domain Isolation Design The design of the solution depends heavily on the business requirements and the information gathered in the previous chapters. Chapter 2, "Understanding Server and Domain Isolation," and Appendix D: "IT Threat Categories," explain the components of the solution and identify the threats that it can and cannot address. Chapter 3, "Determining the Current State of Your IT Infrastructure," provides information about how to gather planning data, such as the current network architecture and host assets in the network. This chapter uses the information and requirements gathered for Woodgrove Bank, which are recorded in detail in Business_Requirements.xls (available in the Tools and Templates folder). You should reference this file during the design process that
Chapter 4: Designing and Planning Isolation Groups
71
this chapter details to better understand the reasons behind the solution's design. The solution design process involves the following primary tasks: •
Modeling foundational groups
•
Planning computer and network access groups (NAG)
•
Creating additional isolation groups
•
Modeling network traffic requirements
•
Assigning computer group and NAG memberships
The following sections explain each of these tasks.
Modeling Foundational Groups For most implementations, it is recommended that you have a common starting point for the initial isolation groups. The following figure presents the two initial isolation groups that you should consider.
Figure 4.1 Foundation isolation groups Foundational groups provide logical containers that are an excellent starting point for the isolation group design.
Untrusted Systems Conceptually, the best place to start is with those computers that are not owned, managed, or even known to exist by the organization's IT department. These computers are generally referred to as untrusted or unmanaged hosts and are the first systems to identify in the design. These computers will not be part of the solution because they will not be able to use the domain-assigned IPsec policies.
72
Server and Domain Isolation Using IPsec and Group Policy
Examples of computers that would fall into this group include: •
Non-Windows-based computers and devices. Macintosh and UNIX workstations and personal digital assistants (PDA) may not have readily available IPsec capabilities.
•
Older versions of the Windows operating system. Computers running Microsoft Windows NT® version 4.0 and Windows 9x cannot use Group Policy-based IPsec.
•
Windows-based computers not joined to a trusted domain. Stand-alone computers will not be able to authenticate using Kerberos domain trust in Internet key exchange (IKE). A computer that is joined to a domain that is not trusted by the forest being used as the trust boundary for IKE authentication will not be able to participate in the domain or server isolation solution.
•
Other non-Microsoft remote access or VPN clients. If a non-Microsoft IPsec virtual private network (VPN) client is being used for an organization's remote access solution, the installation likely disabled the native Windows IPsec service. If the native Windows IPsec service cannot be used, the host will not be able to participate in this solution.
Even if the native Windows IPsec service is running, the VPN client should permit IKE and IPsec communication end-to-end through the VPN tunnel connection. If end-to-end IPsec does not work through the VPN connection, it is possible to create an exemption for all IP subnets used for remote access. When this remote client reconnects to the internal network, it can again participate in the isolation solution.
Isolation Domain The isolation domain provides the first logical container for trusted hosts. The hosts in this group use IPsec policy to control the communications that are allowed to and from themselves. The term domain is used in this context to illustrate boundary of trust rather than to suggest a Windows domain. In this solution the two constructs are very similar because Windows domain authentication (Kerberos) is required for accepting inbound connections from trusted hosts. However, many Windows domains (or forests) may be linked with trust relationships to provide a single logical isolation domain. So they should not be considered one and the same. The aim for the communications characteristics of the isolation domain is to provide the "normal" or standard rules for the majority of the organization's computers. In this way, for most implementations, an isolation domain will contain the largest number of computers. Other isolation groups can be created for the solution if their communication requirements are different from those of the isolation domain. Conceptually, an isolation domain is just a type of isolation group.
Boundary Group In almost all organizations, there will be a number of workstations, or servers, that are unable to communicate using IPsec. For example, computers such as Mac or UNIX workstations are unlikely to be able to communicate using IPsec. Often, business requirements exist for these computers to communicate with trusted hosts in the isolation domain. Perhaps in an ideal world, all hosts on the internal network would be able to be trusted to the same level and to use IPsec, and the design would be simpler. However, the reality is that not all operating systems provide the same degree of support for IPsec. The recommended way to deal with this situation is to create an isolation group (referred to as the Boundary group in this guide) that contains hosts that will be allowed to communicate with untrusted systems. These hosts will be exposed to a higher level of risk because they are able to receive incoming communications directly from untrusted computers.
Chapter 4: Designing and Planning Isolation Groups
73
Computers in the Boundary group are trusted hosts that can communicate both with other trusted hosts and with untrusted hosts. Boundary hosts will attempt to communicate using IPsec by initiating an IKE negotiation to the originating computer. If no IKE response is received within three seconds, the host will Fall back to clear and begin attempting to establish communications in plaintext without IPsec. Because these Boundary group hosts will be allowed to communicate with trusted hosts that use IPsecsecured network communications and untrusted hosts that use fall back to clear, they must be highly secured in other ways. Understanding and mitigating this additional risk should be an important part of the process of deciding whether to place a computer in the Boundary group. For example, setting up a formal business justification process for each computer before agreeing to place it in this group can help ensure that all interested parties understand why the additional risk is required. The following figure illustrates a sample process that can help make such a decision.
Figure 4.2 Boundary Group Membership Justification Process
74
Server and Domain Isolation Using IPsec and Group Policy
The goal of this process is to determine whether the risk of adding a host to the Boundary group can be mitigated to a level that makes it acceptable to the organization. Ultimately, it should be assumed that if the risk cannot be mitigated, membership should be denied.
Creating Exemptions Lists The server and domain isolation security models all run into a few constraints when they are implemented in a live environment. Key infrastructure servers such as domain controllers, DNS servers, and Dynamic Host Configuration Protocol (DHCP) servers are usually available to all systems on the internal network. Clearly they must be secured to the maximum extent possible from network attacks. However, because they are available to all systems on the network, not just to domain members, these server services cannot require IPsec for inbound access, nor can they take advantage of using IPsec transport mode protection for all of their traffic. Because a three-second fall back to clear for access to these services, particularly DNS, would severely impact the performance of all internal network access, they are not candidates for the Boundary group. Also, trusted hosts require access to the DHCP server to get an Internet Protocol (IP) address during computer startup or when the network cable or card is plugged in to a mobile computer. Trusted hosts also require DNS to locate the domain controllers so they can log on to the domain and receive Kerberos credentials. Therefore, a list of servers and services (protocols) that are exempt from using IPsec will be required for IPsec to work properly, as well as to permit all internal hosts to share the common internal network infrastructure. The list of computers that cannot be secured with IPsec is called an exemption list and is implemented in each IPsec policy designed. There may also be other servers on the network that trusted hosts cannot use IPsec to access, which would be added to the exemption list. Generally, the following conditions might cause a host to be in the exemptions list: •
If the host is a computer to which trusted hosts require access but it does not have a compatible IPsec implementation.
•
If the host provides services for untrusted hosts and trusted hosts but does not meet the criteria for membership of the Boundary isolation group.
•
If the host is used for an application that is adversely affected by the three-second fall back to clear delay or by IPsec encapsulation of application traffic.
•
If the host supports many thousands of clients simultaneously and it has been found that IPsec cannot be used due to the performance impact.
•
If the host supports trusted hosts from different isolation domains that do not trust each other.
•
If the host is a domain controller, because IPsec between a domain controller and a domain member is currently not supported. However, domain controllers meet other criteria in this list and also provide the IPsec policy to the domain members and the Kerberos authentication that the isolation concept is based on.
•
If the host supports trusted and untrusted hosts but will never use IPsec to secure communications to trusted hosts.
The IPsec implementation in Windows supports only static filtering, not dynamic (or stateful) filtering. Therefore, a static exemption for outbound traffic is also a static exemption for inbound traffic. Exempted hosts therefore have unauthenticated inbound access to every host, trusted or untrusted. Thus, the number of exempted hosts must be kept to a minimum, and these hosts must be closely managed and hardened as much as possible against attacks and infections. To help mitigate the risk of inbound attacks from hosts in the exemption list, a host-based stateful filtering firewall, such as Windows Firewall, can be used. Windows XP Service Pack (SP) 2 provided domain-based Group Policy controls for configuring the firewall. Windows Firewall also supports the capability
Chapter 4: Designing and Planning Isolation Groups
75
to authorize only certain computers through the firewall when protected by IPsec, using the policy setting "Windows Firewall: Allow authenticated IPsec bypass." Woodgrove Bank chose not to implement Windows Firewall capability. However, other environments may find it necessary to achieve high levels of security within an isolated domain or group. For more information, see the “Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2” white paper on the Microsoft Download Center. For large organizations, the list of exemptions may grow quite large if all the exemptions are implemented by one IPsec policy for the entire domain or for all trusted forests. A large list has a number of unwanted effects on every computer that receives the policy, including the following: •
Reduces the overall effectiveness of isolation
•
Creates a greater management burden (because of frequent updates)
•
Increases the size of the policy, which means that it consumes more memory and CPU resources, slows down network throughput, and increases the time require to download and apply the policy
To keep the number of exemptions as small as possible, several options exist: •
Do not use an exemption if communications can withstand the three-second delay of Fall back to clear. This option does not apply to domain controllers.
•
Carefully consider the communications requirements of each isolation group, particularly server-only groups. They might not be required to communicate with every exemption in the domain-level policy for clients.
•
Consolidate server functions. If several exempt services can be hosted at one IP address, the number of filters will be reduced.
•
Consolidate exempted hosts on the same subnet. Where network traffic volume will permit, the servers might be able to reside on a subnet that is exempted, rather than using exemptions for each IP address.
As with defining the Boundary group, there should be a formal process to approve hosts being added to the exemption list. Refer to the decision flow in the previous figure as a model for processing requests for exemptions.
Planning the Computer and Network Access Groups The isolation domain and each isolation group must have clear and complete specifications of network security requirements. The Business_Requirements.xls spreadsheet in the Tools and Templates folder provides a model for how requirements can be documented. After inbound and outbound requirements are documented, you can design the mechanisms for implementing access controls. At this point in the process, you should start a record of the new Active Directory groups that will be required to support the isolation group requirements. For each isolation group, you will need to create up to three specialized Active Directory groups. The following section explains the role of each of these groups.
Computer Groups Each isolation group will require a computer group to be created that will be used to contain the members of the isolation group. This is required because the security requirements for an isolation group are met by several types of security settings in GPOs assigned in the domain. For example, this solution uses security group filtering on the GPOs to deliver an IPsec policy to the computers in a particular isolation group.
76
Server and Domain Isolation Using IPsec and Group Policy
Computer accounts that are members of the computer group will be assigned the associated IPsec policy when the GPO is processed. This is to avoid having to change or create a new organizational unit (OU) structure based on isolation group membership to apply the proper GPOs. If the OU structure can be changed to reflect the isolation group membership, these computer security groups are not needed to control the application of Group Policy. Table 4.1 Woodgrove Bank Computer Groups Computer group name
Description
CG_IsolationDomain_Computers
This universal group will contain all computers that are part of the isolation domain.
CG_BoundaryIG_Computers
This group will contain all computers that are allowed to accept communication from untrusted systems.
Network Access Groups Using IPsec and Kerberos alone provides a trusted and untrusted authentication boundary. To help differentiate this group from any other groups, this guide refers to these groups as network access groups (NAG). There are two types of NAGs that you can create: Allow and Deny. It is these groups that control the ability of other trusted systems to either explicitly allow or deny access. You achieve this control by using either the "Deny access to this computer from the network" (DENY) or the "Access this computer from the network" (ALLOW) user right in Group Policy. Technically, this user right access control only applies to network services that receive logon credentials to authenticate the account for network logon. The "account" may be a computer, user, or service account. When IPsec policy is configured to protect all traffic IKE will confirm that the remote computer has a network logon right. Therefore, the network logon right now controls the ability for a remote computer to make any IPsec protected connections. After this IP-level access control has been checked, the normal upper layer protocols (for example, file sharing) typically authenticate the user, which again evaluates the network logon rights of the user identity. Finally, service-specific permissions (such as file share access control lists) are evaluated using the user identity. For more information, see the Network Access Control Layers diagram in Chapter 2, "Understanding Server and Domain Isolation." By default, the ALLOW user right contains the Everyone group, which allows all authenticated users and computers to access the computer. During the implementation of this solution, the Everyone group will be replaced through Group Policy user rights assignment with NAGs that contain specific computers or users and groups, depending on organizational requirements. Likewise, the DENY user right will have computers that are not supposed to have IPsec-protected inbound access. Although it is possible to use a single group to contain user and computer accounts, Microsoft recommends using separate groups, one for users and one for computers. This approach improves the ability to manage and support these policies and groups on an ongoing basis. The configuration of user rights assignment for ALLOW and DENY supplements the guidance that earlier Windows platform security guides provide, because those guides did not specifically accommodate computer authentication that IPsec requires.
Chapter 4: Designing and Planning Isolation Groups
77
The requirements that NAGs might implement include the following: •
Blocking network access to sensitive servers from boundary hosts or trusted hosts located in public areas
•
Limiting access to servers dedicated to senior executives to just the client computers that those executives use
•
Isolating trusted hosts in a research and development project from all other trusted hosts in the domain
In the Woodgrove Bank scenario, one business requirement set a limit on the amount of new computer hardware that could be purchased for the year. A print server was needed to allow both trusted hosts and untrusted hosts to print. Although Woodgrove would have preferred to purchase a new server that only untrusted computers would use for printing, Woodgrove decided that one server could fulfill the needs of both types of hosts. Therefore, it created a boundary server as a print server. Because the print server was at higher risk of being infected and attacked from untrusted computers, the rest of the trusted hosts would need to block inbound access from that server. Trusted hosts would still be able to make outbound connections to the print server when needed. Accordingly, Woodgrove determined that it needed a DENY NAG to implement this requirement. At this stage of the design process, assigning NAG membership is not required. All that is needed is to identify and document the NAGs that the design will require. The designers at Woodgrove Bank identified a need for the following NAG: Table 4.2 Woodgrove Bank Network Access Groups NAG Name
Description
DNAG_IsolationDomain_Computers
This group includes any domain computer account that is denied from making inbound IPsec-protected connections to all trusted hosts in the isolation domain.
Creating Additional Isolation Groups At this point in the design process, there are two isolation groups: the isolation domain and the boundary group. If your organization's business requirements can be satisfied by this design, you can continue to the next section of this chapter to define the traffic models for these two isolation groups. However, if your organization requires some trusted hosts to have different inbound or outbound network access controls or traffic protection, isolation groups will be required for each different set of requirements. The purpose of this section is to help you understand when additional groups will be required. The first thing to do is to identify which computers have specific isolation or traffic protection requirements that are not met by the settings for the isolation domain. The goal should be to keep the number of these hosts to a minimum, because each new group will increase the complexity of the overall design and therefore make it more difficult to support and manage.
78
Server and Domain Isolation Using IPsec and Group Policy
Typical examples of requirements that might lead to creation of a new group include the following: •
Encryption requirements
•
Limited host or user access required at the network level
•
Outgoing or incoming network traffic flow or protection requirements that differ from the isolation domain
In many cases, the inbound access requirements of servers that contain high value data are to allow only a subset of trusted hosts in the domain to connect. In other cases, trusted hosts might not be allowed to make outbound connections to untrusted computers to reduce the risk of information leakage or to enforce regulatory compliance for the protection of network traffic. For example, in the Woodgrove Bank scenario, the designers identified requirements that could only be fulfilled by the creation of the following two additional isolation groups: •
The Encryption group contained a small group of application servers with high value data that required the highest level of protection. Only a specific subset of trusted clients would be allowed to connect inbound to these servers. All network traffic with these servers required 128-bit-level encryption that was compliant with U.S. federal regulations for financial data privacy. Lastly, these servers were not allowed to make outbound connections to untrusted hosts or to receive inbound connections from boundary hosts.
•
The No Fallback group was required for a number of trusted hosts in the isolation domain that needed to be restricted from network communications to untrusted systems.
Although the second group has a no fallback requirement, they do not have the full set of requirements that the applications servers do. Thus, these two different sets of requirements indicated that two additional isolation groups were required. These additional groups brought the total group count for Woodgrove Bank to four. The following figure shows how these groups looked in the final Woodgrove Bank isolation group design:
Figure 4.3 Final Woodgrove Bank group design
Chapter 4: Designing and Planning Isolation Groups
79
The following four groups require policy to achieve the design requirements: •
Isolation Domain. This is the default group for all trusted computers.
•
Boundary Isolation Group. This group is assigned for computers that require the ability for untrusted hosts to access them.
•
Encryption Isolation Group. This group only allows communications through a trusted, encrypted communications path.
•
No Fallback Isolation Group. This group contains computers that have a higher security requirement that dictates that they not be allowed the ability to initiate communications to untrusted hosts directly.
Because Woodgrove Bank identified two additional groups that require IPsec policies, it defined additional computer groups to control the application of these newly identified policies. Table 4.3 Additional Woodgrove Bank Computer Groups Computer Group Name
Description
CG_NoFallbackIG_Computers
This group contains all computers that are not allowed to Fall back to clear.
CG_EncryptionIG_Computers
This group contains all computers that are required to use encryption.
Accordingly, Woodgrove determined that it would need NAGs to authorize inbound access for the subset of trusted hosts. The designers at Woodgrove Bank created the following NAGs: Table 4.4 Woodgrove Bank Network Access Groups NAG name
Description
ANAG_EncryptedResourceAccess_Users
This group includes all users who are authorized to have access to the Encryption isolation group servers.
ANAG_EncryptedResourceAccess_Computers This group contains all computers that are authorized to have inbound network access to the Encryption isolation group servers. DNAG_EncryptionIG_Computers
This group includes groups of computer accounts that are to be denied access to hosts in the Encryption isolation group.
Gathering Network Traffic Requirements At this point in the design process, you should document the communications traffic requirements that will be allowed to pass between the groups, along with the form that the communications will take. There are many ways to record the traffic requirements for the groups. However, the Microsoft IT support team found, as part of their own experience, the creation of a diagram was the best method for communication of the exact requirements.
80
Server and Domain Isolation Using IPsec and Group Policy
The following figure depicts the communications paths that are typically allowed between the foundational groups, the untrusted hosts, and the exemptions lists. To simplify this model, the exemptions lists are shown as a single grouping. This is typically the case for infrastructure services, such as Domain Controllers or DNS servers. However, isolation groups may have a business requirement to exempt specific computers just for the computers in that group. In these cases, the isolation group would then contain an additional exemption list of the computers that are to be exempted in addition to the common exemptions. Microsoft recommends keeping the exemption list entries to a minimum because they explicitly exempt systems from participating in the IPsec infrastructure. In the figure, all arrows shown in a solid black line use IPsec for their communications; the dotted lines indicate communications that are allowed to occur without IPsec. Groups that are depicted with a bold dashed line have an IPsec policy assigned to the computers in that group.
Figure 4.4 Typical allowed communications paths for foundational isolation groups
Chapter 4: Designing and Planning Isolation Groups
81
The following table records the allowed communications paths for the traffic among the foundational groups, unsecured systems, and the exemptions lists: Table 4.5 Allowed Communication Options for Foundational Isolation Groups Path
From
To
Bidirectional Try IKE/IPsec
Fall back
Encrypt
1
ID
EX
Yes
No
No
No
2
ID
BO
Yes
Yes
No
No
3
ID
UN
No
Yes
Yes
No
4
BO
EX
Yes
No
No
No
5
BO
UN
No
Yes
Yes
No
6
UN
BO
No
No
No
No
7
UN
EX
Yes
No
No
No
The previous table records the communications requirements for each allowed communications path in the initial isolation group design. The following list explains each column: •
Path. The number assigned to the communications path illustrated in the group diagram.
•
From. The group that contains the initiators of the traffic.
•
To. The group that contains the responders that will be contacted through the allowed communication path.
•
Bidirectional. Indicates whether the path allows the roles of the initiator and responder to be reversed so that traffic can start from either the From or the To group.
•
Try IKE/IPsec. Indicates whether this path attempts to use IPsec to secure the communications.
•
Fall back. Indicates whether the communications can revert to not using IPsec if the IKE negotiation fails to complete.
•
Encrypt. Indicates whether this path requires the communications to be encrypted by using an encryption algorithm set in the IPsec policy.
The short forms of the group names were used to keep the information in the table as concise as possible. By using this form of documentation, it is possible to create a very concise representation of the solution's communications. By assuming that all network traffic is disallowed unless specifically identified in this table, the process of identifying the traffic that will be protected as part of the solution becomes much clearer. In the example shown in the previous figure, each of the following allowed paths is explained: •
Traffic paths 1, 4, and 7 illustrate the network communications that are specifically permitted for all hosts listed by the Exemptions lists in their IPsec policy. The specific exemptions may be different for isolation groups.
•
Traffic path 2 shows the communications between the isolation domain and Boundary groups. This path attempts to use IPsec to protect the traffic. The traffic may require encryption, depending on the security requirements. If the IKE negotiation fails, the communications will fail because there is no Fall back to clear option when IKE fails a negotiation.
82
Server and Domain Isolation Using IPsec and Group Policy
•
Traffic path 3 shows that the hosts in the isolation domain are able to initiate communications with untrusted hosts. This is possible because the policy for this group will allow the isolation domain hosts to Fall back to clear if there is no reply to the initial IKE negotiation request. Untrusted systems that attempt to initiate nonIPsec connections with trusted hosts are blocked by the IPsec inbound filters.
•
Traffic paths 5 and 6 document the allowed communications between the Boundary group and untrusted systems. Path 4 shows that the Boundary group is allowed to communicate outbound with untrusted hosts in the clear. If the IKE negotiation is not responded to, the host will Fall back to clear text communications. Path 5 covers the traffic initiated from the untrusted hosts to the Boundary group. Although this arrow looks similar to path 4, the details in the table illustrate that the untrusted hosts are not attempting IKE negotiation with the Boundary group. They are connecting with clear text TCP/IP connections.
After the foundational communications have been documented, additional groups can be added to the overall plan and their communications requirements recorded in the same way. For example, the two additional groups required by the Woodgrove Bank scenario led to a more complex communications diagram, as shown in the following figure.
Figure 4.5 Woodgrove Bank-allowed communications paths for isolation groups The following table records the allowed communications paths for the traffic in the additional groups for the Woodgrove Bank scenario.
Chapter 4: Designing and Planning Isolation Groups
83
Table 4.6 Allowed Communication Options for Additional Isolation Groups Path
From
To
Bidirectional Try IKE/IPsec
Fall back
Encrypt
8
EN
EX
Yes
No
No
No
9
EN
ID
Yes
Yes
No
Yes
10
EN
NC
Yes
Yes
No
Yes
11
EN
BO
No
Yes
No
Yes
12
NF
ID
Yes
Yes
No
No
13
NF
EX
Yes
No
No
No
14
NF
BO
Yes
Yes
No
No
In the example shown in the previous figure and described in the previous table, each of the following additional allowed paths is explained: •
Paths 8 and 13 are clear communications for all exempted traffic.
•
Paths 9 and 10 show the IPsec Encapsulating Security Payload (ESP)-encrypted communications that is required between the Encryption, No Fallback, and isolation domain groups. If the IKE negotiation fails to secure the communication using encryption, the communication attempt fails.
•
The traffic for path 11 is slightly different because it only allows communications to be initiated from the Encryption group to the Boundary group and not the reverse. This is because Woodgrove Bank placed high value data in the Encryption group and does not want that data to be exposed to computers that are accessed directly by untrusted resources.
•
The traffic paths for 12 and 14 could be implemented by either IPsec AH transport mode, or IPsec ESP transport mode that is authenticated but without encryption (ESP-Null).
As this example illustrates, adding groups can have an exponential impact on the complexity of the solution. For this reason, it is recommended that the number of groups be kept to a minimum, especially during the early stages of a deployment when the most change is being introduced.
Assigning Computer Group and Network Access Group Memberships After the traffic requirements are detailed and documented in the design, the next task is to identify which hosts will be members of which computer group or NAG. As mentioned previously, computer groups are used in this solution to apply the GPO that contains the associated IPsec policy. After determining that a computer must belong to a particular isolation group, that computer's account is added to the computer group for that isolation group. For the isolation domain, this step is not required, because all domain computers implicitly belong in the isolation domain computer group. Membership in a NAG will be based on the inbound authorization that the NAG implements. For example, if a NAG exists to restrict communication for a particular server to a known set of clients, the client computer accounts need to be placed in the appropriate NAG. NAGs are only created when needed, and therefore they have no default configuration.
84
Server and Domain Isolation Using IPsec and Group Policy
Computer Group Membership It is important that a host should not be represented in more than one computer group, because the computer group is used to control which GPOs apply. Although it might be theoretically possible to modify the policies to allow a host to belong to more than one computer group, the complexity of such an approach would rapidly make the solution unsupportable. Generally, this task of determining computer group membership is not complicated, but it can be time consuming. You should use the information generated from an audit such as the one performed in Chapter 3, "Determining the Current State of Your IT Infrastructure," of this guide to place each host into one computer group based on the isolation group membership of that host. You can determine this placement by adding a Group column to record the computer group membership for the final design, as shown in the following table: Table 4.7 Sample Host Collection Data Host name
Hardware Software reqs reqs met? met?
Configuration Details required
HOSTNYC-001
No
No
Upgrade both hardware and software
Current $XXX. operating system is Windows NT 4.0. Old hardware not compatible with Windows XP.
ID
No
Join Trusted domain, upgrade from NT 4 to Windows 2000 or later
No antivirus software present.
EN
SERVER- Yes LON-001
Projected Group cost
$XXX.
Network Access Group Membership The final step in this design process is to populate the membership of the NAGs identified earlier in this chapter. Although a trusted host should only belong to one computer group, it is possible for a trusted host to be a member of multiple NAGs. Try to use as few NAGs as possible to limit the complexity of the solution. When assigning membership to a NAG for user accounts, decide how tightly you want to control the access. For a resource that is already using standard share and file permissions to ensure the correct level of control, the simplest way to assign membership would be to assign the user's NAG membership to Domain Users from each trusted domain in the forest that requires access to the resource. This approach almost restores the behavior of the original default value of Authenticated Users but does not include local user accounts. If local user or service accounts are required, then a domain-based GPO may not be the best approach to configure ALLOW and DENY network logon rights. The ALLOW and DENY user rights assignment do not merge settings among several
Chapter 4: Designing and Planning Isolation Groups
85
GPOs. Therefore, this computer should be prevented from having the domain-based GPO assigned for ALLOW and DENY and should use a customized local GPO. If the domain-based GPO that delivers IPsec policy assignment is different from the GPO used to deliver network logon rights, the domain-based GPO for IPsec policy assignment can still be used. In addition, decide how to implement the inbound access requirements using either an ALLOW NAG or a DENY NAG or both. Deciding which type of NAG to create is based solely on what the intended behavior is and what minimizes administrative effort. It may be helpful to have a pre-existing but empty DENY NAG for users and a DENY NAG for computers already populated in the GPO "Deny access to this computer from the network" right. For high-security scenarios, the membership of user NAGs can be assigned to specific users or groups. If this method is used, it should be understood that users who are not members of this group will be blocked from accessing the computer over the network, even if they are members of the local administrators group and have full control on all share and file permissions. For the Woodgrove Bank scenario, NAG_EncryptedResourceAccess_Users membership was assigned to Domain Users and recorded as shown in the following table: Table 4.8 Woodgrove Bank Network Access Groups with Membership Assigned NAG Name
Membership
Description
ANAG_EncryptedResource User7 Access_Users
This group is for all users that are authorized to make inbound IPsecprotected connections to the Encryption isolation group computers.
ANAG_EncryptedResource IPS-SQL-DFS-01 Access_Computers IPS-SQL-DFS-02
This group contains all computers that are authorized to make inbound IPsec-protected connections to the Encryption isolation group computers.
IPS-ST-XP-05 DNAG_EncryptionIG_ Computers
This group contains all computers that are not authorized to make inbound IPsec-protected connections to the Encryption isolation group computers.
Note Membership in a NAG does not control the level of IPsec traffic protection. IPsec policy settings control the security methods used for protecting traffic and are independent of the identity being authenticated by IKE. The IKE negotiation is only aware of whether the Kerberos computer identity passed or failed the authentication process. It cannot implement a policy of "encrypt if user3 connects" or "encrypt if trusted host IPS-SQL-DFS-01 or IPS-SQL-DFS-02". The administrator must achieve the intended behavior by using an IPsec policy for the servers in the Encryption isolation group that requires "encryption for any inbound trusted host connection" and likewise requires "encryption for any outbound connection to a trusted host."
So far, this design process has not reviewed the details of the IPsec policy design. Chapter 5 will provide details of the IPsec policy design for Woodgrove. At this point in the design process, you have completed the tasks that are required to turn your requirements into a draft design. This section has helped you develop both the design and the documentation that will be required for the creation of the IPsec policies.
86
Server and Domain Isolation Using IPsec and Group Policy
Limitations That Might Affect Your Design The following issues might affect your design and therefore must be considered before your design can be considered complete: •
Maximum number of concurrent connections by unique hosts to servers using IPsec. The number of concurrent connections is a key factor in whether an IPsec implementation on high-use servers will go smoothly or will overload the CPU with IKE or IPsec processing. Each successful IKE negotiation establishes SAs that occupy approximately 5 kilobytes of user-mode memory. CPU resources are needed to maintain current IKE SA states with all concurrently connected peers. For more information about scaling, see the "Improving Security with Domain Isolation" white paper.
•
Maximum Kerberos token size limitation for hosts using IPsec. There is a practical limit of approximately 1,000 groups per user, and if that value is exceeded, GPO application may fail to occur. For more information on this subject, see Microsoft Knowledge Base articles 327825 "New Resolution for Problems That Occur When Users Belong to Many Groups" and 306259 "Members of an Extremely Large Number of Groups Cannot Log On to the Domain".
Although these articles mention users specifically, the issue also exists for computer accounts, because the Kerberos MaxTokenSize also applies to computer accounts. Although this limit should rarely be reached in most implementations, you need to be aware of this issue if you decide to put one computer (perhaps a client) in a large number of NAGs. If your design will be affected by these issues, you will need to revisit the design process to address them. For example, you could address the maximum number of concurrent connections issue by moving a very heavily loaded server into the Exemptions lists. You could address the maximum Kerberos token size limitation by reducing the number of NAGs your design will use. If these limitations will not affect your design, the next task is to consider how the design will be deployed into the organization.
Group Implementation Methods After you have created the initial design, you must carefully consider the process of deploying IPsec. Only in the smallest environments is it possible to simply deploy the policies to all computers and expect IPsec to work smoothly with an acceptably small impact on users. In large organizations, complexity and risk necessitate a phased deployment strategy. By using such an approach, the organization can help mitigate the risk associated with such a fundamental change to the environment. Without careful planning, help desk calls and lost productivity will quickly increase the cost of deployment. There are a number of ways to deploy IPsec in an organization. Some of the factors that help determine the deployment method include: •
The environment's beginning and end states
•
The complexity of group configuration
•
The complexity of the domain structure
•
The organization's risk tolerance
•
Security requirements
Chapter 4: Designing and Planning Isolation Groups
87
The following deployment methods are not all inclusive but provide examples of possible approaches that you could take. You can also use a combination of these approaches. Generally, organizations should not deploy IPsec policies that restrict or block communication initially to ensure that adequate time is available to troubleshoot problems and to reduce the management coordination for complex environments. Regardless of which approach is used to deploy IPsec, it is highly recommended that the deployment scenario be thoroughly tested in a lab environment, including the specific sequence and timing of rollout steps and policy changes. In addition, use a filter action that requests IPsec functionality but will accept plaintext communication by using Fall back to clear. This approach will help minimize the impact of the initial rollout. After the roll out is complete, move towards more secure modes of operation that require the traffic to be protected by IPsec. For deployment in a production environment, an initial pilot is strongly recommended for each major phase of the rollout. It is particularly important to analyze the impact of IPsec policy changes, because they will take effect in the production environment as a result of Kerberos ticket lifetimes, Group Policy polling intervals, and IPsec policy polling intervals. You should implement a formal change control process with rollback strategies and rollback criteria to ensure that all affected IT organizations are aware of the change and its impact and know how to coordinate feedback to decision makers.
Deploy by Group The Deploy by Group method uses fully-defined IPsec policies but controls the application of the policies through the use of groups and ACLs on the GPOs that deliver the policies. In the Deploy by group method, the IPsec policies are created in Active Directory in their final configuration. Each IPsec policy has all of the exemptions and secure subnets defined with the appropriate filter actions enabled. Then the IPsec policy administrators create GPOs for each IPsec policy. In addition, computer groups are created in the domain to manage and apply these newly created GPOs. The ACLs on the GPOs are modified so that members of Authenticated Users no longer have the "Apply" right. The appropriate administrator user groups for management and application of the policy are also granted rights to the GPO. Next, the appropriate IPsec policies are assigned to their corresponding GPO. In addition, the GPO is linked to the appropriate object in Active Directory. At this point in time, none of the computers in the environment should receive the policy, because the ACLs that control the assignment of the GPO (the ability to read the GPO) are empty. Finally, the computers that will receive the policies are identified and their computer accounts are placed in the appropriate computer groups with read access to the GPO. After the computer's Kerberos tickets are updated with the group membership information, the GPO, along with the corresponding IPsec policy, will apply at the next Group Policy polling interval. Note ACLs that restrict domain computers from reading the IPsec policy objects or the IPsec policy container in Active Directory are not recommended.
Consider an organization that has two IPsec policies defined, IPsec Standard and IPsec Encryption. The IPsec Standard policy is its default policy that requires incoming traffic to use IPsec but will allow the systems to Fall back to clear if they initiate to a non-IPsecbased computer. The IPsec Encryption policy requires encrypted IPsec to be negotiated at all times.
88
Server and Domain Isolation Using IPsec and Group Policy
In this example, the organization's administration creates two GPOs in Active Directory: Standard IPsec GPO and Encrypted IPsec GPO. In addition, they identify the groups in the following table: Table 4.9 IPsec Administration Groups Group name
Group type
Description
IPsecSTD
Universal
Controls application of the IPsec Standard policy
IPsecENC
Universal
Controls application of the IPsec Encryption policy
The ACLs on the two newly created GPOs are updated so that they do not automatically get applied to the Authenticated Users group and so that the appropriate application groups and management groups are given the correct rights. The administration modified the ACLs for the two GPOs according to the information in the following table: Table 4.10 Group Rights on GPOs Group
Standard IPsec GPO
Encrypted IPsec GPO
Authenticated Users
Read
Read
IPsecENC
None
Read Apply Group Policy
IPsecSTD
Read
None
Apply Group Policy Note This table only shows permissions that are added or modified. There will be some additional groups with permissions, as well.
The administrators linked the two GPOs to the domain in Active Directory. This approach ensures that the policy will apply on any computer in the domain without modifying its location (unless the computer is located in an OU that blocks policies). As computers are identified, their computer accounts are added to either the IPsecSTD group or the IPsecEnc group. After a period of time, the corresponding IPsec policy will apply and be in effect. This method requires careful planning to ensure that communications are not disrupted. For example, if a server was placed in the IPsecEnc group, but multiple clients that depended on that server could not negotiate IPsec, communications between those clients and server would be disrupted.
Deploy by Policy Buildup This deployment method uses a technique in which the IPsec policies can be built from scratch during the deployment. The advantage to this method is that IPsec is negotiated only for a small percentage of the total TCP/IP traffic, instead of for all internal subnets in the deploy-by-group method. It also allows the testing of all network paths in the internal network to this target subnet to be sure there are no problems with the network passing IKE negotiation and IPsec protected traffic. A further advantage is that the polling interval for IPsec can more quickly deliver IPsec policy updates (including rollback) instead of having to depend on group membership changes in the Kerberos Ticket Granting Ticket (TGT) or service tickets. The disadvantage to this method is that it applies to all computers in the isolation domain or group, not to specific computers as in the Deploy by
Chapter 4: Designing and Planning Isolation Groups
89
Group Method. Also, all computers will have a three-second delay for Fall back to clear at some point when communicating to the specified subnets. In this deployment method, IPsec policies only include exceptions initially; no rules exist for computers to negotiate security in the IPsec policy. This method first tests and ensures that any previously existing local IPsec policies that might be in use are removed. The administration team should be able to identify hosts that were using locally defined IPsec policies in advance to manage those systems with a special process. If a local IPsec policy is overridden by a domain policy, there could be interruptions in communications and a loss of security for the affected computers. Unlike local policies that are overwritten by the domain policy application, persistent policies on Windows Server 2003 merge with the result of the application of the domain policy. A system that contains a persistent policy might appear to work, but the configuration of the persistent policy can change the behavior or actually lessen the security that the domain policy provides or can disrupt the communications after secure subnet rules are added to the policy. Next, you can create a security rule with a filter that affects only a single subnet within the organization's network, for example "From Any IP to Subnet A all traffic, negotiate." This rule would have a filter action to accept inbound plaintext and trigger negotiations for all outbound traffic to that subnet with Fall back to clear enabled. As the rollout in all domains of this IPsec policy takes effect, communications will gradually go from soft SAs to normal IPsec security associations for trusted hosts just on that subnet. Any IKE negotiation failures are investigated and resolved. Any application incompatibilities are identified and fixed. IPsec will secure communication between trusted hosts within that subnet. Communication with trusted hosts outside that subnet will Fall back to clear after the three-second delay. Additional subnets are added to the secure rule until the policy is built up to its final state. Consider an organization that has a single IPsec policy defined, which is called IPsec Standard policy, which requests IPsec negotiation but failing that will Fall back to clear text communication. The policy is created in Active Directory, and it contains only exemption rules. The Standard IPsec GPO is created and linked so that it applies to all computers in the environment. In addition, the IPsec Standard policy is assigned to this new GPO. All computers will eventually be assigned the IPsec policy. Any issues with local IPsec policies will be discovered because this domain policy will override the existing local policies. Issues are continually resolved until all subnets are listed in the Secure Subnets filter list.
Group Implementation for Woodgrove Bank Woodgrove Bank chose to implement its production deployment by first moving all computers to the Boundary group using the buildup method. This approach allowed administrators to move forward slowly and resolve any outstanding issues without significantly affecting the communications between all systems. By first deploying a policy without any secure subnets, the administration team was able to identify any systems that had a local IPsec policy assigned and take that information for additional consideration. As subnets were added to the policy, any additional conflicts that were found were resolved. After the computers were operating under the Boundary group policy, the team implemented the Isolation domain, No fallback, and Encryption groups. Deployment of these groups used the Deploy by Group method. A set of computers were selected for a
90
Server and Domain Isolation Using IPsec and Group Policy
pilot and added to the appropriate groups that controlled the new policies. Issues were resolved as they were discovered, and additional computers were added to the groups until the groups were fully populated. The following table lists the computer groups and NAGs and their membership after the solution is fully deployed: Table 4.11 Computer and Network Access Group Membership Computer or network access group
Members
CG_IsolationDomain_Computers
Domain computers
CG_BoundaryIG_Computers
IPS-PRINTS-01
CG_NoFallbackIG_Computers
IPS-LT-XP-01
CG_EncryptionIG_Computers
IPS-SQL-DFS-01 IPS-SQL-DFS-02
ANAG_EncryptedResourceAccess_Users
User7
ANAG_EncryptedResourceAccess_Computers
IPS-SQL-DFS-01 IPS-SQL-DFS-02 IPS-ST-XP-05
DNAG_EncryptionIG_Computers
CG_BoundaryIG_Computers
Notice that the ANAG_EncryptedResourceAccess_Computers group contains the servers that are in the encryption isolation group. This is so they will be able to communicate with themselves and each other as required. If this communication is not required for these servers, you do not need to add them into this group.
Summary This chapter described the design process for a server and domain isolation solution. Tasks included identifying the need for computer groups and NAGs, understanding the foundational isolation groups, adding additional isolation groups, completing a traffic model, assigning membership to the groups, and planning the deployment rollout method. This chapter also used the IPsec implementation at Woodgrove Bank, a fictitious organization, to help illustrate the design process in action and to prove the design in the Microsoft test labs. Group design was based on business requirements and the discovery information obtained from the previous two chapters and documented in the Business_Requirements.xls spreadsheet (available in the Tools and Templates folder). An appreciation for the impact of IPsec on a network was also an important consideration. After reading this chapter, you should have enough information to start planning isolation groups, documenting the communication requirements between those groups, and planning the high-level IPsec policy. These tasks will prepare you for Chapter 5, "Creating IPsec Policies for Isolation Groups."
Chapter 4: Designing and Planning Isolation Groups
91
More Information This section provides links to additional information that may be helpful when implementing this solution.
IPsec The following links provide a wide range of Windows-specific IPsec content: •
The "Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server” white paper presents the first model for using IPsec to secure network access to internal servers that process or store sensitive information.
•
The Microsoft deployment of IPSec to protect all domain members is described in the technical white paper "Improving Security with Domain Isolation".
•
The Internet Protocol Security for Windows 2000 Server page.
•
The IPsec Web site.
Security •
The Microsoft IT security risk assessment approach is documented in the "Information Security at Microsoft Overview" white paper.
Windows Server 2003 Active Directory For more information about Active Directory, see: •
The Windows Server 2003 Active Directory page.
Chapter 5: Creating IPsec Policies for Isolation Groups The objective of this chapter is to provide instructions for implementation of the server and domain isolation design. The previous chapters explain the design process and rationale behind the guidance that this chapter provides. If you have not already done so, it is strongly recommended that you read these chapters before continuing with this one. This chapter provides complete guidance for implementing the security requirements of domain isolation and the server isolation groups designed in Chapter 4, "Designing and Planning Isolation Groups." A combination of the following elements will implement these requirements: •
•
Inbound and outbound access requirements for the isolation domain and isolation groups: •
Internet Protocol security (IPsec) policy designed specifically for the isolation group that requires IPsec Internet Key Exchange (IKE) negotiation for inbound and outbound connections
•
Domain-based security groups called network access groups to allow or deny network access when using IPsec-protected traffic
Network traffic protection requirements for the Isolation domain and isolation groups: •
IPsec policy filters designed to properly identify which traffic should be secured
•
IPsec filter actions that negotiate the required level of authentication and encryption for the traffic that the filters identify
•
IPsec filter action settings to control whether plaintext communication is allowed when trusted hosts initiate outbound connections
This guidance discusses the preparation of the solution using Group Policy and IPsec policies in the Active Directory® directory service using Microsoft® Windows Server™ 2003, and configuration of domain members using Windows Server 2003 and Microsoft Windows® XP. Additionally, this chapter discusses design alternatives and rollout options. Final check lists are provided to ensure that the design meets all of the business and security requirements.
Chapter Prerequisites This section contains information that will help you determine your organization's readiness to implement the IPsec solution. (Readiness is meant in a logistical sense rather than a business sense—the business motivation for implementing this solution is discussed in Chapter 1, "Introduction to Server and Domain Isolation," of this guide.)
Knowledge Prerequisites You should be familiar with general concepts of IPsec and the Microsoft implementation of IPsec in particular. Familiarity with Windows Server 2003 is also required in the following areas: •
Active Directory concepts, including Active Directory structure and tools; manipulating users, groups, and other Active Directory objects; and use of Group Policy
•
Windows system security, including security concepts such as users, groups, auditing, and access control lists (ACL); the use of security templates; and the application of security templates using Group Policy or command-line tools
•
An understanding of core networking and IPsec principles
Before proceeding with this chapter, you should also have read the planning guidance that the earlier chapters in this guide provide and have a thorough understanding of the architecture and design of the solution. You also should have defined and documented the business requirements of the solution as part of the solution requirements matrix.
Organizational Prerequisites You should consult with other people in your organization who may need to be involved in the implementation of this solution, including the following: •
Business sponsors
•
Security and audit personnel
•
Active Directory engineering, administration, and operations personnel
•
DNS (Domain Name System), Web server, and network engineering administration and operations personnel
Note Depending on the structure of your information technology (IT) organization, these roles may be filled by a number of people, or there may be fewer people spanning several roles.
IT Infrastructure Prerequisites This chapter also assumes that the following IT infrastructure exists: •
A Microsoft Windows Server 2003 Active Directory domain running in mixed or native mode. This solution uses Universal groups for Group Policy object (GPO) application. If the organization is not running in mixed or native mode, it is still possible to apply the GPO through the use of standard global and local group configurations. However, because this option is more complex to manage, this solution does not use it. Note Windows Server 2003 introduced a number of improvements that affect IPsec policies. There is nothing specific to this solution that would keep it from working with Windows 2000. However, the solution was only tested using Windows Server 2003 Active Directory. For more information about the enhancements made to IPsec in Windows Server 2003, see New features for IPSec.
•
Windows 2000 Server, Windows Server 2003 Standard Edition, and Windows Server 2003 Enterprise Edition licenses, installation media, and product keys.
This chapter also requires a complete understanding of the existing IT infrastructure to ensure that the correct policies are deployed to the intended hosts in the environment. Chapter 3, "Determining the Current State of Your IT Infrastructure," describes the required information and how to obtain.
Chapter 5: Creating IPsec Policies for Isolation Groups
95
You should not undertake the steps that this chapter describes until you have obtained at least the following information: •
The isolation groups definition for the design. Each of the required isolation groups should have a clear statement that communicates security requirements and identifies assets to which these requirements apply (that is, isolation group membership).
•
A high-level description of how IPsec policies are used to implement the isolation groups, including a list of the different IPsec policies that are needed and how they will be assigned.
•
A high-level summary of the impact of applying IPsec to enforce the isolation groups. This summary might be accompanied by a list of issues and workarounds.
•
A high-level description of how the IPsec policies will change over time and a list of procedures that require IPsec policy changes. This list would include such procedures as security incident responses, adding network components, and adding clients or servers in any isolation group.
•
An understanding of the organization's network topology and IP addressing scheme.
Creating IPsec Policies in Active Directory The process of creating the necessary policies to support the required isolation groups consists of the following main tasks: •
Create the filter lists.
•
Create the filter actions.
•
Create the IPsec policies to implement the isolation groups.
Before undertaking the process of creating these components, it is important to obtain the traffic model diagrams and tables from Chapter 4, "Designing and Planning Isolation Groups," and the host and network mapping tables. These tables provide the necessary information to ensure that the policies provide the required functionality and are assigned to the correct isolation groups.
96
Server and Domain Isolation Using IPsec and Group Policy
The following figure depicts the network configuration that was used to simulate the Woodgrove Bank scenario.
Figure 5.1 Woodgrove Bank network configuration The Woodgrove Bank test lab configuration demonstrates the following key capabilities of the solution: •
Domain isolation using network access groups to block certain higher-risk but trusted hosts in the domain when using IPsec
•
Server isolation using network access groups to limit which trusted host clients are authorized to connect using IPsec
In addition, this lab environment demonstrates the following required functionalities of Windows IPsec and test compatibility with other security technologies that would be used in real-world environments: •
Compatibility of computers running Windows 2000 Service Pack (SP) 4 (with the network address translation traversal (NAT-T) update), Windows XP SP2, and Windows Server 2003 as domain members.
•
Compatibility of these platforms when secured using recommended hardening by the Microsoft Windows Security Guides. The traffic maps for permitting and blocking traffic using IPsec filters were not integrated with this solution because the protection
Chapter 5: Creating IPsec Policies for Isolation Groups
97
requirements are different for isolation. Additional reasons for not integrating traffic maps were to reduce complexity of the server isolation IPsec policies, and because Windows Firewall is better suited in many cases for permit/block filtering (independent of IPsec providing end-to-end security for each packet). •
IPsec application capability to secure Web (HTTP), SQL Server, Distributed File System (DFS), file and print sharing, Microsoft Operations Manager (MOM), and Microsoft Systems Management Server (SMS) servers and traffic.
•
Compatibility of IPsec encapsulated security payload (ESP) NAT-T using User Datagram Protocol (UDP)-ESP encapsulation for both of the following conditions: •
Outbound access from domain members behind NAT using IKE Kerberos authentication
•
Inbound access to a domain member behind NAT using IKE Kerberos authentication
The lab scenario illustrated in figure 5.1 was used to test that the correct functionality was achieved in all of the isolation groups for the solution. In total, four IPsec policies were created and assigned to the isolation groups shown in bold dashes in the figure (that is, the Isolation domain, the Encryption isolation group, the No Fallback isolation group, and the Boundary isolation group.) The following sections explain how these policies were created.
IPsec Policy Component Overview An IPsec policy consists of a number of components that are used to enforce the IPsec security requirements of the organization. The following figure depicts the various components of an IPsec policy and how they are associated with each other.
Figure 5.2 IPsec policy components
98
Server and Domain Isolation Using IPsec and Group Policy
The IPsec policy acts as a container for a set of rules that determine what and how network communications traffic will be allowed. Each of the rules consists of a filter list and an associated action. The filter list contains a grouping of filters. As traffic is matched to a specific filter, the associated filter action is triggered. In addition, the rules define which authentication methods are used between hosts. This diagram depicts the policy components from the top down. However, the most effective way to build policies is to start with the filters and filter lists, because they are the fundamental building blocks that control which traffic is secured.
IPsec Filter Lists IPsec filter lists are collections of one or more filters that are used to match network traffic based on the criteria for each filter. Each filter in the filter list defines the following: •
Source and destination networks or addresses
•
Protocol(s)
•
Source and destination Transmission Control Protocol (TCP) or UDP ports
Filter lists and filter actions were designed to be shared among IPsec policies. This approach allows one filter list to be maintained for a certain type of exemption and used in the individual IPsec policy for each isolation group. However, filters that make up the filter lists cannot be shared between filter lists. If two filter lists have identical filters, the filters will have to be created twice, once for each filter list. The IPsec administrator should carefully avoid duplicate filters in an IPsec policy because the filters may have separate actions. The IPsec service may change the ordering of duplicate filters to packet processing and yield inconsistent results. Duplicate filters may be used if necessary when the filters have exactly the same action, such as permit or block, and performance is not affected. The network information gathered earlier is used to identify the various traffic patterns that the administrator wants to secure. In addition, the information is used to identify any traffic that might need to be exempted from the IPsec restrictions. The following table describes some basic filter lists that might exist in a typical organization. Depending on the organization's business requirements and network design, additional filter lists may be required. Table 5.1 Solution-Provided Filter Lists Filter list
Description
Secure Subnets List
Contains all subnets in the organization that will be secured with IPsec
DNS Exemption List
Contains the IP addresses of the DNS servers that will be allowed to communicate without IPsec
Domain Controllers Exemption List
Contains the IP addresses of the domain controllers that will be allowed to communicate without IPsec
WINS Exemption List
Contains the IP addresses of the Windows Internet Naming Service (WINS) servers that will be allowed to communicate without IPsec
DHCP, Negotiation Traffic
Contains the filter that allows the Dynamic Host Configuration Protocol (DHCP) negotiation traffic across UDP 68 to occur
Chapter 5: Creating IPsec Policies for Isolation Groups
Filter list
Description
ICMP, All Traffic
Contains the filter that allows the Internet Control Message Protocol (ICMP) to function within the organization for troubleshooting purposes
99
The Secure Subnets List contains all of the subnets within the organization's internal network. This filter list is associated with a filter action that implements the actions required for a particular isolation group. This action is the broadest security action for all network traffic for that subnet (for example, negotiate IPsec), because other filters, like the one for ICMP, will be more specific to require a different action (such as permit). It is important to remember that this approach means that no untrusted or non-IPsec hosts should be on those subnets. The filters must implement both inbound and outbound security requirements. When defining the filters, they should be configured as mirrored. Mirroring ensures that traffic is matched when the exact opposite source and destination addresses are used. When describing filters, the symbol "" is used to signify that the filter is mirrored. Mirrored filters must be used whenever the filter action negotiates security methods for IPsec encapsulation.
Source and Destination Addresses Each filter has a setting for both the source and destination addresses. Windows XP and Windows Server 2003 have more options for addresses than Windows 2000. So you should use only Windows 2000 settings when this platform is a member of the domain. The Windows 2000 settings are explained as follows: •
My IP Address. This option was designed so that a common IPsec policy in Active Directory can apply to many or all computers, regardless of whether they have a static IP address or a DHCP-assigned address. To support centralized policy assignment from the domain, IPsec does not support filter configuration for physical network interfaces, only the type of interface such as LAN or WAN, for example, dialup or virtual private networking (VPN) interfaces. Using My IP Address causes the generic IPsec policy filters to be copied into a specific filter that contains each IP address used by the computer at the time the IPsec service prepares to enforce the policy. It also makes the IPsec service detect address changes or new network interfaces so that the right number of filters can be maintained. If a computer has one network card with two IP addresses configured for that card, there will be two different IPsec-specific filters created using the two different IP addresses.
•
Any IP Address. This option causes the IPsec filters to match against any IP address.
•
A Specific DNS Name. This option causes IPsec to evaluate the IP address of the specified DNS name and then create the filters using that IP address or addresses. The result is the same as if the administrator had entered the IP address(es) into the filter(s). During the creation of the initial filter, the DNS name will be resolved and the corresponding IP address(es) will be placed in the filter. If the DNS server has an incorrect resource record for the DNS name specified in the filter, the wrong IP address will be added to the filter. Note The DNS name is never evaluated after the filter(s) are created for the first time in policy.
The DNS name option is useful when you need to create many filters, because the DNS name has many corresponding IP addresses, such as for each domain controller in the domain. There is no automatic way to create filters that will be kept current with the list of IP addresses for a given DNS name.
100
Server and Domain Isolation Using IPsec and Group Policy
•
A Specific Address. This option matches traffic to the IP address that is provided to the filter.
•
A Specific Subnet. This option allows the administrator to configure a specific subnet. Any IP address within the specified subnet will match against the filter. Care should be taken with this option, especially if an exemption is created for a subnet, because a rogue user spoofing an IP address from that subnet will also be exempted.
Note Windows XP and Windows Server 2003 were enhanced to provide additional address options, as well as a number of other options supported by those releases. If the same IPsec policy will be applied to multiple platforms, the administrator must ensure that only Windows 2000 options are used in the policy design.
Protocols In addition to source and destination address configuration, each filter can be configured to match against a specific protocol or port. By default the filter will match traffic on all protocols and all ports. If a specific protocol that supports ports is selected as part of the filter criteria, the administrator has the option to also configure source and destination ports.
Source and Destination Ports Although filters can be configured to match against the TCP or UDP ports, this solution does not recommend creating port-specific filters. Port filtering greatly increases the administrative overhead and complexity of the configuration of the IPsec filters and can require complex coordination between client and server policies for IKE to successfully negotiate security. Because this solution assumes that communication between trusted computers is in fact trusted, the filters allow all traffic (except ICMP) to be secured by IPsec. If port filtering on the trusted host is required, see Business_Requirements.xls for security requirements that are met by using the combination of IPsec and a hostbased firewall (such as Windows Firewall) positioned above the IPsec layer. To work around a number of the issues mentioned in Appendix A regarding the behavior of filters using "My IP Address," this solution uses Any subnet filters for the Woodgrove Bank scenario. A filter list is created that consists of multiple Any IP Address A Specific Subnet filters in which all the organization's subnets are listed explicitly. This approach allows the administrator to define the specific subnets that should be secured. Any traffic outside the specified subnets will not match any IPsec filters and will be sent through in plaintext to the destination host. For additional best practice recommendations in filter design, see the "Best Practices" section of the IT Showcase white paper, "Improving Security with Domain Isolation”.
Exemption List Considerations Some traffic cannot be protected by IPsec for support, technical, or business reasons. Also, computers that are not running the Windows operating system might not support IPsec or have IPsec easily deployed to them. Computers running older versions of Windows such as Microsoft Windows NT® version 4.0, Windows 95, and Windows 98 are unable to process Group Policy-based IPsec. Finally, unmanaged computers that run Windows 2000 or later can only participate in the IPsec negotiation if the policy is manually rolled out to the individual computers and some form of authentication other than the Kerberos version 5 protocol (such as a preshared key or certificate) is used. In addition, a computer running Windows 2000 or later needs to have network connectivity and be able to obtain an IPsec policy from the domain before it can establish IPsec. Currently, connecting to the network, locating a domain controller, and retrieving the policy requires that the supporting infrastructure services be exempted from IPsec
Chapter 5: Creating IPsec Policies for Isolation Groups
101
security. These services include naming services such as DNS and WINS and the domain controllers themselves. In addition to these infrastructure services, other services that do not support IPsec might exist in the organization. For example, thin clients or other bootstrap clients that need to download an image from Advanced Deployment Services (ADS) or Remote Installation Services (RIS) do not support IPsec. If servers that provide these services exist on your network, you should examine them for inclusion in an exemption list or make them members of the Boundary isolation group so that they can accept network communications from hosts that are unable to use IPsec. Note Deciding whether to include servers that provide ADS, RIS, or other such services on exemption lists or make them members of the Boundary isolation group is based on factors of risk and manageability. In either case, you should thoroughly test the approach that you have chosen.
If a client is not able to participate in the IPsec infrastructure but has a business need to access a server that is using IPsec, you must implement some method to allow a communication path to be established. The solution in this guide uses exemption filter lists to control these traffic requirements through permits. Exemption lists are designed into the IPsec infrastructure to ensure that all required host communications can occur, even if IPsec negotiations cannot be used. Exemption lists are used to selectively opt out traffic from participating in the IPsec infrastructure by permitting traffic that matches the exemption lists' filters. These lists need to be carefully designed, because they bypass the security mechanisms that IPsec implements. For example, placing a server that is typically secured through the use of encryption (to protect proprietary information) in an exemption filter will allow guest computers to communicate directly with the server without using IPsec. The exemption lists are implemented as filter lists to help minimize the list size for easier user interface (UI) configuration. For example, you should have a filter list that contains the filters for all domain controllers, or for domain controllers in each domain. A second advantage in having several filter lists is that the permit rule can be disabled/enabled in IPsec policy easily for each filter list. When designing a rule to implement the exemption in IPsec policy, you want to permit the least amount of traffic necessary to be unprotected by IPsec. However, there are tradeoffs in terms of the complexity and size of the IPsec policy as opposed to the security gained by using the most specific filters. Note that all domain controller IP addresses in all trusted forests must be exempted in order for clients in one domain or forest to be able to obtain Kerberos tickets for servers in another trusted domain or forest. The Windows Kerberos client requires ICMP, Lightweight Directory Access Protocol (LDAP) UDP 389, and Kerberos UDP 88 and TCP 88 traffic to both its own domain controllers and to domain controllers in other domains. Domain members require additional types of traffic with the domain controllers of their own domain such as server message block (SMB) TCP 445, remote procedure call (RPC), and LDAP TCP 389. Where security requirements are not extreme, the exemption is implemented for "all traffic" with the domain controller IP addresses for simplicity and to reduce the number of filters.
102
Server and Domain Isolation Using IPsec and Group Policy
It is tempting to want to exempt particular application traffic by port instead of by destination address to avoid having to maintain a list of addresses, such as outbound Telnet using TCP port 23 to access UNIX systems. For example, consider the following outbound exemption: My IP Address to Any IP address, TCP, src port Any, dst port 23, mirrored The corresponding inbound filter would be as follows: Any IP Address to My IP address, TCP, src port 23, dst port Any This inbound filter would allow responses from Telnet connection requests, but it would also allow an attacker to bypass IPsec authentication requirements and access any open port on the host. Organizations will have to carefully evaluate the security risk of such a potential attack before using this filter design. The risk is certainly minimized if the destination IP address is specified. This same situation can exist if default exemption for the Kerberos authentication protocol is not disabled. See Microsoft Knowledge Base articles 811832 “IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios” and 810207 “IPSec default exemptions are removed in Windows Server 2003” for detailed discussion of the design and security impact of default exemptions. You should design IPsec policies with the assumption that no default exemptions are enabled. Placing system addresses in an exemption list effectively exempts those systems from participating as IPsec hosts for all IPsec policies that implement the exemption list. Because most clients in the organization (including guest clients) will typically need access to infrastructure services such as DHCP, DNS, or WINS, the servers that provide these services are usually implemented in this manner.
Woodgrove Bank Filter Lists After analyzing the traffic requirements output from Chapter 4, Woodgrove Bank administrators mapped out the filter lists in the following table: Table 5.2 Woodgrove Bank Filter List Examples Filter list
Filters defined
All
Secure Subnets
Any 192.168.1.0/24
All
Any 172.10.1.0/24 DNS Exemption List
Any 192.168.1.21
All
Any 192.168.1.22 Domain Controllers Exemption List
Any 192.168.1.21
All
LOB Application Servers Exemption List
Any <
All
WINS Exemption List
Any <
UDP source 68, dest 67
DHCP, Negotiation Traffic
My IP Address <
ICMP only
ICMP, All Traffic
My IP Address <
All
Any 192.168.1.22
Chapter 5: Creating IPsec Policies for Isolation Groups
103
The Woodgrove Bank designers followed the guidance provided in this chapter to create these filter lists. The first list—the Secure Subnets list—consists of two filters: •
Any 192.168.1.0/24
•
Any 172.10.1.0/24
These subnet filters are mirrored to match both inbound and outbound traffic and are configured to trigger on any protocol. This filter list, when paired with the appropriate filter action, will implement the isolation groups. The Woodgrove Bank designers then chose to implement an exemption list for ICMP network traffic. This filter list is comprised of a single mirrored filter (My IP Address Any) that is configured for ICMP network traffic only. This approach allows administrators to use the Ping utility as a troubleshooting tool in the environment, regardless of whether an IPsec security association (SA) has been negotiated. This approach was also necessary because path maximum transmission unit (MTU) discovery is required for this solution to work correctly. For DHCP traffic, the Woodgrove Bank designers created a new filter for UDP port 68 to allow DHCP clients to receive traffic from the DHCP server. In addition, Woodgrove Bank had some line of business (LOB) applications that were running on servers that are unable to participate in the IPsec infrastructure. To accommodate those services, they created a new exemption filter list called LOB Application Servers Exemption List and added an Any 192.168.1.10 filter for the system hosting the LOB application. Finally, the Woodgrove Bank design team identified its infrastructure services and created the corresponding exemption filter lists to allow all clients to communicate directly to the servers that provide these services, regardless of the IPsec settings for the isolation groups. Specific exemption lists were created for the following services: •
DNS. This list exempts DNS servers so that all clients in the network can perform domain name lookups.
•
Domain Controllers. This list allows the domain-joined systems to authenticate with a domain controller.
•
WINS. This list specifically allows host devices to look up NetBIOS names on a WINS server.
These filter lists are comprised of mirrored filters that define Any Specific IP Address, and these filters are configured to trigger on any protocol. The number of computers in the exemption filter lists should be kept to a minimum because all traffic is exempted to these computers, and all computers in the exemption list have full TCP/IP access to all trusted hosts in the Isolation domain. Accordingly, this approach could present a larger attack surface than what otherwise might be present. See the Business_Requirements.xls spreadsheet (in the Tools and Templates folder) for details of requirements to mitigate the risk of inbound traffic from IP addresses that are exempted. Woodgrove Bank chose to manage two separate lists for DNS servers and domain controllers, even though the IP addresses are the same. Woodgrove took this approach because both filter lists will have the exact same action, permit. Also, the Woodgrove production network uses DNS servers in some areas that are not also domain controllers. Instead of having specific destination IP addresses, the filter for DHCP was designed to match all DHCP client outbound traffic. The mirror of this filter will permit responses from DHCP servers. As discussed, it may also permit inbound attacks from any IP address using source port 67. However, the inbound attack is limited to destination port 68 on the client, which the DHCP client is using. Woodgrove Bank used this design to avoid having filters for every DHCP server, and because its risk assessment did not rank highly the
104
Server and Domain Isolation Using IPsec and Group Policy
risks of inbound attacks to the DHCP client port or the risk of unauthorized DHCP servers. This section does not include the full description for each filter. However, it is recommended that you use the filter description field to carefully define each filter, because the IPsec monitor and command-line tools display each filter's description, not the information in the filter list.
IPsec Filter Actions The filter actions define how IP packets are handled after they are matched to a filter within a filter list. Filter actions are the basis for implementing the various isolation groups. Although there are three default filter actions provided with the Windows operating system, it is recommended that you remove these and create new filter actions this approach allows you to ensure that only the actions that you create as part of your design are being used. Each filter action is comprised of a name, description, and security method.
Name Give the filter action a meaningful name that reflects what the filter action does.
Description Type a detailed description of the filter action behavior in the description field.
Security Methods The security methods that are implemented within the filter action are determined by the requirements for processing packets that match the associated filters in the filter list. The following three options are available: •
Block. For IP packets matching the associated filter, the packet will be blocked. In other words, the packet is discarded or ignored.
•
Permit. For IP packets matching the associated filter, the packet will be allowed to pass the IPsec layer without any further processing by IPsec.
•
Negotiate. If the filter criteria are met by outbound packets, IPsec will attempt to negotiate one of the security methods that are in the filter action based on its relative order. The higher the security method is in the list, the higher preference it has. Each security method can define whether to use integrity, whether to enable encryption, and which cryptographic algorithms provide the functionality. The handling of inbound packets that match a filter with a negotiate action is determined by the setting for Accept unsecured communication, but always respond with IPsec.
The following table lists the possible cryptographic options for each security method: Table 5.3 Security and Cryptographic Options Security method
Cryptographic options
Description
Authentication Header (AH)
MD5
Provides both IP payload (data) and IP header (address) integrity and authenticity without encryption. AH cannot traverse devices running NAT.
SHA-1
Chapter 5: Creating IPsec Policies for Isolation Groups
105
Security method
Cryptographic options
Description
ESP – Integrity
Provides data integrity and authenticity for the IP payload (data) only. It can be used with or without encryption. Use of ESP without authentication is not recommended..
MD5 SHA-1 ESP – Encryption
3DES
With DES or 3DES, provides IP payload (data) encryption. Can be used with a null encryption algorithm when encryption is not necessary.
DES The Windows 2000 SP4, Windows XP SP2, and Windows Server 2003 IPsec implementations now support NAT-T techniques for IPsec transport mode ESP, in addition to supporting NAT-T for L2TP/IPsec VPN client tunnels. The NAT-T update is required for Windows 2000 SP4. The Windows 2000 and Windows XP support for IPsec transport mode NAT-T is limited for Windows 2000 and Windows XP versions prior to SP2 because TCP Path MTU (PMTU) detection is not supported for IPsec-protected TCP traffic. Windows Server 2003 does have this support. NAT-T techniques use a UDP header after the IP header to encapsulate ESP. IKE automatically detects when NAT exists in the path and uses UDP-ESP whenever ESP is allowed in the security method list. Also, it is worth noting that current Windows IPsec implementations do not support the U.S. Federal government Advanced Encryption Standard (AES). This will change in future versions of Windows. The following cryptographic options are available for AH and ESP: •
MD5. This hash algorithm uses a 128-bit cryptographic key to generate a digest of the packet contents. MD5 is not an approved algorithm for U.S. federal security scenarios.
•
SHA-1. This hash algorithm uses a stronger 160-bit cryptographic key to generate a digest of the packet contents. The greater key length of SHA-1 provides stronger security, although it does have higher processing overhead. SHA-1 is an approved algorithm for U.S. federal security regulations.
ESP can be configured to use no encryption algorithm, in which case only data integrity and authenticity is enforced. This configuration is commonly called ESP-Null, and it provides the ability to authenticate the hosts prior to establishing a communication connection and performing an integrity check on the data part of the IP packet carried within the ESP packet. ESP can also encrypt the data section of the IP packet. The following two cryptographic options are available: •
DES. This option uses a single 56-bit key and processes each block once. DES is provided for Request for Comment (RFC) compliance. Because of advances in the ability of attackers to compromise DES encryption, using DES is not recommended.
•
3DES. This option processes each block three times, using three unique 56-bit keys. Although DES is supported, it is strongly recommended that you use 3DES because it is more secure. However, 3DES is somewhat slower in performance and has higher processing overhead than DES.
You can combine AH and ESP protocols with one another if required to meet very high security requirements. For example, if there is a clear requirement for IP header integrity in addition to data encryption, you can configure the security method to use AH with SHA-1 integrity and ESP – 3DES Encryption. If only data integrity is required, then you can use ESP-null with SHA-1.
106
Server and Domain Isolation Using IPsec and Group Policy
Although you can select any combination of the security options, it is important to recognize that AH provides both data and address header integrity. Using AH and ESP to provide integrity does not provide any additional integrity protection for packet data; it just increases the workload associated with processing the packet. In addition, ESP combined with AH will not overcome the NAT barrier issues that AH faces. Therefore, using AH in addition to ESP is appropriate for only the highest security environments. Careful planning is required when designing the security methods of the filter actions. For two computers to successfully negotiate, they need to have at least one security method in common in their respective filter actions. Each filter action may contain more than one negotiation method to accommodate different types of negotiation. For example, a system may typically only negotiate ESP-Null, but the filter action may also contain a negotiation method for ESP-3DES. This approach will allow the system to negotiate a 3DES encryption connection if required. In addition to selecting the security methods, you can set the session key settings for each security method if required. In its default setting, the IPsec SA lifetimes are configured to be when 100 megabytes (MB) of data are passed or after one hour has elapsed. These settings control when a new pair of IPsec security associations is renegotiated by IKE quick mode. The IKE quick mode process is called "rekeying" but does not actually just refresh keys for an existing IPsec SA pair. IPsec must discard packets if the lifetime expires; therefore, it attempts to renegotiate well before either the lifetime for bytes or seconds expires. If the lifetime is set too low, then packets can be lost. Similarly, CPU usage may be increased for servers maintaining IPsec SAs with many clients. Renewing IPsec SAs ensures that an attacker is unable to decipher the entire communication even if they manage to determine one of the session keys. As the lifetime increases, more information is available to the attacker about the session key. Therefore, you should not change the lifetimes unless operational needs require it, and you can write specific security requirements that define an appropriate level of protection against sophisticated cryptographic attacks.
Security Negotiation Options You can set the following security negotiation options for IPsec policies: •
Inbound passthrough
•
Fall back to clear
•
Use session key perfect forward secrecy
Inbound Passthrough The Inbound passthrough option was designed to be used in an internal server policy so that client policy could use the non-intrusive "default response" rule. With this option enabled, a plaintext connection request that matches an inbound filter will be accepted. The server's connection reply matches the outbound filter to trigger an IKE main mode negotiation request to the client. You should not enable this option should on Internet-facing computers, because it allows inbound attacks to pass through the IPsec layer. It also forces the server to attempt an IPsec SA negotiation to the source IP of any incoming packet. By spoofing source IP addresses, the attacker can cause denial of service on the server as IKE tries to negotiate with hundreds or thousands of invalid IP addresses. To enable Inbound passthrough, select Accept unsecured communication, but always respond using IPsec in the Manage Filter Actions dialog box. Note If the policies assigned to the clients do not enable the default response rule, you should disable this option, because there will be no response for IPsec communication. In addition, it can be used as a denial of service attack vector.
Chapter 5: Creating IPsec Policies for Isolation Groups
107
Fall Back to Clear The Fall back to clear option controls the ability for the (source) computer to allow traffic to be sent without IPsec protection if the initial IKE main mode negotiation does not get a response from a target destination computer. Hosts that do not support IPsec will not be able to reply (using IKE) to the IKE negotiation request. These hosts are referred to as being "non-IPsec-aware" computers. However, the lack of an IKE main mode response does not necessarily mean that the computer is not capable of IPsec; it might be an IPsec-capable computer that does not have an active IPsec policy. Or the active IPsec policy might only have permit and block actions. Or the active IPsec policy may not be designed to negotiate with the source computer's IP address. In IPsec terminology, network traffic that does not use IPsec is referred to as in plaintext. If there is no response from the target computer in three seconds, a soft security association (soft SA) will be created, and communication will begin in plaintext. For initial deployments, it is recommended that this option be enabled so that clients can communicate with hosts that do not have IPsec enabled. Also, using this option also helps re-establish plaintext connectivity temporarily when the IPsec service is stopped for troubleshooting. If the target computer does provide an IKE response and there is a failure during the IKE negotiation for any reason, IPsec on the source computer will discard the outbound packets, effectively blocking the communication. To enable the Fall back to clear option, select Allow unsecured communication with non-IPsec-aware computers in the Manage Filter Actions dialog box. Note The way this option functions has changed on computers that run Windows 2000 SP3 or later, Windows XP SP1, or Windows Server 2003. If only this option is enabled, the system will be able to initiate communication in the clear but will not accept any communication requests from non-IPsec aware systems. If the system needs to respond to requests from and initiate communication to non-IPsec aware systems, you must select both the Accept unsecured communication, but always respond using IPsec option and the Allow unsecured communication with non-IPsec-aware computers option. If the system is running Windows 2000 or Windows XP without the appropriate service packs, the client will accept unsecured communication requests when Allow unsecured communication with non-IPsec-aware computers is selected, even when Accept unsecured communication, but always respond using IPsec is not selected. This behavior occurs because when the Allow unsecured communication with non-IPsec-aware computers option is selected, IPsec processes the associated inbound filter as an Inbound passthrough filter (the same behavior that occurs when Accept unsecured communication, but always respond using IPsec is selected).
Use Session Key Perfect Forward Secrecy The Use session key perfect forward secrecy (PFS) option determines whether the master key material can be used to generate all the session keys or just the first session key. If this option is enabled, the master key can only be used once, and each additional session key renegotiation will require a new key exchange to be performed to generate a new master key before generating the session key. This requirement ensures that if the master key is compromised, the attacker cannot generate additional session keys to decrypt the traffic stream. Enabling this option is not recommended because of the additional overhead cost of performing a key exchange at each session key renewal interval. For more information about the Inbound passthrough, Fall back to clear, and Session key and Master key PFS options, see the "Security Negotiation Options" section in Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server.
108
Server and Domain Isolation Using IPsec and Group Policy
Woodgrove Bank IPsec Filter Actions The following table provides the filter action names and descriptions that are used to implement the various isolation groups for the Woodgrove Bank scenario: Table 5.4 IPsec Filter Actions and Descriptions Filter action
Description
IPsec – Block
Blocks the traffic that matches the filter.
IPsec – Permit
Allows the traffic that matches the filter.
IPsec – Request Mode
A host accepts inbound packets that are either IPsec or plaintext. For outbound traffic, it triggers an IKE negotiation and allows Fall back to clear if no response. This filter action is used to configure the Boundary isolation group.
(Accept Inbound, Allow Outbound) IPsec – Secure Request Mode (Ignore Inbound, Allow Outbound)
A host allows inbound TCP/IP access only when packets are secured by IPsec and ignores non-IPsec inbound packets. For outbound traffic, it triggers an IKE negotiation, and allows Fall back to clear if no response. This filter action is used to implement the Isolation domain, where outbound connections to untrusted hosts are allowed.
IPsec – Full Require Mode (Ignore Inbound, Disallow Outbound)
A host requires IPsec-secured communications for both inbound and outbound packets. This filter action is used to implement the No Fallback isolation group where all communications are protected by IPsec.
IPsec – Require Encryption Mode (Ignore Inbound, Disallow Outbound)
A host allows inbound TCP/IP access only when packets are secured by IPsec ESP 3DES encryption and ignores non-IPsec inbound packets. For outbound traffic, it triggers an IKE negotiation that requires IPsec ESP 3DES encryption. This filter action is used to implement the Encryption isolation group.
The first two filter actions are straightforward. The block filter action will drop any traffic that matches a filter in a filter list associated with this action. The permit filter action will allow the traffic to occur for any associated filter list that has the matching filter. The final four filter actions in Table 5.4 are used to implement the isolation groups in the Woodgrove Bank scenario. Woodgrove Bank administrators have four security isolation groups to implement. To deploy this configuration, you must define a minimum of three filter actions with custom security negotiation methods in addition to the permit and block filter actions. Woodgrove Bank has no additional requirements for isolating computers from each other within a specific security isolation group. The bank has determined that the four negotiated filter actions in the following table are sufficient to implement its environment: Table 5.5 Supported Security Methods Filter action
Security methods supported
IPsec – Request Mode (Accept Inbound, Allow Outbound)
ESP – SHA-1, ESP – SHA-1, 3DES
Chapter 5: Creating IPsec Policies for Isolation Groups
109
Filter action
Security methods supported
IPsec – Secure Request Mode (Ignore Inbound, Allow Outbound)
ESP – SHA-1,
IPsec – Full Require Mode (Ignore Inbound, Disallow Outbound)
ESP – SHA-1,
IPsec – Require Encryption Mode (Ignore Inbound, Disallow Outbound)
ESP – SHA-1, 3DES
ESP – SHA-1, 3DES ESP – SHA-1, 3DES
Woodgrove uses IPsec ESP instead of AH because of the presence of network devices in the organization that use NAT. Woodgrove Bank also had a requirement to implement encryption for some of the servers in the organization. Therefore, all policies needed the option to use encryption. For these reasons, Woodgrove Bank chose to implement its security based solely on IPsec ESP. For ESP integrity, Woodgrove Bank chose to use SHA-1 instead of MD5 for its stronger security, but also because it is required to meet U.S. government regulations on processing financial information that included using approved algorithms. Woodgrove Bank chose not to implement PFS on any of the filter actions because it did not have a specific security threat that required the use of PFS. Woodgrove also made this decision to avoid the performance impact on the computers caused by the key renegotiation.
Isolation Domain Filter Action To implement the Isolation domain, the Woodgrove Bank administrators created the IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) filter action. Woodgrove Bank has several business requirements for communication between hosts in the Isolation domain and other isolation groups. Accordingly, clients in the Isolation domain perform the following actions described in the tables 4.5 and 4.6 of Chapter 4 of this guide: •
Initiate communications with hosts in the No Fallback isolation group
•
Accept communications from hosts in the No Fallback isolation group
•
Initiate communications with hosts in the Encryption isolation group
•
Accept communications from hosts in the Encryption isolation group
•
Initiate communications with hosts in the Boundary isolation group
•
Accept communications from hosts in the Boundary isolation group
•
Initiate communication to untrusted systems
Clients in the Isolation domain cannot accept communications from untrusted systems. Remember that IPsec policy uses filters and filter actions to intercept and control inbound and outbound IP packets. Although IKE does authenticate both computers, the group membership of a computer using a certain IP address is not known at the time the initial connection request is sent outbound. Therefore, IPsec and IKE cannot be configured specifically to initiate communications in a certain way with a particular identity or isolation group. Also, computers that are members of these isolation groups may be located anywhere on the internal network. Therefore, you cannot use IP addresses to define or approximate isolation groups.
110
Server and Domain Isolation Using IPsec and Group Policy
In order to implement these requirements in an IPsec policy, you must design the filter action to work with the filter list that specifies all internal subnets. You can reduce the preceding requirements into two basic behaviors: •
Outbound, for packets matching the corresponding filters (all internal subnets), trigger IKE negotiation requests that attempt to secure traffic with IPsec ESP, preferring ESP-null, and including ESP–SHA-1–3DES. Allow Fall back to clear if a target destination host does not respond with IKE.
•
Inbound, for packets matching the corresponding filters (all internal subnets), ignore traffic if it is not already secured inside valid IPsec ESP packets.
To enable communications with the Encryption isolation group, the security methods include the security methods (ESP–SHA-1–3DES algorithms) that are defined for the Encryption isolation group. For more information about the encryption security negotiation methods, see the "Encryption Isolation Group Filter Action" section later in this chapter. For traffic within the Isolation domain, and with the Boundary and No Fallback isolation groups, Woodgrove Bank uses ESP-null with SHA-1. You must disable the Accept unsecured communication, but always respond with IPsec option on the filter action so that inbound plaintext will be ignored. This approach ensures that hosts in the Isolation domain will not accept traffic from any computer that is not participating in the IPsec environment. The IPSEC – Secure Request Security (Ignore Inbound, Allow Outbound) filter action is configured to allow the members of the Isolation domain to initiate communications with untrusted systems. This behavior is implemented by enabling the Allow unsecured communication with non-IPsec-aware computers option on the filter action. If a trusted host in the Isolation domain initiates an outbound connection to an untrusted host (or another non-IPsec-aware system), the IPsec soft SA is established and remains active for five minutes after traffic stops flowing. Therefore, that untrusted system is able to initiate new plaintext connections back into the trusted host during this time. After the soft SA times out, the trusted host will no longer accept plaintext traffic from that system. IPsec filtering and soft SA support was not designed to provide connection-specific protections, such as stateful filtering, like many firewalls do. Soft SAs allow all traffic that matches the associated filter. For more information about this process, see the "IKE Main Mode SAs and IPsec SAs" section of Appendix A, "Overview of IPsec Policy Concepts."
Boundary Isolation Group Filter Action To implement the Boundary isolation group, the Woodgrove Bank administrators created the IPSEC – Request Mode (Accept Inbound, Allow Outbound) filter action. Woodgrove Bank has several business requirements regarding communication between hosts in the Boundary isolation group and other isolation groups. Accordingly, clients in the Boundary isolation group can perform the following actions described in tables 4.5 and 4.6 of Chapter 4: •
Initiate communications with hosts in the No Fallback isolation group
•
Accept communications from hosts in the No Fallback isolation group
•
Initiate communications with hosts in the Isolation domain
•
Accept communications from hosts in the Isolation domain
•
Accept communications from hosts in the Encryption isolation group
•
Initiate communications with untrusted systems
•
Accept communications from untrusted systems
Chapter 5: Creating IPsec Policies for Isolation Groups
111
In order to implement these requirements in an IPsec policy, you must design the filter action to work with the filter list that specifies all internal subnets. It is possible to reduce the listed requirements into two basic behaviors: •
Outbound, for packets matching the corresponding filters (all internal subnets), trigger IKE negotiation requests that attempt to secure traffic with IPsec ESP, preferring ESP-null, and including ESP–SHA-1–3DES. Allow Fall back to clear if a target destination host does not respond with IKE.
•
Inbound, accept plaintext packets that match the corresponding filters (all internal subnets).
To meet the requirements for initiating and accepting traffic to or from the Isolation domain and the No Fallback isolation group, Woodgrove Bank ensured that the security negotiation methods used for the Isolation domain and No Fallback isolation group are present in the filter action. The common security negotiation method that Woodgrove selected is ESP with SHA-1 for integrity. Hosts in the Boundary isolation group are allowed to communicate with untrusted systems. To facilitate this capability, the Woodgrove Bank administration team enabled both the Allow unsecured communication with non-IPsec-aware computers and Accept unsecured communication, but always respond with IPsec options for this filter action. By enabling both of these options, Woodgrove Bank ensured that the hosts will accept inbound unsecured traffic and be able to Fall back to clear for outbound unsecured traffic.
No Fallback Isolation Group Filter Action To implement the No Fallback isolation group, the Woodgrove Bank administrators created the IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) filter action. Woodgrove Bank has several business requirements for communication between hosts in the No Fallback isolation group and other isolation groups. Accordingly, clients in the No Fallback isolation group can perform the following actions: •
Initiate communications with hosts in the Isolation domain
•
Accept communications from hosts in the Isolation domain
•
Initiate communications with hosts in the Encryption isolation group
•
Accept communications from hosts in the Encryption isolation group
•
Initiate communications with hosts in the Boundary isolation group
•
Accept communications from hosts in the Boundary isolation group
Clients in the No Fallback isolation group can neither initiate communications to nor accept communications from untrusted systems. To implement these requirements in an IPsec policy, you must design the filter action to work with the filter list that specifies all internal subnets. It is possible to reduce the listed requirements into two basic behaviors: •
Outbound, for packets matching the corresponding filters (all internal subnets), trigger IKE negotiation requests that attempt to secure traffic with IPsec ESP, preferring ESP-null, and including ESP–SHA-1–3DES. Do not allow Fall back to clear if a target destination host does not respond with IKE.
•
Inbound, for plaintext packets matching the corresponding filters (all internal subnets), ignore them.
To enable communications with the Encryption isolation group, the security negotiation methods include the encryption negotiation methods that are defined for the Encryption
112
Server and Domain Isolation Using IPsec and Group Policy
isolation group. For more information about the encryption security negotiation methods, see the following "Encryption Isolation Group Filter Action" section in this chapter. For traffic to the Boundary isolation group and No Fallback isolation group, Woodgrove Bank uses ESP with SHA-1 for the integrity security negotiation method. The Accept unsecured communication, but always respond with IPsec checkbox on the filter action is cleared to create the No Fallback isolation group. This approach ensures that hosts in the No Fallback isolation group must secure all inbound and outbound traffic with IPsec. They will not accept traffic from any computer that is not participating in the IPsec environment. The IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) filter action will not allow a computer that uses this filter action to initiate communication to a computer that does not participate in the IPsec infrastructure. The Allow unsecured communication with non-IPsec-aware computers option was disabled to enforce this requirement.
Encryption Isolation Group Filter Action Woodgrove Bank chose ESP as its base integrity protocol and SHA-1 as the cryptographic option. In addition, hosts in the Encryption isolation group need to communicate with the hosts in the Isolation domain and No Fallback isolation group. The filter action was configured to include the security negotiation methods that encrypt the information. Woodgrove Bank has several business requirements regarding the communication between hosts in the Encryption isolation group and other isolation groups. Accordingly, clients in the Encryption isolation group can perform the following actions from table 4.6: •
Initiate communications with hosts in the Isolation domain
•
Accept communications from hosts in the Isolation domain
•
Initiate communications with hosts in the No Fallback isolation group
•
Accept communications from hosts in the No Fallback isolation group
•
Initiate communications with hosts in the Boundary isolation group
Computers in the Encryption isolation group are prohibited from accepting communications from hosts in the Boundary isolation group. To implement these requirements in an IPsec policy, the filter action must be designed to work with the filter list that specifies all internal subnets. It is possible to reduce the listed requirements into two basic behaviors: •
Outbound, for packets matching the corresponding filters (all internal subnets), trigger IKE negotiation requests that attempt to secure traffic only with IPsec ESP–SHA-1– 3DES. Do not allow Fall back to clear if a target destination host does not respond with IKE.
•
Inbound, for plaintext packets matching the corresponding filters (all internal subnets), ignore them. Accept only IKE negotiation requests from trusted hosts that allow IPsec ESP–SHA-1–3DES.
Clients in the Encryption isolation group cannot accept communications from the Boundary isolation group and can neither initiate communications with nor accept communications from untrusted systems. To enable communications with the Isolation domain, the encryption security negotiation methods used in the IPSEC – Require Encryption Mode (Ignore Inbound, Disallow Outbound) are also present in the IPSEC – Secure Request (Ignore Inbound, Allow Outbound) and the IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound)
Chapter 5: Creating IPsec Policies for Isolation Groups
113
filter actions. Woodgrove Bank uses the 3DES encryption method, which provides better security than DES but at the cost of additional overhead. Because of the requirement to neither accept nor initiate communications with untrusted systems, Woodgrove Bank did not enable the Accept unsecured communication, but always respond with IPsec option. This configuration ensures that hosts in the Encryption isolation group will not accept traffic from any computer that is not participating in the IPsec environment. In addition, the Allow unsecured communication with non-IPsec-aware computers option was also disabled to prevent computers from attempting to initiate communications with any computer that was not participating in the IPsec environment. Blocking IPsec communications from the Boundary isolation group computers required additional configuration. The Woodgrove Bank administrators configured the GPO that delivers the IPsec policy for the Encryption isolation group computers with the "Deny access to this computer from the network" right. This right was applied to a group that had all of the computer accounts for the systems participating in the Boundary isolation group. If any of these computers attempted to initiate communications with a system in the Encryption isolation group, the IKE authentication would result in an authorization failure, and the communication would be blocked.
IPsec Policies IPsec policies configure Windows-based computers to function in an IPsec environment. An IPsec policy is a collection of rules against which traffic is matched. There are three different types of IPsec policy for Windows 2000: •
Local Policy
•
Active Directory Domain Policy
•
Dynamic Policy
Windows XP and Windows Server 2003 support the following additional policy types: •
Startup IPsec Policy. Stored and managed in local registry. Supported only in Windows XP SP2 or later. Applies as soon as the computer obtains an IP address, which can be before the IPsec service starts. Replaced when service applies persistent policy.
•
Persistent IPsec Policy. Stored and managed in registry on local computer. Configured by command-line tool. Applies first when the IPsec service starts. Replaces the startup policy.
•
Local IPsec Policy. Stored and managed on local computer. Configured by IPsec Policy Management MMC (Microsoft Management Console) snap-in or command-line tool. Applies in addition to persistent policy if no domain policy is assigned.
•
Active Directory Domain IPsec Policy. Stored in Active Directory. Managed by IPsec Policy Management MMC snap-in or command-line tool. Overrides any local policy that may have been assigned. Active Directory IPsec policies are assigned to a GPO using the Group Policy Editor MMC snap-in or the Group Policy Management Console under Windows Settings, Security Settings, IPsec Policies.
•
Dynamic IPsec Policy. Stored only in memory. Configured by command-line tool. Used to dynamically add to the existing policy. The dynamic policy will be discarded when the IPsec service stops.
For simplicity, this guidance focuses on using Active Directory Domain IPsec Policy. When defining IPsec policies, it is best to try to design a generic policy that will establish a foundation for the IPsec infrastructure for all computers. Then you can create additional policies to enforce more stringent settings on systems that need additional security
114
Server and Domain Isolation Using IPsec and Group Policy
configuration. You should design each additional policy to affect the greatest number of computers that need to meet the particular business or technical requirement. Keeping the total number of policies to a minimum will make it easier to troubleshoot and manage the policies. IPsec policies comprise a name, description, set of rules, and configuration settings for polling intervals, key exchange settings, and key exchange methods, all of which the following section discusses in more detail.
Name You should give policies, like filter actions, meaningful names to help in the management and troubleshooting of the solution during both the implementation and operations phases of the project.
Description A detailed description of the policy will help administrators identify what the policy enforces without having to actually open the policy and study its rules.
Rules An IPsec rule consists of a single filter list, an associated filter action, the authentication methods used to establish the trust between computers, the connection type, and whether the rule is a tunnel configuration. Each rule defines one or more authentication methods to use for establishing trust between the hosts. The options are the Kerberos version 5 protocol, certificates from a specific certification authority, and preshared keys. The connection type defines the connections to which the IPsec policy applies. You can configure the policy to apply to all connections, local area connections, or remote accessbased connections. The tunnel type defines whether the IPsec policy defines an IPsec tunnel. If the tunnel type is disabled, IPsec uses transport mode. To support the security isolation groups identified earlier in this guide, Woodgrove Bank implemented four IPsec policies. It configured all four policies so that they used the Kerberos version 5 authentication protocol, applied to all connections, and did not define an IPsec tunnel. The following table shows the policies used in the Woodgrove Bank scenario: Table 5.6 Woodgrove Bank IPsec Policies Policy name
Description
IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600)
This policy defines the Isolation domain. Hosts in this isolation group are able to Fall back to clear when initiating communications with non-IPsec hosts. It configures hosts to require IPsec communication. If negotiation fails between IPsec-aware clients, the communication will fail.
IPSEC – Boundary Isolation Group IPsec Policy (1.0.041001.1600)
This policy defines the Boundary isolation group. It configures hosts to request IPsec communications but allows them to Fall back to clear if communications need to occur with a non-IPsec-based host.
Chapter 5: Creating IPsec Policies for Isolation Groups
115
Policy name
Description
IPSEC – No Fallback Isolation Group IPsec Policy (1.0.041001.1600)
This policy defines the No Fallback isolation group. It configures hosts to require IPsec communication. If negotiation fails or communication is attempted with a client that does not use IPsec, the communication will fail.
IPSEC – Encryption Isolation Group IPsec Policy (1.0.041001.1600)
This policy defines the Encryption isolation group. It configures hosts to require IPsec communication and encryption. If negotiation fails or communication is attempted with a client that does not use IPsec, the communication will fail.
The number associated with each policy name is a version number and is discussed later in the "Policy Versioning" section. Each of the Woodgrove Bank policies contains the same exemption lists, because there are no requirements for exempting a special set of computers for one particular isolation group. The following table shows the enabled rules that are the same across the four policies identified in the previous table: Table 5.7 Common Rules Defined in Woodgrove Bank IPsec Policies Filter list
Filter action
Authentication methods
Tunnel endpoint
Connection type
DNS Exemption List
IPSEC – Permit
None
None
All
Domain Controllers Exemption List
IPSEC – Permit
None
None
All
WINS Exemptions List
IPSEC – Permit
None
None
All
DHCP, Negotiation Traffic
IPSEC – Permit
None
None
All
ICMP, All Traffic
IPSEC – Permit
None
None
All
In addition to the rules listed in this table, the default client response rule in each of the policies is disabled. The four policies that Woodgrove Bank defined only differ in how they handle the remaining traffic that is not handled by any of the exemption filter lists. For each of these rules, the authentication method is set to Kerberos version 5 protocol, the tunnel endpoint is set to None, and the connection type is set to All. The following table shows the Woodgrove Bank rules for implementing the four isolation groups: Table 5.8 Woodgrove Bank Base Rules for Implementing Isolation Groups Policy name
Filter list
Filter action
IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600)
Woodgrove Bank Secure Subnets
IPsec – Secure Request Mode (Ignore Inbound, Allow Outbound)
116
Policy name
Server and Domain Isolation Using IPsec and Group Policy
Filter list
Filter action
IPSEC – Boundary Isolation Group Woodgrove Bank IPsec Policy (1.0.041001.1600) Secure Subnets
IPsec – Request Mode (Accept Inbound, Allow Outbound)
IPSEC – No Fallback Isolation Group IPsec Policy (1.0.041001.1600)
Woodgrove Bank Secure Subnets
IPsec – Full Require Mode (Ignore Inbound, Disallow Outbound)
IPSEC – Encryption Isolation Group IPsec Policy (1.0.041001.1600)
Woodgrove Bank Secure Subnets
IPsec – Require Encryption Mode (Ignore Inbound, Disallow Outbound)
Woodgrove Bank chose to use the Kerberos version 5 protocol as its only authentication protocol. Woodgrove did not use preshared keys because the authentication key value can be read by local administrators in the registry, and by any authenticated user and computer in the domain. Woodgrove did not choose certificates because the bank does not have a deployed public key infrastructure (PKI). By using the Kerberos version 5 protocol, all domain-joined computers are able to participate in the IPsec infrastructure because they can authenticate and obtain policy. Computers that are not joined to the domain are not able to easily participate in the IPsec environment because of the lack of an authentication mechanism and policy distribution system. If these computers meet trusted host criteria, you can configure an IPsec local policy using certificate authentication to enable them to communicate with other trusted hosts. Woodgrove Bank treats non-domain computers as untrusted at the current time. Note Using the Kerberos version 5 protocol for IKE authentication does not prevent nondomain-based computers from participating in the IPsec environment. For example, if a UNIX system is configured properly to use Active Directory as its Kerberos realm and the IKE implementation supports Kerberos authentication, then it may be possible for it to participate in the Isolation domain. However, such a configuration is beyond the scope of this document and has not been tested by Microsoft.
Polling Intervals There are two polling intervals to consider: the Group Policy polling interval, and the IPsec service polling interval. The default setting for the IPsec service policy change polling interval is 180 minutes between consecutive polls for changes in Active Directorybased IPsec policies. These polls check only for changes in the IPsec policy, they do not detect changes in domain or organizational unit (OU) membership or the assignment or removal of an IPsec policy in a GPO. Changes to the computer's OU membership and assignment of GPOs are detected through the Group Policy service polling, which occurs every 90 minutes by default. Woodgrove Bank chose to set both polling intervals to 60 minutes so that in case a security response was needed, policies could be updated and deployed within one hour to mitigate the risk. This increased polling frequency introduced additional polling traffic in the form of LDAP queries from the client to check the timestamps on the IPsec policies. Although this did not introduce a significant overhead in the Woodgrove Bank scenario, in deployments with a large number of clients, this increase may become significant.
Key Exchange Settings The following key exchange settings define how new keys are derived and how often they are renewed. The term "master key" means the Diffie-Hellman shared secret key material generated in IKE main mode. The term "session key" refers to keys generated
Chapter 5: Creating IPsec Policies for Isolation Groups
117
by IKE quick mode for use in the IPsec integrity and encryption algorithms. Session keys are derived from the master key. •
Perfect forward secrecy (PFS). There are two types of PFS in IKE, Master key PFS (which means main mode PFS), and Session key PFS (which means quick mode PFS). Main mode PFS is not recommended because the functionality is duplicated by other supported key exchange settings. Main mode PFS requires that IKE should reauthenticate and negotiate a new master key each time a quick mode is performed to refresh session keys. This requirement ensures that every time any cryptographic key needs to be refreshed, the two computers start from the beginning with a new IKE main mode and quick mode negotiation. This additional protection comes at a cost of additional overhead. Session key PFS generates a new master key during quick mode (without main mode authentication) and then derives new session keys from the new master key. This functionality ensures that a large amount or all data in the communication is not protected by just one master key value, and a smaller amount of encrypted data would be revealed if an attacker were able to discover the master key. Session key PFS is supported as a checkbox in the security methods for a filter action. You should use Session key PFS only where IPsec protected traffic is at risk of sophisticated cryptographic attacks on the Diffie-Hellman master key.
•
Authenticate and generate a new key after every minutes. This value sets the IKE main mode SA lifetime, which is 480 minutes by default. It controls how long the master key and trust relationship can be used before having to be renegotiated. The first TCP/IP connection from a unique client to the host causes a new IKE main mode SA to be created. Unlike soft SAs, main mode SAs are not removed from the host after five minutes of inactivity. Main mode SAs take approximately 5 kilobytes of memory each. By adjusting this value, the administrator can optimize CPU load and memory utilization required by IKE. If you reduce the lifetime, you reduce the number of active main mode SAs on the server. This reduces memory utilization and saves IKE processing time to maintain fewer SAs. However, you can increase CPU load required to renegotiate main mode SAs for clients that communicate frequently.
•
Authenticate and generate a new key after every sessions. This setting controls the maximum number of IKE quick modes allowed during the lifetime of one main mode SA, thereby limiting the number of session keys that can be generated from the same master key. When this limit is reached, a new IKE main mode SA will be negotiated that will generate a new master key. The default setting is 0, which means that there is no limit. Therefore, the master key is only refreshed when the IKE main mode SA lifetime expires, unless quick mode PFS is used. To achieve the same behavior as the Master key PFS setting, this option is set to 1.
Woodgrove Bank chose not to use Master key PFS because it did not have specific security requirements that required it. Similarly, IKE quick mode PFS was not used in the filter actions. The IKE main mode SA lifetime was changed from 480 minutes to 180 minutes to more quickly delete main mode SAs on busy servers in all but the Boundary isolation group. For the Boundary isolation group, Woodgrove Bank administrators reduced the IKE main mode SA lifetime to 20 minutes to reduce the attack surface presented by resident main mode SAs that were negotiated with the Encrypted isolation group. Although hosts in the Boundary isolation group cannot initiate new IKE negotiations with hosts in the Encrypted isolation group, the reverse can occur. After the main mode SA has been established, then a boundary host would be able to use this SA to negotiate quick mode SAs for the protection of inbound traffic to the corresponding system in the Encrypted isolation group until the main mode SA was deleted. This risk is reduced by forcing the main mode SAs on the boundary servers to be deleted more frequently. The number of sessions for which the master key can be used to generate a session key was left at the default setting of 0.
118
Server and Domain Isolation Using IPsec and Group Policy
Key Exchange Methods The key exchange methods control the security methods that are used during main mode IKE negotiation. The configuration options are for integrity (SHA-1 and MD5), confidentiality or encryption (3DES and DES), and the length of the base prime numbers used during the key exchange process. Note Computers running Windows 2000 must have the High Encryption Pack or SP2 (or later) installed to use 3DES.
The cryptographic strength of keys used for the integrity and encryption of the IKE negotiation itself and for IPsec data protection depends on the strength of the DiffieHellman group upon which the prime numbers are based. There are three options for the Diffie-Hellman group: •
High (3) – 2048-bit keying strength. This option corresponds to the IETF RFC 3526 specification for Diffie-Hellman group 14. This key strength is required for 3DES to have maximum cryptographic strength. See IETF RFC 3526 for additional information.
•
Medium (2) – 1024-bit keying strength.
•
Low (1) – 768-bit keying strength.
The High configuration can only be used with Windows XP SP2- and Windows Server 2003-based systems. The Medium configuration provides interoperability with Windows 2000 and Windows XP SP1. Low is provided for backward compatibility and should not be used because of its relative weakness. The following table lists the key exchange security methods in order of preference that Woodgrove Bank chose to implement: Table 5.9 Default Key Exchange Security Methods Encryption Integrity Diffie-Hellman Group 3DES
SHA-1
High (3) 2048 bits
3DES
SHA-1
Medium (2) 1024 bits
3DES
MD5
Medium (2) 1024 bits
Note The use of the 2048-bit group in IPsec policy requires that the IPsec policy be configured using the Windows Server 2003 management tools, such as the IPsec Policy Management MMC snap-in or the Netsh IPsec command-line utility. This policy can be assigned in the domain to Windows 2000 platforms, which will ignore the 2048-bit option.
Policy Versioning IPsec policy designs are likely to be changed many times throughout initial planning, lab testing, pilot deployments, and while in operational use. If you use scripts, spreadsheets, or other documents to create IPsec policies, you should manage these files with a version control system similar to Microsoft Visual SourceSafe®. It is difficult to identify versions of IPsec policies within Active Directory by looking at the attributes on the policy. Troubleshooting steps will require the ability to determine which version of the IPsec policy is active on the computer. Therefore, it is recommended that you store some form of versioning information both within the name of the policy and within the policy rules.
Chapter 5: Creating IPsec Policies for Isolation Groups
119
A simple versioning method is to create a version ID based on the following formula: ... For example, 1.0.041001.1600 would be version 1.0 created on 10/01/04 at 4 P.M. You should then place this version ID at the end of the name of the policy that you are creating. For example, IPSEC – Boundary IPsec Policy (1.0.041001.1600). You can also append it to the name or description of Filter Lists, which frequently change. Group Policy retrieves the IPsec policy name, and it is stored in the local registry under HKEY_LOCAL_MACHINE \SOFTWARE\Policies\Microsoft\Windows\IPsec\GPTIPSECPolicy where it is stored as a string value under the DSIPSECPolicyName key. Although IPsec service polling checks for changes in all assigned policy objects, it does not update the name of the assigned policy that Group Policy has stored. Group Policy does not update the name in the local registry until the GPO assignment is changed. Microsoft IT found that an unused rule within the IPsec policy can be an effective means of storing the policy version information. For example, you can create a filter list with a filter that contains invalid addresses and is associated with a permit filter action, such as the following: Filter List Name: IPsec policy ver 1.0.041001.1600 Filter List Description: IPsec policy ver 1.0.041001.1600 1.1.1.1 1.1.1.2, ICMP, description = "IPsec policy ver ID 1.0.041001.1600" After you create this filter list in Active Directory, you can identify the version object distinguished name (DN) for the filter list by using the Active Directory Users and Computers MMC running in Advanced mode. You can find the filter list object under the \System\IP Security tree and identify it by its description. After you know the version object DN, you can compare it programmatically with the IPsec objects stored in the registry under HKEY_LOCAL_MACHINE \SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Cache to determine whether it is located in the cache. If you find the version object DN in cache, you can compare the policy names for the object stored in Active Directory and the object stored on the local computer. If the names are the same, the local and domain policies are synchronized. The names and descriptions of each IPsec filter list are also stored in the IPsec policy cache, which will help identify which versions of these objects are currently assigned. The IPsec service retains the text description for each filter (not filter list) in memory so that the IPsec monitor MMC snap-in and command-line tools can report this information. A script can help automate the policy version check of a client, such as the example script Detect_IPsec_Policy.vbs, which is included in the Tools and Templates folder for this solution. As policies are edited over a period of time, you should update the corresponding filter names to reflect the changes.
How to Apply IPsec Policies to Individual Computers The final step to enabling IPsec is to deploy the policies to the hosts. There are two methods of deploying the policies. One method is to apply them directly to the individual host computers, and the second is through the use of GPOs and Active Directory. Policy application through Active Directory is discussed in the "How to Apply IPsec Policies Using GPOs" section later in this chapter.
120
Server and Domain Isolation Using IPsec and Group Policy
You can accomplish the application of IPsec policies to individual computers in one of two ways: through the IPsec Security Policy Management MMC snap-in, or through the command line using Netsh (for Windows Server 2003), Ipseccmd.exe (for Windows XP), or Ipsecpol.exe (for Windows 2000). The MMC snap-in provides a graphical user interface (GUI) that the administrator can use to manually apply policy or import a previously defined IPsec policy that was exported from another computer. In addition to manipulating the policy on the local computer, administrators can use the snap-in to manage policy on a remote computer. Detailed information about the command-line tools is available from the following resources: •
Windows Server 2003 Help and Support for Netsh
•
Windows XP Service Pack 2 Support Tools documentation for Ipseccmd.exe
•
Windows 2000 Server Resource Kit for Ipsecpol.exe
Microsoft provided updated IPseccmd and other support tools for Windows XP SP2. For more information see Microsoft Knowledge Base article 838079, "Windows XP Service Pack 2 Support Tools". Detailed information about the use of these tools is beyond the scope of this guidance. The examples in this guide are geared toward using Netsh on servers running Windows Server 2003.
How to Apply IPsec Policies Using GPOs Active Directory Group Policy is used as the IPsec policy assignment and distribution mechanism for domain-joined computers. Before distributing the policies through the Group Policy distribution mechanisms in Active Directory, you must first configure the GPOs that will be used to apply the IPsec policies to the host computers. Note Although the following section discusses loading IPsec policies directly into Active Directory, it is assumed that the policies were created and tested on a local system, in a test lab, and in small-scale pilot projects before being deployed to a production environment.
How to Load IPsec Policies into Active Directory The first task in implementing IPsec policies through Active Directory is to create the filter lists, filter actions, and IPsec policies in the directory service. You can perform this task using the IPsec Security Policy Management MMC snap-in or a command-line tool such as Netsh. Regardless of which tool you select, you must perform the following three subtasks to implement the IPsec policies: 1. Create the filter lists and filters identified in the "IPsec Filter Lists" section of this chapter. 2. Create the filter actions identified in the "IPsec Filter Actions" section of this chapter. 3. Create the IPsec policies identified in the "IPsec Policies" section of this chapter.
Using the IPsec Security Policy Management MMC Snap-in The IPsec Security Policy Management MMC snap-in is a GUI-based tool that allows administrators to create, configure, and edit IPsec policies on local computers, remote computers, or domains. Configuration of the IPsec components is a manual process that involves direct editing of the objects being created and is guided by wizards.
Chapter 5: Creating IPsec Policies for Isolation Groups
121
After the IPsec policies are defined locally or in Active Directory, the administrator can export the IPsec policies (including all filter lists and filter actions) to a file ending with an .ipsec file name extension. You can copy this file to other media for backup purposes. If a backup of the IPsec policies exists, you can use the tool to import the backed-up policies into Active Directory. You can use this approach for recovery purposes or to move IPsec policy files from a test forest into a production forest without having to recreate each filter list, filter action, and policy manually. Thoroughly review the design of policies that are restored from backup. Testing is recommended to assess the impact of applying old settings in the current environment. An old backup file may contain policy settings, such as filter lists, or filter actions, which are invalid and may cause communicate to fail if they were assigned to current domain members. For more information about using the IPsec Security Policy Management MMC snap-in, see the topic "Define IPSec Policies" in the Help and Support Center in Windows Server 2003.
Using Netsh You can use Netsh as an alternative to the IPsec Security Policy Management MMC snap-in for configuring IPsec polices within a Windows Server 2003-based Active Directory. You can run this command-line tool in an interactive mode or in batch mode. When used in interactive mode, Netsh requires the administrator to type individual commands into the Netsh command shell. Before creating the filter lists, filter actions, and IPsec policies, you must configure the tool to point to the Active Directory. To point Netsh to the Active Directory, type the following command at the Netsh prompt: ipsec static set store location=domain The administrator then enters the filter lists, filters, filter actions, and IPsec policies manually through the Netsh command shell. Like the GUI tool, Netsh supports the export and import of IPsec policy files for backup and recovery scenarios. Running Netsh in batch mode requires creation of a script file of Netsh commands. This script file must contain the command to set the focus on the domain as well as all of the configuration commands for the filter lists, filters, filter actions, and IPsec policies. You can then create the IPsec policy information in Active Directory by launching Netsh and executing the script file. The command-line syntax for launching Netsh and executing a script file is as follows: netsh –f For more information on using Netsh, see the "Netsh" topic in the "Administration and Scripting Tools" section of the Help and Support Center in Windows Server 2003. Note Netsh only works with IPsec policies on computers running Windows Server 2003. Command-line manipulation of IPsec policies on computers running Windows 2000 or Windows XP requires Ipsecpol.exe or Ipseccmd.exe, respectively. Also, Netsh lists a dump command in the IPsec context of the tool. This function is not implemented, although it is listed in the help text. In addition, unlike the GUI tool, Netsh does not support remote connections.
Creating Group Policy Objects for IPsec Policy Distribution GPOs are objects stored within Active Directory that define a set of settings to be applied to a computer. IPsec policies are not stored within GPOs directly. Instead, GPOs maintain an LDAP DN link to the IPsec policy. IPsec policies are stored in the cn=IP Security, cn=System, dc= location within Active Directory. GPOs are assigned to sites, domains, or OUs within Active Directory. Computers that are within those locations or containers receive the policy defined by the GPO unless it is otherwise blocked. The IPsec design team should consult with the Active Directory team
122
Server and Domain Isolation Using IPsec and Group Policy
to discuss the feasibility of using existing GPOs to deliver their IPsec policies. If this approach is not feasible or requires extensive modification of their management practices, new GPOs can be defined for each set of IPsec policies that will be deployed. The solution described in this guidance uses new GPOs for deployment of the IPsec policies. Although GPOs can be created through Active Directory Users and Computers or the Active Directory Sites and Services tools, it is recommended that you create the new GPOs by using the Group Policy Management Console (GPMC). Creation of a policy through the Active Directory tools automatically links the GPO to the object that is being browsed. By using the GPMC to create the GPOs, the administrator can ensure that the GPOs are created within Active Directly but not applied to computers until each GPO is explicitly linked to a site, domain, or OU. The GPMC is an add-on utility for computers running Windows XP Service Pack 1 (or later) or Windows Server 2003. The GPMC allows administrators to manage Group Policy for multiple domains and sites within one or more forests through a simplified user interface with drag-and-drop support. Key features include functionality such as backup, restore, import, copy, and reporting of GPOs. These operations are fully scriptable, which allows administrators to customize and automate management. Note that these GPO management techniques apply to managing IPsec policy objects themselves. You should develop a management strategy for managing IPsec policy in coordination with the GPOs that deliver the IPsec policy assignment. For additional information about using the GPMC, see the white paper "Administering Group Policy with the GPMC". You can download the Group Policy Management Console with Service Pack 1. Using the GPMC, the administrator creates a GPO for each IPsec policy by completing the following steps: To create a new GPO 1. Expand the domain tree, right-click the Group Policy Objects container, and then select New. 2. Type a new GPO name, and then click OK. As with IPsec filter actions and policies, you should develop a naming standard for the GPOs that includes a version number of the policy within the name—because version information of Active Directory objects is not easily obtainable. Inclusion of a version number in the policy name allows administrators to quickly identify the policy that is currently in effect. Microsoft recommends using the same naming convention that was described earlier in this chapter for filter actions and IPsec policies. For example, a GPO named "Isolation Domain IPsec GPO ver 1.0.040601.1600" would be version 1.0 created on 06/01/04 at 4 P.M. After the GPO has been created, the administrator needs to configure it to use the appropriate IPsec policy. To assign IPsec policy in a GPO 1. Launch the Group Policy Editor by right-clicking the name of the GPO and selecting Edit. 2. The available IPsec policies that can be assigned are located under Computer Configuration\Windows Settings\Security Settings\IP Security Policies in Active Directory.
Chapter 5: Creating IPsec Policies for Isolation Groups
123
3. To assign an IPsec policy, right-click the policy name in the right pane and then select Assign. Only one IPsec policy can be assigned per GPO. 4. To save the changes to the GPO, close the Group Policy Editor tool. IPsec policy is applied to host computers through the computer configuration settings on the GPO. If the GPO is only used to apply IPsec policies, it is recommended that you configure the GPO to disable the user configuration settings. Disabling these settings will help shorten the processing time of the GPO by bypassing the evaluation of user configuration options. To disable the user configuration on the GPO 1. Open the GPMC tool. 2. Right-click the GPO name in the GPMC. 3. Select GPO Status, and then User Configuration Settings Disabled. If the user configuration settings are configured in the GPO at a later date, the administrator will have to re-enable the processing of user configuration settings for them to apply.
Domain Security Groups Domain security groups serve two purposes. The first is to identify domain computer accounts that are members of an isolation group, and the second is to identify domain computer accounts that are members of a network access group. All members of an isolation group are required to receive the same IPsec policy. Therefore, you can create domain security groups for application and management of the IPsec policies instead of using OU containers to control policy assignment. Universal groups are the best option to control policy assignment because they are applicable to the entire forest and reduce the number of groups that need to be managed. However, if universal groups are unavailable, you can use domain global groups instead. Domain local groups are used for network access groups discussed in a later section. The following table lists the groups that were created for the Woodgrove Bank scenario to manage the IPsec environment and control policy application: Table 5.10 IPsec Group Names Group name
Description
No IPsec
A universal group of computer accounts that do not participate in the IPsec environment. Typically consists of infrastructure computer accounts.
CG_IsolationDomain_computers A universal group of computer accounts that are members of the Isolation domain. CG_BoundaryIG_computers
A universal group of computer accounts that are members of the Boundary isolation group and thus allowed to communicate with untrusted systems.
124
Server and Domain Isolation Using IPsec and Group Policy
Group name
Description
CG_NoFallbackIG_computers A universal group of computer accounts that are part of the No Fallback isolation group who are not allowed to perform outbound unauthenticated communications. CG_EncryptionIG_computers
A universal group of computer accounts that are members of the Encryption isolation group and thus require encryption for their communications.
In addition to the listed groups, additional groups may have been created and used to restrict the policy application during the initial rollout. When deploying IPsec, it is not recommended to just create the GPOs and IPsec policies and assign them at the same time to all computers in the domain. A domain security group can be used for precise control over which computers can read the GPOs and thus receive the corresponding IPsec policy. The GPOs that deliver IPsec policy can all be assigned to the entire domain. The rollout process must carefully consider whether IPsec policy is properly designed, assigned, and retrieved on all nodes that expect to negotiate IPsec. The design of the boundary group policy is typically used to allow non-IPsec communication both inbound and outbound with computers that have not yet received their IPsec policy.
Distributing IPsec Policies Through Active Directory You can control which GPOs are applied to computers in Active Directory in a combination of three ways: •
Using OUs with linked GPOs
•
Placing computer accounts in security groups that are referenced in ACLs that apply to the GPOs
•
Using Windows Management Instrumentation (WMI) filters on the GPOs
Controlling GPO application through OUs with linked GPOs is the most common form of policy application in Active Directory. This method creates OUs within Active Directory and links GPOs to sites, domains, or OUs. Computers receive policy based on their location within Active Directory. If a computer is moved from one OU to another, the policy linked to the second OU will eventually take effect when Group Policy detects the change during polling. The second method uses security settings on the GPOs themselves. A group is added to the ACL of the GPO in Active Directory. This group is then assigned Read and Apply Group Policy Permissions rights on the policy that should take effect on the computers within the group. In addition, the group is specifically denied permissions on policies that should not apply to the computers within the group. The policy is then linked at the domain level. The third method uses WMI filters on the policy to dynamically control the scope of the policy application. A WMI SQL filter is created and linked to the policy. If the condition that was queried is true, then the policy is applied; otherwise it is ignored. Computers running Windows 2000 ignore WMI filtering and will apply the policy. WMI queries can slow GPO processing and should be used only when necessary. Woodgrove Bank chose to use security groups to control the policy application rather than linking to an OU directly. Woodgrove selected this approach to easily introduce IPsec policies in the environment without having to force the policies into multiple locations or force a move of computers from one OU to another to receive the correct policy. Unless the ACLs on the GPO are extremely large, there is no additional overhead associated with this method over the first method because in both cases the ACLs have
Chapter 5: Creating IPsec Policies for Isolation Groups
125
to be evaluated. Woodgrove did not choose WMI filtering because there are Windows 2000 systems in the environment. The following table shows the final Group Policy ACL configuration. Note that ACLs on IPsec policy objects themselves are not used and are not recommended. Table 5.11 Woodgrove Bank Policy GPO Permissions GPO name
Security group name
Rights assigned
IPSEC – Isolation Domain Policy
No IPsec
Deny Apply Group Policy
CG_IsolationDomain_computers Allow Read and Apply Group Policy IPSEC – Boundary Group Policy
IPSEC – No Fallback Isolation Group Policy
IPSEC – Encryption Isolation Group Policy
No IPsec
Deny Apply Group Policy
CG_BoundaryIG_computers
Allow Read and Apply Group Policy
No IPsec
Deny Apply Group Policy
CG_NoFallbackIG_computers
Allow Read and Apply Group Policy
No IPsec
Deny Apply Group Policy
CG_EncryptionIG_computers
Allow Read and Apply Group Policy
Isolation Domain Woodgrove Bank chose to link the Isolation Domain policy to the domain level in each domain in the organization. The policy uses an ACL, which prevents anyone who is not a member of the CG_IsolationDomain_computers group from applying the policy. The Authenticated Users group's Apply Group Policy rights were removed from the policy ACL. The Isolation Domain policy is the policy that all computers in the organization use as their default IPsec security policy. Accordingly, the Domain Computers group is granted Read access to the policy. The Authenticated Users group's Apply Group Policy rights were removed from the policy ACL. During the initial rollout, the Domain Computers group was removed from the ACL, and another temporary security group was used to control who could receive this policy. This approach allowed for a staged deployment of this policy.
Boundary Isolation Group Woodgrove Bank chose to link the Boundary isolation group policy to the domain level in each domain in the organization. The policy uses an ACL, which prevents anyone who is not a member of the CG_BoundaryIG_computers group from applying the policy. The Authenticated Users group's Apply Group Policy rights were removed from the policy ACL. If there is a business need for a system to accept communications from untrusted systems, the computer account of the system can be added to the CG_BoundaryIG_computers security group.
126
Server and Domain Isolation Using IPsec and Group Policy
No Fallback Isolation Group Woodgrove Bank chose to link the No Fallback isolation group policy to the domain level in each domain in the organization. The policy uses an ACL, which prevents anyone who is not a member of the CG_NoFallbackIG_computers group from applying the policy. The Authenticated Users group's Apply Group Policy rights were removed from the policy ACL. If there is a business need for a system to be denied the ability to initiate communications with untrusted systems, the computer account of the system can be added to the CG_NoFallbackIG_computers group.
Encryption Isolation Group Woodgrove Bank chose to link the Encryption isolation group policy to the domain level in each domain in the organization. This policy uses an ACL, which prevents anyone who is not a member of the CG_EncryptionIG_computers group from applying the policy. The Authenticated Users group's Apply Group Policy rights were removed from the policy ACL. If there is a business need for a system to communicate only with encrypted traffic, the computer account of the system is added to the CG_EncryptionIG_computers group.
Authorizing Inbound Access to an Isolation Group The Woodgrove Bank requirements were to allow only a subset of trusted hosts to be authorized for inbound network access to the servers in the Encryption isolation group. Table 4.8 in Chapter 4 defined the following network access groups (NAG) to implement these requirements: •
ANAG_EncryptedResourceAccess_Users
•
ANAG_EncryptedResourceAccess_Computers
•
DNAG_EncryptedResourceAccess_Computers
When a client initiates IKE to an encryption server, IKE must obtain a Kerberos service ticket that contains the domain security group identifier that indicates whether the client computer is a member of the ANAG and/or possibly the DNAG. If all the computers in the Encryption isolation group are members of the same domain, then these NAGs can be created as domain local security groups. If the computers in the Encryption isolation group are members of separate trusted domains, then either one set of domain global groups can be used for the NAGs or domain local groups can be created in each domain. The Woodgrove Bank scenario involves only one domain, so it uses domain local groups for these NAGs. The following additional GPO was created for the purpose of defining the Access this computer from the network rights that implement the inbound authorization: •
EncryptionIG Inbound Network Authorization GPO
The CG_EncryptionIG_Computers group is given Read and Apply rights for this GPO. The Authenticated Users group is removed from the Read right, which results in this GPO being applied only to computers that are members of the Encryption isolation group. As shown in Table 4.8 of Chapter 4, the authorized client domain computer account IPSST-XP-05 is added to the ANAG_EncryptedResourceAccess_Computers network access group. The encryption server accounts themselves, IPS-SQL-DFS-01 and IPS-SQL-DFS02, are also added. However, the same result could have been achieved more easily by using the CG_EncryptionIG_computers group to manage a larger list. The accounts must be authorized to have the Access this computer from the network right in some manner, whether it is through the ANAG membership, by direct inclusion of their
Chapter 5: Creating IPsec Policies for Isolation Groups
127
CG_EncryptionIG_computers group, or through explicit listing of computer accounts in the right. Otherwise, the accounts will not be able to make IPsec-protected connections to each other, which their applications require. To simulate a large domain environment, the ANAG groups are the only groups that authorize inbound access for the Woodgrove Bank scenario. Because the Authenticated Users group includes all domain computers, it must be removed from the Access this computer from the network right. Authorized domain users must now be explicitly authorized, which could be achieved by using the built-in group for Domain Users. However, Woodgrove Bank wanted to take advantage of the ability to define inbound network access restrictions for users as well as computers. Therefore, it created a domain local security group called ANAG_EncryptedResourceAccess_Users and populated it with authorized application user accounts (such as User7) as well as the local administrators group and the domain administrator groups. These user-level network access restrictions occur during upper layer protocol (such as RPC, SMB, and SQL) authentication requests after successful IPsec ESP 3DES connectivity is established. The following domain security groups were created for network logon rights for the encryption servers. They reside in the GPO under Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment, Access this computer from the network right: •
ANAG_EncryptedResourceAccess_Computers
•
ANAG_EncryptedResourceAccess_Users
The following group is configured for the same GPO, Deny Access to this computer from the network: •
DNAG_EncryptedResourceAccess_Computers
Assuming User7 cannot log on to the encryption servers directly, the result is that User7 must use the IPS-ST-XP-05 client computer to access either IPS-SQL-DFS-01 or IPSSQL-DFS-02 servers. The IPS-ST-XP-05 computer must have a valid domain computer account and an active IPsec policy that initiates IKE negotiation to the encryption servers' IP addresses. Note that the rest of the user and computers in the domain are effectively denied access, because they are purposely omitted from the Access this computer from the network right. Only the Boundary computers are explicitly denied access through the use of the DNAG as a defense-in-depth measure against future group membership changes that might include a boundary computer account in an ANAG. An explicit deny parameter overrides all forms of allow.
Additional IPsec Considerations In addition to defining the IPsec policies, there are some additional considerations for a successful IPsec implementation. The Business_Requirements.xls spreadsheet in the Tools and Templates folder provides details of constraints when using IPsec.
Default Exemptions In Windows 2000 and Windows XP, the following types of traffic are exempt from filter matches by default: •
Broadcast
•
Multicast
•
Kerberos authentication protocol
128
Server and Domain Isolation Using IPsec and Group Policy
•
IKE
•
Resource Reservation Protocol (RSVP)
In the Windows Server 2003 family of operating systems, traffic from the broadcast, multicast, RSVP, and Kerberos authentication protocols is not exempt from filter matches by default (only IKE traffic is exempt). Broadcast and multicast packets will be dropped if they match a filter with a filter action to negotiate security. By default, the Windows Server 2003 family provides limited support for filtering broadcast and multicast traffic. A filter with a source address of Any IP Address will match multicast and broadcast addresses. A filter with a source address of Any IP Address and a destination address of Any IP Address will match inbound and outbound multicast addresses. You can use such a filter to block all traffic. One-way filters that would be used to block or permit specific multicast or broadcast traffic, however, are not supported. As a result of the change in default exemption behavior for the Windows Server 2003 family implementation of IPsec, you should verify the behavior of IPsec policies designed for Windows 2000 or Windows XP and determine whether to configure explicit permit filters to permit specific traffic types. To restore the default Windows 2000 and Windows XP behavior for IPsec policies, you can use the Netsh command or modify the registry. To restore the IPsec driver to the default Windows 2000 and Windows XP filtering behavior using Netsh 1. Type the following command at a Netsh prompt and then press ENTER: netsh ipsec dynamic set config ipsecexempt 0 2. Restart the computer. To exempt all broadcast, multicast, and IKE traffic from IPsec filtering by modifying the registry 1. Set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\NoDefaultExe mpt DWORD registry setting to a value of 1. The NoDefaultExempt key does not exist by default and must be created. 2. Restart the computer.
NAT-Traversal Because of the way that network address translators work, clients may experience unexpected results when communicating with servers running Windows 2000 Server or Windows Server 2003 behind a network address translator that uses IPsec NAT-T. By default, Windows XP SP2 no longer supports IPsec NAT-T security associations to such servers. This change was made to avoid a perceived security risk for a situation in which the following sequence of events occurs: 1. A network address translator is configured to map IKE and IPsec NAT-T traffic to a server on a NAT-configured network (Server 1). 2. A client from outside the NAT-configured network (Client 1) uses IPsec NAT-T to establish bidirectional security associations with Server 1. 3. A client on the NAT-configured network (Client 2) uses IPsec NAT-T to establish bidirectional security associations with Client 1.
Chapter 5: Creating IPsec Policies for Isolation Groups
129
4. A condition occurs that causes Client 1 to re-establish the security associations with Client 2 because of the static network address translator mappings that map IKE and IPsec NAT-T traffic to Server 1. This condition may cause the IPsec security association negotiation traffic that is sent by Client 1 and that is destined for Client 2 to be misrouted to Server 1. Although this is an unlikely situation, the default behavior on Windows XP SP2-based computers prevents any IPsec NAT-T-based security associations to servers that are located behind a network address translator to ensure that it never occurs. If there is a requirement for IPsec communication across NAT, it is recommended that you use public IP addresses for all servers that can be connected to directly from the Internet. If this configuration is not possible, then you can change the default behavior of Windows XP SP2 to enable IPsec NAT-T security associations to servers that are located behind a network address translator. To create and configure the AssumeUDPEncapsulationContextOnSendRule registry value 1. Click Start and Run, type regedit and then click OK. 2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec 3. On the Edit menu, point to New, and then click DWORD Value. 4. In the New Value #1 box, type the following, and then press ENTER: AssumeUDPEncapsulationContextOnSendRule Note
This value name is case-sensitive.
5. Right-click AssumeUDPEncapsulationContextOnSendRule, and then click Modify. 6. In the Value data box, type one of the following values: •
0 (default). A value of 0 (zero) configures Windows so that it cannot establish security associations with servers that are located behind network address translators.
•
1. A value of 1 configures Windows so that it can establish security associations with servers that are located behind network address translators.
•
2. A value of 2 configures Windows so that it can establish security associations when both the server and the Windows XP SP2-based client computer are behind network address translators.
Note The configuration represented by value 2 exists in the original release version of Windows XP and in Windows XP Service Pack 1 (SP1).
7. Click OK, and then close the Registry Editor. 8. Restart the computer. After configuring AssumeUDPEncapsulationContextOnSendRule with a value of 1 or a value of 2, Windows XP SP2 can connect to a server that is located behind a network address translator.
130
Server and Domain Isolation Using IPsec and Group Policy
Windows Server 2003-based servers also require an update to operate correctly with IPsec when placed behind a NAT device, see the following URL for information on how to get Windows Server 2003 Service Pack 1. Note For more information, see Knowledge Base article 885348, "IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators". This article explains the security risks of using this scenario. Each customer must evaluate the benefits of using IPsec in this scenario against the security risks associated with it. Although Microsoft does not recommend the scenario because of the associated security risks, Microsoft will support the scenario using the configuration documented in this solution.
For inbound NAT connections to successfully work, PMTU discovery must be enabled and functioning. Some sources, such as the Windows XP Hardening Guide and the Windows Server 2003 Hardening Guide, recommend disabling PMTU discovery, and in some cases, they provide policy templates that disable the PMTU discovery functionality. To enable PMTU Discovery 1. Click Start and Run, type regedit and then click OK. 2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\ parameters 3. On the Edit menu, point to New, and then click DWORD Value. 4. In the New Value #1 box, type EnablePMTUDiscovery and then press ENTER. 5. Right-click EnablePMTUDiscovery, and then click Modify. 6. In the Value data box, type 1 7. Click OK, and then close the Registry Editor. 8. Restart the computer. In addition, hosts running Windows 2000 and participating in a NAT-T scenario require the application of the hotfix associated with Knowledge Base article 818043, "L2TP/IPSec NAT-T update for Windows XP and Windows 2000". For additional information, see Knowledge Base article 885407, "The default behavior of IPSec NAT traversal (NAT-T) is changed in Windows XP Service Pack 2".
IPsec and Windows Firewall Windows Firewall on computers running Windows XP SP2 provides additional protection against attacks by blocking incoming unsolicited traffic. IPsec in Windows XP SP2 is Windows Firewall-aware. When there is an active IPsec policy, the IPsec components of Windows XP SP2 instruct Windows Firewall to open UDP ports 500 and 4500 to allow IKE traffic. An additional feature of IPsec support is that you can specify through Group Policy that all IPsec-protected traffic bypass Windows Firewall processing. For more information, see Appendix A of the white paper, "Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2".
IPsec and Internet Connection Firewall (ICF) For Windows XP-based computers not running SP2, the Internet Connection Firewall (ICF) may better meet the security requirements for filtering traffic. ICF does provide filtering and can block inbound multicast and broadcast traffic in Windows XP SP1. However, ICF is not aware of traffic that is protected by IPsec AH or ESP in transport or
Chapter 5: Creating IPsec Policies for Isolation Groups
131
tunnel mode. Because IPsec operates in the network layer below ICF and IKE operates above ICF, a static permit for IKE (UDP port 500) should be set for inbound traffic. If IPsec blocks traffic, the ICF dropped packet log will not contain the packets that IPsec discarded.
Summary This chapter provided the information for creating and deploying IPsec polices that are based on the isolation group design that was created in Chapter 4. This information was divided into the following seven basic tasks: •
Identifying and creating filter lists
•
Identifying and creating filter actions
•
Identifying and creating rules
•
Identifying and creating IPsec policies
•
Defining a distribution mechanism for IPsec policies
•
Defining a rollout deployment method for the IPsec policies
•
Defining authorizations for inbound access control using Group Policy network logon rights configuration
These tasks complete the design and planning phases of the server and domain isolation solution. The next phase of the project is the deployment of a test or pilot environment to allow the design to be verified. Microsoft performed this verification in its test labs and used the Woodgrove Bank scenario as the pilot. If you want to recreate this environment or study the deployment stages, Appendix C of this guide contains step-by-step guidance for the deployment process that Microsoft used in its test labs to validate the design for the scenario.
More Information This section provides links to additional information about the technologies mentioned in this chapter.
General Background Information on IPsec ●
The IPsec Web site
● The Internet Protocol Security for Windows 2000 Server download provides a wide range of Windows 2000-specific IPsec content ●
The Deploying IPsec chapter from the Windows Server 2003 Deployment Kit
Additional Information ● The Windows Server 2003 Group Policy download provides a wide range of information about managing Windows systems with Group Policy in Active Directory. ● The Cable Guy—October 2004: Problems with Using Network Address Translators provides additional information on the specific issues with NAT and IPsec.
Chapter 6: Managing a Ser ver and Domain Isolation Environment This chapter provides guidance to help manage a server and domain isolation solution after successful deployment into a production environment. It is important for support staff to understand that the isolation solution adds an additional layer of security, and that more than a network connection and an IP address are needed for a host to successfully connect to a resource. Similarly, the staff that is responsible for IPsec policies and Group Policy must understand that a single, incorrectly-set option can significantly restrict the functionality of hosts that consume the policies. For these reasons, a well-documented and well-communicated set of management processes and procedures should be in place for the support teams to use after the solution becomes operational. The information provided in this chapter is designed to help you develop these solution management processes. Ideally, the information here should be customized as much as possible to reflect the needs of your own implementation. The key to success in managing a server and domain isolation solution is to plan ahead.
Chapter Prerequisites Before you use the information provided in this chapter, you should be familiar with the concepts used in the Microsoft® Operations Framework (MOF) and the concepts of IPsec. Familiarity with Microsoft Windows® 2000 Server (or later) is also required in the following areas: •
Basic operations and maintenance of Microsoft Windows Server™ 2003, including the use of tools such as Event Viewer, Computer Management, and NTBackup.
•
The Active Directory® directory service, including Active Directory structure and tools; manipulating users, groups, and other Active Directory objects; and use of Group Policy.
•
Windows system security concepts, such as users, groups, auditing, and access control lists; the use of security templates; and the application of security templates through the use of either Group Policy or command-line tools.
•
An understanding of core networking concepts, particularly with regard to IPsec and TCP/IP.
•
An understanding of Windows Scripting Host and knowledge of Microsoft Visual Basic® Scripting Edition (VBScript) will help you obtain the most benefit from the supplied scripts but is not essential.
Before proceeding with this chapter, you should read the rest of this guide and have a thorough understanding of the architecture and design of the solution.
Change Management A key goal of change management processes is to ensure that all parties affected by an impending change are aware of and understand the impact of the change. Because most systems are heavily interrelated, any changes made in one part of a system may have profound impacts on another. To mitigate or eliminate any adverse effects, change management attempts to identify all affected systems and processes before the change is deployed. Typically, the target (or managed) environment is the production environment, but it should also include key integration, testing, and staging environments. All changes to an IPsec environment should follow the standard MOF change management process: 1. Change request. The formal initiation of a change through the submission of a request for change (RFC). 2. Change classification. The assignment of a priority and a category to the change that uses its urgency and its impact on the infrastructure or users as criteria. This assignment affects the implementation speed and route. 3. Change authorization. The consideration and approval or disapproval of the change by the change manager and the change approvals board (CAB), a group of IT and business representatives. 4. Change development. The planning and development of the change, a process that can vary significantly in scope and includes reviews at key interim milestones. 5. Change release. The release and deployment of the change into the production environment. 6. Change review. A post-implementation process that reviews whether the change has achieved the goals that were established for it and determines whether to keep the change in effect or back it out. The following section outlines the change development procedures for some of the key changes that will likely be required on a regular basis in your IPsec environment. Each change development procedure will have a companion change release procedure that describes how to deploy the change into production.
Changing IPsec Policy It is important to understand how changes in IPsec policy will affect communication. As in the initial rollout, the first concern is with the timing of the changes, because this timing affects the ability to implement a change and the timeframe for rolling back the change.
Policy Application Delays When the assignment of IPsec policy in a Group Policy object (GPO) is changed to a new IPsec policy, certain delays occur. There is the Active Directory replication delay of the GPO attribute that contains the assignment in the domain, and also the polling delay of domain member Group Policy clients to detect the change in the GPO. These delays can range from less than a minute in a small location to a matter of hours in a global enterprise. Microsoft recommends that you test and document these delays (minimum, maximum, and median) for your particular environment so that when a change is introduced, the time required for the first impact and the complete rollout can be predicted.
Chapter 6: Managing a Server and Domain Isolation Environment
135
When the contents of an already assigned IPsec policy are changed, similar delays occur. There is an Active Directory replication delay of the IPsec policy objects, and also the polling delay of the IPsec policy service on the member computers. It is possible to create a condition where the replication of the policy assignment in the GPO happens before the replication of the IPsec policy, which would cause clients to behave as if they have a domain-based IPsec policy assigned—but they would not to be able to retrieve that policy. In such a case, Windows 2000 and Windows XP hosts will simply fail to apply the domain-based policy. Also, they will not apply any local policy that might be assigned. To properly accommodate Active Directory replication delays, ensure that you first create all the objects (GPO, IPsec policy, and so on) and then make the assignment of IPsec policy into the GPO.
Changes That Affect IPsec Connectivity There are many areas that can affect connectivity within the policies and groups that make up an IPsec solution. This section provides information on how common changes can affect IPsec connectivity from the perspective of changing a server policy when clients may not have the latest update. If a change causes Internet Key Exchange (IKE) main mode or quick mode to fail, then traffic flow will stop as soon as the current IPsec security associations (SAs) idle or their lifetime in bytes or in seconds expires. This discussion covers the impact of most types of changes on IPsec client-server functionality. It does not assume the Woodgrove Bank IPsec policy designs. For this discussion, clients may have policy that is similar to the Woodgrove Bank design (in which the clients have filters to initiate IKE to the server), or they may use only the default response rule (which is not used in Woodgrove's design).
Main Mode Changes Changing an authentication method or main mode security method will cause the IKE to delete the existing main modes, which will not affect established quick mode IPsec SAs. The new main mode SAs will be generated when the next quick mode rekey occurs. Generally, server policy change will not affect the ability of existing clients to rekey main mode. However, some changes on the server side that can cause IKE main mode negotiation with clients to fail include: •
Changing to a new authentication method (certificates only) without including the old authentication methods that the client can use
•
Changing to 3DES/SHA1/DH1 or DH2 as the main mode security method when clients were configured only to use DES/SHA1/DH1
•
Activating main mode perfect forward secrecy (PFS) without updating both client and server policy so that both use main mode PFS
•
Activating quick mode PFS without updating both client and server policy so that both use quick mode PFS
The following server policy changes will not affect a client's ability to rekey main mode SAs: •
Polling interval for policy changes (because it is not a main mode IKE setting)
•
Session keys that use the same master key (for example, the number of IKE quick modes per main mode)
•
Adding a new security method that clients do not know about
•
Changing the IPsec policy advanced key exchange settings for Authenticate and generate a new key lifetime parameters for IKE main mode SA
136
Server and Domain Isolation Using IPsec and Group Policy
Quick Mode Changes Any change in a filter action that was being used for an IPsec SA will cause the existing IPsec SAs that were established under those policy settings to be deleted. Therefore, a new quick mode will be attempted if traffic is flowing. Some traffic may be lost in the process of this change, but TCP connections should recover. However, for high-speed data transfers, the impact of an immediate IPsec SA deletion is that outbound traffic will be dropped until the new quick mode can be established. For example a burst of packets from a video data stream, which TCP could not recover from, will cause the connection to reset for the video application. Server policy changes that will affect the ability of active IPsec clients to rekey quick mode include the following: •
Changing from a more general filter to a more specific filter. An example of this type of change would be when a server starts with an all traffic filter and then removes it, leaving a TCP only filter. To avoid problems, keep the more generic filter in place when you add the more specific filter. For example, if clients have default response policy and a server has policy is changing from "all traffic" to "TCP only." The more specific filter will be subject to outbound traffic on the server, which will establish a new IPsec SA for TCP only when clients have default response. The "all traffic" filter on all the clients will eventually be deleted (after two hours) and can then be safely deleted in the server policy. If the server adds a more specific filter that has a permit action, that traffic will immediately begin to be permitted and may be dropped by the client with a more general IPsec default response filter. For example, an Internet Control Message Protocol (ICMP)-exempt filter gets added to a server, but the clients are already secure for all traffic to the server. In this case, the client will secure its outbound ICMP, receive a plaintext ICMP in reply, and drop the packet, because the current IPsec default response filter says all traffic must be secure. This particular example would not affect any traffic other than ICMP traffic between the server and the client and is an expected design behavior that will always produce lost ICMP traffic after the server requests security for all traffic with the client. This may or may not be a significant operational problem.
•
Changing between incompatible security methods or encapsulation types. For example, from only 3DES/SHA1 for ESP transport mode to only 3DES/MD5 for ESP transport mode. You can avoid IKE quick mode negotiation failures caused by this type of change by including the old security methods or encapsulation types as the last choice in the new security method. After you see that all IPsec SAs are using the new encapsulation method, you can delete the old method at the bottom of the security method list.
•
Entirely disabling a rule that the clients needed to establish either IKE main mode or quick mode. In quick mode, the filter will get deleted so that a different filter or no filter will govern the IKE main mode and quick mode negotiation.
•
Changing a filter action entirely from negotiate security to permit or block. Traffic that is explicitly permitted or blocked will not require a rekey as the traffic will no longer participate in a communication channel protected by IPsec.
•
Clearing the Fall back to clear check box. This action will cause currently connected clients to have connectivity for as long as the soft SA lasts. After the SA expires or idles, more server outbound traffic will cause IKE to attempt new main mode negotiation and recognize the new setting to not fall back. Clients that cannot respond successfully to the IKE negotiation will fail to connect. This may be the intended behavior.
Chapter 6: Managing a Server and Domain Isolation Environment
•
137
Clearing the Allow unsecured check box. This action will cause clients to be disconnected if they do not have IPsec filters to trigger an outbound IKE main mode initiation. Default response rule clients will stay connected until their dynamic default response filter idles out after two hours of no traffic to the server, whereupon they will not be able to reconnect.
The following server policy changes will not affect a client's ability to rekey quick mode: •
The addition of a filter that does not match traffic that is already in current IPsec SAs will not affect that traffic. For example, if permit filters are added to a server's policy for a new domain controller's IP address.
•
A change in the filter action IPsec SA lifetime, either bytes or time.
•
Changing the filter action from Permit to Negotiate security. If the clients can respond, they will still be able to negotiate a secure connection for that traffic.
IPsec Policy Change Procedures The following sections provide steps for modifying IPsec policies that are delivered by using GPOs. Although the steps presented for each task use the IP Security Policy Microsoft Management Console (MMC) snap-in, each of these tasks can also be accomplished by using the Netsh command-line tool on a Windows Server 2003 system. Microsoft recommends the Windows Server 2003 platform as a policy management station because it provides the best capabilities exist for scripting and for monitoring. Windows IPsec policy export and import is designed for backup and restore purposes. The export function copies all IPsec policy objects in the storage location to ensure that all related objects are captured in the backup. Export is the recommended method to move all of the current domain policy into local storage for testing. Because of the chance for errors, be careful to delete every unwanted object (including policies, filter lists, and filter actions) from a local store before using the export function. Microsoft does not recommend the use of an exported local store to import into the domain because of the possibility that old object versions could overwrite more recent domain versions and break links between the objects. Command line scripts are the recommended method for creating IPsec policy and making significant additions to existing objects, such as adding filters to an existing filter list. Generally, such significant changes in an IPsec policy should be done through creation of a new IPsec policy version. After the policy is created, you can use either scripts or the IPsec Policy Management MMC snap-in to make changes. After IPsec policy has been created and is operational, the IPsec Policy Management MMC snap-in is recommended to make small changes. Because the Windows 2000 command-line tool Ipsecpol.exe only supports the ability to create policy, the MMC snap-in can be used to manage changes in Windows 2000 Active Directory. The addition of a new object with the same name is not allowed in Netsh add commands. For this reason and because scripts are often run many times, Netsh scripts should include initial steps that delete policy objects that already exist before new ones are added. Deletion of a nonexistent object will return an expected error message that will not stop the script from executing. Deletion of a domain IPsec policy that is already assigned to a GPO will invalidate the GPO link. The GPO must be edited to re-assign the latest version of the IPsec policy. Note Although the following section discusses how to modify IPsec policies directly in Active Directory, it is assumed that any changes have been tested on a local system or test environment before deployment in a production environment.
138
Server and Domain Isolation Using IPsec and Group Policy
Changing IPsec Policy Assignment for an Isolation Group To change the IPsec policy assigned to an isolation group, you can replace the current IPsec policy with the new IPsec policy. The Group Policy Management Console (GPMC) is used to change the IPsec policy that a particular GPO is distributing. After identifying the new IPsec policy and the GPO that distributes the current policy, complete the following steps. To change the IPsec policy assigned to an isolation group 1. Log on to a domain controller as a domain administrator. 2. Launch the GPMC. 3. Expand the Forest: , expand Domains, and then expand . 4. Right-click GPO name, and then click Edit. 5. Expand Computer Configuration, expand Windows Settings, expand Security Settings, and then click IP Security Policies on Active Directory . 6. In the right pane, right-click and then click Assign. 7. Ensure that is assigned, and then close the GPO Editor and then the GPMC.
Changing an Existing IPsec Policy in the Domain Because the functionality of IPsec was extended in Windows XP and then again in Windows Server 2003, the IPsec policy storage format has been changed to include the settings for these extensions. Be careful not to use an IPsec Policy Management MMC snap-in from an earlier release to view or edit policy that contains these extensions. If you click OK when viewing a policy component, you will overwrite the existing settings with settings in current memory even if you made no changes. Updates were made in Windows XP service packs and Windows 2000 Service Pack 4 (SP4) to detect newer versions of policy to help avoid this potential problem. However, the MMC snap-in simply fails to save changes as if modify access was denied and use the error messages that existed at the time the product was released. Similarly, if the user running the MMC snapin only has read permission to the IPsec policy objects, then any changes will be lost when an access denied error occurs. Use the read-only mode of the IPsec Policy Management MMC snap-in in Windows Server 2003 whenever you do not intend to make changes. Finally, the MMC snap-in does not provide the ability to enter a different user ID and password when connecting to a remote computer or domain. The user must be logged on to the desktop as someone with appropriate permissions to make the intended changes.
Changing an Existing Rule Filter List There are times when it is necessary to modify an existing rule filter list to add, remove, or modify a filter item. You can use the IP Security Policy Management MMC snap-in to perform this modification. Remember that the order of a filter in a filter list has no effect on the order in which the IPsec driver will process packets. The filters for all filter lists in all rules of an IPsec policy are ordered by using an internal algorithm for weighting. To make a change, you must manually ensure that you are not creating a duplicate filter for any other filter used in the IPsec policy. As part of the change testing process, the policy should be assigned locally on a computer so that the IPsec Monitor MMC snap-in or
Chapter 6: Managing a Server and Domain Isolation Environment
139
command line output can be used to view the exact filter ordering and detect duplicate filters. To add a computer to a filter list 1. Log on to a domain controller as a domain administrator. 2. Launch the IP Security Policy Management MMC snap-in and focus it on the domain. 3. Right-click IP Security Policies on Active Directory, and then click Manage IP filter lists and filter actions. 4. On the Manage IP Filter Lists tab, in the Manage IP filter lists and actions window, click the Exemptions filter list, and then click Edit. 5. Ensure that the Use Add Wizard check box is cleared. 6. In the IP Filter List dialog box, click Add. 7. In the Source address drop-down box, click Any IP Address. 8. In the Destination address drop-down box, click A specific IP Address. 9. In the IP address text box, type the specific IP address. 10. Ensure that the Mirrored check box is selected. 11. On the Description tab, type an appropriate description for the filter item. 12. Click OK, and then click OK again. 13. Close the IP Security Policy Management MMC snap-in. Note After the new system is added to an exemptions filter list, the computer account should be added to the No IPsec security group.
To edit a computer entry in a filter list 1. Log on to a domain controller as a domain administrator. 2. Launch the IP Security Policy Management MMC snap-in and focus it on the domain. 3. Right-click IP Security Policies on Active Directory, and then click Manage IP filter lists and filter actions. 4. On the Manage IP Filter Lists tab, in the Manage IP filter lists and actions window, click the Exemptions filter list, and then click Edit. 5. Ensure that the Use Add Wizard check box is cleared. 6. In the IP Filters list, click the filter that corresponds with the system, and then click Edit. 7. In the IP address text box, change the entry to the new IP address. 8. Click OK, and then click OK again. 9. Close the IP Security Policy Management MMC snap-in. To remove an entry from a filter list 1.
Log on to a domain controller as a domain administrator.
2. Launch the IP Security Policy Management MMC snap-in and focus it on the domain. 3. Right-click IP Security Policies on Active Directory, and then click Manage IP filter lists and filter actions. 4. On the Manage IP Filter Lists tab, in the Manage IP filter lists and actions window, click the Exemptions filter list, and then click Edit. 5. In the IP Filters list, click the filter that corresponds with the system.
140
Server and Domain Isolation Using IPsec and Group Policy
6. In the IP Filter List dialog box, click Remove. 7. Click Yes to remove the filter item. 8. Click OK, and then click OK again. 9. Close the IP Security Policy Management MMC snap-in. Note After the system is removed from an exemptions filter list, the computer account should be removed from the No IPsec security group.
Changing an Existing Rule Filter Action Each rule in an IPsec policy has a corresponding filter action that is performed when the rule is matched. Although it is possible to assign a new IPsec policy to the computers that have the new rule and filter action combination, it may make more sense instead to change the filter action for a rule in an IPsec policy that already exists. For example, if a custom IPsec policy exists for a set of computers, it would make sense to change the filter action assigned to the rule rather than generate a new IPsec policy. You can use the IP Security Policy Management MMC snap-in to configure a rule in an IPsec policy to use a new filter action. To change an existing rule filter action 1. Log on to a domain controller as a domain administrator. 2. Launch the IP Security Policy Management MMC snap-in and focus it on the domain. 3. In the right pane, right-click , and then click Properties. 4. In the IP Security Rules list, click , and then click Edit. 5. On the Filter Action tab, in the Filter Actions list, click to select the adjacent button. 6. Click OK, and then click OK again. 7. Close the IP Security Policy Management MMC snap-in.
Changing an Existing Rule Authentication Method The default authentication method in IPsec policies uses the Kerberos version 5 protocol. Over time it may become necessary to change an authentication method that is associated with an existing rule. For example, a public key infrastructure (PKI) could be rolled out so that certificates can be used to authenticate computers. Although different information is needed for each authentication method that can be chosen, the general steps for adding an authentication method are similar. For example, to use a preshared key you must identify the key, and to use certificates the certificate authority (CA) must be known. To add a new authentication option to an existing IPsec rule, complete the following steps. To add an option to an existing rule 1. Log on to a domain controller as a domain administrator. 2. Launch the IP Security Policy Management MMC snap-in and focus it on the domain. 3. In the right pane, right-click , and then click Properties. 4. In the IP Security Rules list, click , and then click Edit. 5. On the Authentication Methods tab, click Add. 6. Click the button next to the new authentication option that is being chosen and then configure any options that are required.
Chapter 6: Managing a Server and Domain Isolation Environment
141
7. Click OK. 8. In the Authentication method preference order list, use the Move up and Move down buttons to create the preferred order of the authentication methods. Note To remove an authentication method, click it in the Authentication method preference order list, and then click Remove.
9. Click OK, and then click OK again. 10. Close the IP Security Policy Management MMC snap-in.
Adding a New Rule to an Existing IPsec Policy New rules are added to IPsec policies that already exist to further restrict or allow communication to occur between computers in the environment. For example, if an IPsec-capable system needs to communicate with systems in a particular isolation group but does not get its policy from the IPsec infrastructure, you can make changes to the isolation group policy to allow the communication. In this example, the non-managed IPsec host would need to have a policy applied to it that allows the communication to occur. Furthermore, a shared authentication method must be decided upon; either certificates or a preshared key could be used. A new rule could be created in the existing IPsec policy for the isolation group to allow the traffic to occur after the appropriate authentication method was agreed upon. The necessary steps would be to create a new filter list in the directory, associate the new filter list with the existing policy, and then configure the authentication mechanism to include the new authentication method that is chosen. To create a new filter list to allow all traffic to occur to a specific computer 1. Log on to a domain controller as a domain administrator. 2. Launch the IP Security Policy Management MMC snap-in and focus it on the domain. 3. Right-click IP Security Policies on Active Directory, and then click Manage IP filter lists and filter actions. 4. On the Manage IP Filter Lists tab, click Add. 5. In the Name text box, type an appropriate filter list name. 6. In the Description text box, type an appropriate description for the filter list. 7. Ensure that the Use Add Wizard check box is cleared. 8. In the IP Filter List dialog box, click Add. 9. In the Source address drop-down box, click Any IP Address. 10. In the Destination address drop-down box, click A specific IP Address. 11. In the IP address text box, type the IP address of the specific computer. 12. Ensure that the Mirrored check box is selected. Note By default, this procedure creates a rule that matches any traffic from any IP address to a specific IP address. If matching needs to be done on a specific port or protocol basis, additional configuration must be done on the Protocol tab.
13. On the Description tab, type an appropriate description for the filter item. 14. Click OK, and then click OK again.
142
Server and Domain Isolation Using IPsec and Group Policy
To modify an IPsec policy to use a new filter list and filter action 1. Right-click and then click Properties. 2. Ensure that the Use Add Wizard check box is cleared. 3. Click Add. 4. On the IP Filter List tab, in the IP Filter list, click the New Filter List option button. 5. On the Filter Action tab, in the Filter Actions list, click the Filter Action option button. 6. On the Authentication Methods tab, click Add. 7. Click the button next to the authentication method that is being chosen and configure any options that are required. Note The authentication method that is chosen must be one that both the initiator and responder can negotiate, such as a preshared key or certificates. If necessary, remove the Kerberos protocol from the list by selecting it and then clicking the Remove button.
8. Click OK. 9. In the Authentication method preference order list, use the Move up and Move down buttons to select the preferred order of the authentication methods if more than one authentication method is listed. 10. Click OK, and then click OK again. 11. Close the IP Security Policy Management MMC snap-in.
Moving Hosts Between Isolation Groups For various reasons, hosts will periodically need to be moved from one group to another. It is important to understand the implications of changes to group membership in terms of traffic communications. The following sections describe the steps for adding or removing hosts from groups.
Adding or Removing a Host in the Exemption List You can add a host to or remove a host from the Exemption List by modifying the IPsec exemption filter lists and the No IPsec security group. To do so, follow the steps in the "Changing an Existing Rule Filter List" section earlier in this chapter. The exemption filter list, the host's name, and its IP address must be known to complete this task.
Adding or Removing Hosts and Users in Existing Groups When you add a host to or remove a host from a network access group (NAG), the steps are specific to the role the host plays in the group. If the host acts only as an initiator, it is sufficient to either add or remove it from the associated NAG. However, if the host acts as a responder, the policy that controls the update of the "Access this computer from the network" right must either be applied or removed. If the system acts as both an initiator and responder, both steps must be taken.
Chapter 6: Managing a Server and Domain Isolation Environment
143
Adding or Removing Initiators in an Existing Network Access Group You can add or remove an initiator in a network access group by using standard group management tools to modify the associated security group. To modify a NAG relative to a specific computer 1. Log on to a domain controller as a domain administrator, and then launch Active Directory Users and Computers. 2. Expand the domain, and then click Users. 3. In the right pane, right-click the and then click Properties. 4. To add a computer to the group: a. Click the Members tab, and then click Add. b. Click the Object Types button, select the Computers check box, and then click OK. c.
In the Enter the object names to select text box, type and then click OK.
d. Click OK. 5. To remove a computer from the group: a. Click the Members tab. b. In the Members list, click and then click Remove. c.
Click Yes to remove the account.
d. Click OK. Note There will be a delay between the time the host account is added to the group and when the host can access the restricted resource. This delay is caused by replication delays and the time between updates of the session ticket on the server that is hosting the restricted resource (if the ticket is cached).
Adding or Removing Users in an Existing Network Access Group Although isolation groups were created to restrict which hosts can initiate communication to the restricted resource, they can also be used to help restrict which users have access to a resource. If there is no requirement to restrict a resource in a manner that is similar to a NAG, then the Domain Users group is granted the "Access this computer from the network" right on the responders. If there is a requirement to restrict a resource, then a NAG Users group is created. You can add or remove a restricted user from a NAG Users group by using standard group management tools to modify the associated security group. This procedure is only required if a NAG Users group has been created and assigned to the NAG; if the Domain Users group is being used, then this procedure is not necessary. To modify a NAG Users group relative to a specific user 1. Log on to a domain controller as a domain administrator, and then launch Active Directory Users and Computers. 2. Expand the domain, and then click Users.
144
Server and Domain Isolation Using IPsec and Group Policy
3. In the right pane, right-click the NAG Users security group, and then click Properties. 4. To add a user to the NAG: a. Click the Members tab, and then click Add. b. In the Enter the object names to select text box, type and then click OK. c.
Click OK.
5. To remove a user from the NAG: a. Click the Members tab. b. In the Members list, click the specific , and then click Remove. c.
Click Yes to remove the account.
d. Click OK. Note There will be a delay between the time the user account is added to the group and when the user can access the restricted resource. This delay is caused by replication delays and the time between updates of the session ticket on the server that is hosting the restricted resource (if the ticket is cached).
Adding or Removing Responders in an Existing Network Access Group To remove a responding host (the responder) from an existing NAG, you can remove the GPO assignment that configures the "Access this computer from the network" right on the responder. The GPO application can be controlled through any of the standard means of ensuring policy application with Active Directory. However, the approach used in this guide assigned the GPO to an organizational unit (OU) that was created to hold the domain computer accounts of responders. Simply moving the computer account out of the responders OU will cause it to no longer receive the assigned GPO, and access will no longer be restricted. The computer would revert to the Isolation Domain policy. (If the computer account was also a member of a domain local security group that consisted of network access groups, then it must also be removed from that group.) Care should be taken to ensure that hosts that are members of multiple NAGs are still able to communicate with other NAGs after they are removed from one of the NAGs.
Adding New Network Access Groups Creation of a new NAG is a fairly straightforward process. First, you must create a domain local group to control the access to the resource and a GPO to update the "Access this computer from the network" right on the hosts that act as servers in the NAG. Then you must apply that GPO to the servers, and identify the hosts that belong in the group. Only initiators need to be members of the NAG. In other words, if two servers are in the same isolation group and will never initiate communications to each other, they do not need to be added to the NAG for their isolation group. However if these two servers need to communicate, they will need to be added to the NAG like all other initiators. If a server acts as a responder within multiple NAGs, care must be taken to ensure that after the GPO is applied, all NAG security groups in which the server participates are present on that system's "Access this computer from the network" right. If necessary, additional GPOs may be required so that specific computers meet this need.
Chapter 6: Managing a Server and Domain Isolation Environment
145
Creating a New Network Access Group for Initiator Computers Complete the following steps to create a new NAG. To create a new NAG for initiator computers 1. Log on to a domain controller as a domain administrator and then launch Active Directory Users and Computers. 2. Right-click the Users container, click New, and then click Group. 3. In the Group name text box, type an appropriate name for the group. 4. Click the Domain local security group and then click OK. 5. Right-click the newly created group and then click Properties. 6. In the Description text box, type an appropriate description for the group. 7. Click OK.
Adding Initiator Computer Accounts to a Network Access Group Complete the following steps to populate a new NAG with initiator accounts. To populate the new NAG for initiators with the initiator accounts 1. Log on to a domain controller as a domain administrator and then launch Active Directory Users and Computers. 2. Expand the domain, and then click Users. 3. In the right pane, right-click the NAG initiators group, and then click Properties. 4. Click the Members tab, and then click Add. 5. Click the Object Types button, select the Computers check box, and then click OK. 6. In the Enter the object names to select text box, type the and then click OK. 7. Click OK. If there is a requirement to further restrict which users in the domain are allowed to access the restricted resource, a group for the restricted NAG users must be created. Otherwise, the Domain Users group can be used instead.
Creating a New Network Access Group for Restricted Users Complete the following steps to create a NAG for restricted users. To create a new NAG for user accounts 1. Log on to a domain controller as a domain administrator and then launch Active Directory Users and Computers. 2. Right-click the Users container, click New, and then click Group. 3. In the Group name text box, type an appropriate name for the group. 4. Click the Domain local security group and then click OK. 5. Right-click the newly created group and then click Properties.
146
Server and Domain Isolation Using IPsec and Group Policy
6. In the Description text box, type an appropriate description for the group. 7. Click OK.
Adding Restricted User Accounts to a Network Access Group Complete the following steps to populate a new NAG with restricted users. To populate the new NAG with user accounts 1. Log on to a domain controller as a domain administrator and then launch Active Directory Users and Computers. 2. Expand the domain, and then click Users. 3. In the right pane, right-click the NAG Users group, and then click Properties. 4. Click the Members tab, and then click Add. 5. In the Enter the object names to select text box, type and then click OK. 6. Click OK.
Creating a GPO to Grant the "Access This Computer from the Network" Right A GPO is used to assign the "Access this computer from the network" right to the appropriate NAGs. The following table provides an example of a GPO implementing a NAG and the associated group names that need to be granted the "Access this computer from the network" right. Table 6.1 Example NAG Policy Definition GPO name
Group name
Administrators Backup Operators NAG Users or Domain Users Note The listed groups are the minimum that should be added. The administrator will need to determine whether there are any additional groups that should be granted this right. The Domain Users group is added as a default. If the administrator also wishes to restrict users as well as computers, a NAG Users group will need to be created like the one for computer accounts that contains the selected user accounts.
To create a GPO to grant the Access this computer from the network right 1. Log on to a domain controller as a domain administrator. 2. Launch the GPMC. 3. Expand Forest: , expand Domains, and then expand .
Chapter 6: Managing a Server and Domain Isolation Environment
147
4. Right-click Group Policy Objects, and then click New. 5. In the Name text box, type and then click OK. 6. Right-click , and then click Edit. 7. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click User Rights Assignment. 8. In the right pane, right-click Access this computer from the network, and then click Properties. 9. Select the Define these policy settings check box. 10. Click the Add User or Group button. 11. Click the Browse button. 12. In the Enter the object names to select text box, type the name of each group listed in the previous table, separated by semicolons. Then click OK. 13. Click OK. 14. Close the GPO editor and then the GPMC.
Deploying Network Access Group GPOs To deploy NAG GPOs, they first need to be linked to a location within the domain environment so that they can be applied to the appropriate responders within the NAG. The GPO application can be controlled through any of the standard methods for ensuring policy application with Active Directory. It is beyond the scope of this guidance to provide specific steps, because they would be dependent on the OU structure and management methods employed within the organization.
Disabling IPsec in an Isolation Group You can disable an IPsec policy by modifying the GPO that delivers the policy. To disable the IPsec policy, the GPO is configured so that the computer settings are disabled. To disable the computer settings of the GPO 1. Log on to a domain controller as a domain administrator. 2. Launch the GPMC. 3. Expand Forest: , expand Domains, expand , and then expand Group Policy Objects. 4. Right-click , click GPO Status, and then click Computer Configuration Settings Disabled. 5. Close the GPMC.
Re-Enabling IPsec in an Isolation Group You can re-enable IPsec policies that have been disabled by modifying the GPO that delivers the policy. To re-enable a disabled IPsec policy, the GPO is configured so that the computer settings are enabled. To enable the computer settings of the GPO 1. Log on to a domain controller as a domain administrator. 2. Launch the GPMC.
148
Server and Domain Isolation Using IPsec and Group Policy
3. Expand Forest: , expand Domains, expand , and then expand Group Policy Objects. 4. Right-click , click GPO Status, and then click Enabled. 5. Close the GPMC.
Removing IPsec from an Isolation group You can remove an IPsec policy by modifying the GPO that delivers the policy. To remove the IPsec policy, the GPO is configured so that the IPsec policy is no longer assigned. To unassign the IPsec policy of the GPO 1. Log on to a domain controller as a domain administrator. 2. Launch the GPMC. 3. Expand the Forest: , expand Domains, and then expand . 4. Right-click , and then click Edit. 5. Expand Computer Configuration, expand Windows Settings, expand Security Settings, and then click IP Security Policies on Active Directory . 6. In the right pane, right-click , and then click Un-assign. 7. Ensure that is unassigned, and then close the GPO editor and then the GPMC.
Backup/Restore Considerations This section provides information about how to evaluate the processes that specifically deal with backup and restoration of the server and domain isolation solution components.
Active Directory Backup IPsec policies are not stored in the Group Policy objects that are used to deliver the policies. Group Policy backup and restore capabilities will only capture information about which IPsec policies are assigned to Group Policy objects, not the actual IPsec policy information. Although a full System State backup of a domain controller will capture the IPsec policy information, it is also possible to use the IP Security Policy Management MMC snap-in's Export Policies and Import Policies menu commands to back up and restore IPsec policies. Note It is important to secure your IPsec policy backups. However, the backup is a file that inherits the NTFS file system permissions of the directory in which it is stored, and the data in the file is not encrypted or signed. You should protect the IPsec configuration information in these files by using appropriate permissions or security procedures. Only authorized IPsec administrators should have access to these backup files.
For more information about backing up System State data on a computer running Windows Server 2003, see the Back up System State data page.
Chapter 6: Managing a Server and Domain Isolation Environment
149
Host Restoration On computers for which IPsec policy has been restored from backup (either a tape backup or an image-based backup), the IPsec policy that is applied might be a cached copy of the Active Directory-based IPsec policy or a local IPsec policy. If the computer is assigned Active Directory-based IPsec policy, the IPsec service attempts to retrieve the latest copy of the assigned IPsec policy from Active Directory before it applies the cached copy of the Active Directory-based policy. When doing so, the IPsec service first queries Domain Name System (DNS) for the current list of the IP addresses of all of the domain controllers. If the IPsec policy objects have been deleted from Active Directory, the cached copy of the Active Directory-based policy is applied instead. The list of domain controller IP addresses in the cached copy of the Active Directorybased IPsec policy might have changed substantially since the IPsec policy backup was created (for example, if new domain controllers were added). If so, communication might be blocked with current domain controllers—and therefore authentication that used the Kerberos protocol will fail when attempts are made to establish IPsec-secured connections remotely. In addition, the computer might not be able to receive Group Policy updates. This problem can be resolved as follows: 1. Access the computer locally, and stop the IPsec service on that computer. 2. Restart the computer in Safe Mode with Networking, and either configure the IPsec service to start manually or disable the IPsec service to allow IPsec-secured communication with the IP addresses of the new domain controllers.
Mitigation of Network-Based Infections Some circumstances may require rapid disruption of communications to ensure the security of the environment, such as when a virus outbreak or security intrusion occurs. The following sections discuss various ways to isolate hosts that participate in authenticated communications. By design, these methods do not isolate the infrastructure or exempted servers, because care must be taken not to isolate the infrastructure servers so that the systems do not lose the ability to update their IPsec policies from the domain. Note Although these methods of isolation are technically sound, they have not been tested in a lab environment. It is strongly suggested that you test these methods in a lab environment before relying on them.
Isolating the Isolation Domain Hosts in the isolation domain are allowed to initiate communications with untrusted hosts. If there is a need to quickly block this type of traffic, the IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) filter action can be modified so that the "Allow unsecured communication with non-IPsec-aware computers" right is disabled. After the IPsec polling period has elapsed, all hosts in the isolation domain should be blocked from communicating with systems that are not participating in the IPsec environment. To modify the IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) filter action 1. Log on to a domain controller as a domain administrator. 2. Launch the IP Security Policy Management MMC snap-in and focus it on the domain. 3. Right-click IP Security Policies on Active Directory, and then click Manage IP filter lists and filter actions.
150
Server and Domain Isolation Using IPsec and Group Policy
4. On the Manage IP Filter Actions tab, click the IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) filter action, and then click Edit. 5. Select or clear the Allow unsecured communication with non-IPsec-aware clients check box. 6. Click OK. 7. Click OK. After this option has been set, the policy will block all network traffic that is destined for untrusted hosts. After the issue has been resolved, the communication can be restored by re-enabling the option.
Blocking Ports IPsec policies that are deployed to internal organizational local area network (LAN) computers are configured to allow all communication across all ports. This approach simplifies the configuration and management of the environment. However, if a host using IPsec becomes infected with malware such as a virus or worm, the host will likely spread the infection to other computers. Depending on the policies the computer is using, the infection could spread to both trusted and untrusted hosts. IPsec policies can be used to help reduce the spread of malware by explicitly blocking the ports that malware uses. The main limitation to this approach is the delay required for all computers to detect the policy change that adds the blocking filters. In addition, some worms have flooded the network and made it difficult for IPsec policy changes to be retrieved. And some worms have used ports that are also used by critical services such as DNS, which would make it difficult to update the policy after blocking filters were applied on the host. Blocking can be accomplished by creating a rule that blocks traffic from any IP address to the specific port that a certain form of malware uses. This rule is added to all policies in the environment. After the malware is removed, the rule can be removed from the policies. After you identify the ports and protocols that a certain form of malware uses, create a filter list that matches the criteria of the malware communication by following the steps in the "Adding a new rule to an existing IPsec policy" procedure in the "Changing IPsec Policy" section earlier in this chapter. The IPsec policy polling interval should be reduced right away as soon as the decision is made to use port blocking in domain policy. The polling interval can be increased again once the threat has subsided. However, instead of creating a filter that uses any IP address to a specific IP address, create a filter that uses "My IP Address" to any IP address. Typically, mirrored filters are not used. A filter list that contains two one-way filters is required, one for inbound to a well known port and one for outbound traffic to a well known port. For example, the following filters block the SQL port 1433 exploited by the SQLSlammer worm: From Any IP Address -> My IP address, TCP, src *, dst 1433, not mirrored From My IP Address -> Any IP address, TCP, src *, dst 1433, not mirrored Clearly, these filters will also block the SQL application connections and would be removed when the worm threat had subsided. Use caution not to block access to critical infrastructure ports such as DNS unless absolutely necessary. These filters are more specific than the Woodgrove Bank subnet filters that negotiate IPsec for all traffic on the internal network because they have a specific IP address defined. After the filter is created, add a rule to all isolation domain and group IPsec policies to associate the filter list with the IPsec – Block filter action. You may want to include in your policy design a rule that already associates an empty IPsec Filter List used for blocked ports with the block action. This empty filter list could be used by rules in all IPsec
Chapter 6: Managing a Server and Domain Isolation Environment
151
policies and enabled so that all domain members will check this filter list on each polling interval. Or the rule could be disabled, and the IPsec service polling would detect when the rule is enabled in each isolation group policy. If for some reason the port blocking prevents IPsec from accessing Active Directory to obtain an updated policy, then the IPsec service can be administratively stopped and restarted on the computer, or the computer can be restarted. When the IPsec service starts, it will attempt to download the latest version of the assigned IPsec policy before applying the older version in the cache.
Isolation to Within Child Domain Only If an entire domain needs to be isolated from the rest of the domains in the forest, the policy for that domain can be configured to use a preshared key rather than the Kerberos protocol. This approach will allow computers within the child domain to maintain communications with other systems in the same domain, but it will block communication with systems outside of the domain to which they usually would have access. Each policy in the child domain would need to be modified so that it used only a preshared key for the IPsec – Secure Organization Subnets rule. Any existing authentication methods, such as the Kerberos protocol, will need to be removed. To configure the authentication methods, follow the steps in the "Changing an Existing Rule Authentication Method" section earlier in this chapter. If additional rules that perform authentication exist in the policy, they will also need to be configured to use a preshared key. All policies in the child domain that is to be isolated will need to be configured in this way. To minimize the chance of IKE main mode authentication failures as the policy is rolled out, the preshared key authentication method can be ordered first in the authentication method list, followed by the Kerberos method. After all computers have the updated policy, the Kerberos authentication method can be removed. A similar process is used to restore authentication for the Kerberos protocol and remove the preshared key after the threat has subsided.
Isolation to Predefined Groups Although network access groups are one implementation that can be used to isolate a predefined group of computers, preshared keys or certificates can also be used to perform the same isolation. The primary difference from network access groups is that you will need to create separate policies for each group of computers to secure the traffic between the computers that have a preshared key or certificate. This solution requires additional traffic communication planning, particularly if a system belongs to more than one group. The major drawback to preshared keys is that they are stored in plaintext in the policy and thus are easily discovered (their secrecy is compromised) from a client within the domain. This drawback may not be a concern if the preshared key value is being used simply for temporary isolation during a worm outbreak. Because of a limitation in how IKE checks certificate constraints at the root CA rather than at the issuing CA, a unique root CA would need to be deployed for each group.
152
Server and Domain Isolation Using IPsec and Group Policy
Summary This chapter provided information, processes, and procedures for managing, maintaining, and modifying a server and domain isolation solution after it has been successfully deployed and made operational. The processes and procedures should be well documented and communicated to all staff who are involved in the day-to-day management of the hosts in the environment. Because there is always the potential for a small change to an IPsec policy to disable a protected communications path, these processes and procedures should be designed to help ensure that no errors are introduced as a result of someone not understanding the ramifications of a policy change.
Chapter 7: Troubleshooting IPsec This chapter provides information about how to troubleshoot Internet Protocol security (IPsec), such as in server and domain isolation scenarios, and is based on the experience and processes of the Microsoft Information Technology (IT) team. Where possible, this chapter refers to existing Microsoft troubleshooting procedures and related information. Microsoft IT support is based on a multi-tiered support model, and the help desk is referred to as Tier 1 support. Escalation procedures enable the help desk staff to escalate incidents that require the assistance of specialists. The procedures in this chapter refer to three levels of support: Tier 1, Tier 2, and Tier 3. To ensure that the guidance is as practical and concise as possible, most of the content is at the Tier 2 level. Initial Tier 1 guidance is provided to help an organization determine as quickly as possible if a problem is related to IPsec and, if it is, to generate the required information to help Tier 2 support engineers troubleshoot the problem. The highly detailed and complex information that would be required to support Tier 3 troubleshooting efforts is outside the scope of this chapter. If the information provided in this chapter does not fix the IPsec problem, Microsoft recommends that you contact Microsoft® Product Support Services to obtain additional assistance. Many of the support procedures, tools, and scripts that are used by Microsoft are provided in this chapter for reference purposes. These recommendations and tools should be adapted to meet the specific needs of your organization. When IPsec is used to secure Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) traffic on the network, typical TCP/IP network troubleshooting procedures and tools can become ineffective. For this reason, it is important to plan for and develop IPsec-specific troubleshooting techniques that can be used if an issue arises between computers that use (or attempt to use) IPsec for their communications.
Support Tiers and Escalation Within Microsoft, server and domain isolation support is a standard offering and is defined in standard service level agreements (SLA). Isolation support is provided by the following tiers: •
Tier 1: Help desk. The help desk is the entry point for both domain-joined and nondomain-joined client issues. The help desk also supports servers that are managed by the central IT organization. (Other servers may be managed by line of business application teams or product groups.) Help desk staff members are trained to use a taxonomy and several flowcharts for classifying problems that relate to server and domain isolation. During the pilot phase of the Microsoft isolation solution, client issues were escalated to the Corporate IT Security department. However, after the solution was deployed into production, client issues were handled by the Tier 2 support teams.
•
Tier 2: Data center operations, global network operations center, line of business application support, and messaging/collaboration support. These groups are the day-to-day operations teams that monitor and manage IT services and related assets. During server and domain isolation pilots, these teams were the initial escalation point for help desk and Corporate IT Security for server-related issues and troubleshooting. Each group has a subject matter expert for server and domain isolation, as well as detailed procedures for troubleshooting.
•
Tier 3: Windows network and infrastructure services. For server and domain isolation pilots, this group identified a team of people to be experts in troubleshooting the solution-related architectural components and technologies, such as IPsec, TCP/IP packet processing, computer accounts, and network logon rights. Within Microsoft, if further escalation is necessary, Tier 3 works directly with the Windows Development teams until closure is reached. Outside of Microsoft, this level would engage with Microsoft Product Support Services when necessary.
The following section summarizes the troubleshooting techniques that can be used by the help desk staff in the Tier 1 support organization.
Tier 1 Troubleshooting This section presents the overall process for troubleshooting IPsec-related problems that is used by help desk staff, who provide Tier 1 support. Typically, Tier 1 support personnel are phone-based help desk staff members who attempt to diagnose problems remotely.
Is IPsec the Problem? The help desk is likely to receive calls such as “I was able to connect to server x until IPsec was turned on" or "Everything worked yesterday, today I can’t connect to anything!" In the experience of Microsoft IT, the rollout of IPsec increased call volumes for all types of network connectivity issues and "access denied" incidents because people were paying increased attention to application and network behaviors. If someone thought it might be related to IPsec, they called the help desk. A server and domain isolation implementation plan should include a call classification system so that help desk personnel can provide clear reports about the volume and nature of IPsec-related problems. After appropriate administrative information is obtained from the caller, help desk staff should follow a defined troubleshooting process. Because IPsec policy designs may vary in their impact on communications, and because the rollout process may take several days or weeks, a flowchart should be defined and updated for each set of isolation changes being implemented. Help desk management personnel must be involved in this planning process. The goal of the help desk should be to categorize the problem so that known solutions can be attempted. If these attempts do not resolve the problem, then help desk personnel can ensure the proper information is collected and escalate the problem to Tier 2 support. For example, the help desk should be able to identify various types of problems in the following ways: •
Network connectivity. Use ping and tracert Internet Control Message Protocol (ICMP) messages to test network paths.
•
Name resolution. Use ping and nslookup.
•
Applications. Some applications work (for example, net view), but others do not when communicating with the same destination.
Chapter 7: Troubleshooting IPsec
155
•
Services. For example, determine whether the server is running the Routing and Remote Access (RRAS) service, which creates a conflicting automatic IPsec policy for L2TP.
•
The caller’s computer. Determine whether it can access any host or specific trusted host destination computers that are used for help desk testing and diagnosis.
•
The target computer. Determine whether the caller's computer can access all help desk computers that are used for testing but cannot access a certain destination computer.
Depending on the organization, the help desk may use Remote Assistance or Remote Desktop to connect to the caller's computer. The guidelines provided in this chapter do not require remote access, although they may be useful tools for help desk personnel to use as an alternative to guiding the caller through the IPsec Monitor Microsoft Management Console (MMC) snap-in or the Event Log viewer. In scenarios where server isolation is used without domain isolation, help desk personnel should be aware of which servers are members of the isolation group.
Assign Scope and Severity One of the first questions that Tier 1 support must address is: who is affected by the problem? Support personnel need to understand if the problem is shared by other users and, if so, how many and where they are. The support staff must then look at the extent of the problem. For example, does it affect connectivity to a single server, or are there more extensive problems such as logon or authentication failures across large parts of the network? Problems with connectivity can involve many different layers and technologies that are used in network communications. Support engineers should be aware of how Windows TCP/IP network communications work in general, as well as specific issues related to the solution. This section reviews the different types of problems and common issues for each that Tier 1 support must handle. •
Computer-specific problems. IPsec-protected communications require mutual Internet Key Exchange (IKE) computer authentication. Computers that initiate communications and computers that respond to communications must have valid domain accounts and access to domain controllers for their domain. Furthermore, IPsec policy assignment and network access controls depend upon computer accounts being in the correct domain groups. Other computer-specific issues that may affect IPsec behavior include the following: •
The operating system does not have the correct service pack, patch or registry key configuration.
•
The computer has certain software installed or particular services running.
•
The network connection is using a specific IP address or communicating using a particular network path.
Because of these types of issues, some computers may experience problems with connectivity and others not. Note All of the IPsec troubleshooting tools discussed in this chapter require local administrator group privileges.
•
Network location and path-specific problems. In a server and domain isolation solution or other widespread deployment of IPsec, it is likely that all TCP and UDP traffic will be encapsulated. Therefore, network devices along the path will only see only IKE, IPsec and ICMP protocols. If there are any network problems in the transmission of these three protocols between the source and destination, then communication may be blocked between the two computers.
156
•
Server and Domain Isolation Using IPsec and Group Policy
User-specific problems. The deployment of IPsec, such as in a server and domain isolation scenario, can affect the network logon rights of domain users. For example, the problem may only affect users who are not in an authorized group for network access, or an authorized user may have problems obtaining Kerberos authentication credentials that contain the proper group memberships. There may be differences in behavior between domain and local user or service accounts.
Two other features of the server and domain isolation solution that are also typically found in enterprise deployments of IPsec are the use of subnet filters to define the address ranges used on the internal network, and the application of IPsec policies that are based on domain membership and group membership, regardless of where a computer is located on the internal network. Consequently, if there is a problem with the design of the subnet filters or the network path used by that computer to reach other computers, connectivity problems may appear in only certain parts of the network, when using a certain IP address (for example, a wireless address and not a LAN address), or only on certain computers.
Troubleshooting Flowcharts The call handling flowcharts in this section were developed by Microsoft IT to help classify Tier 1 IPsec support problems. In addition to standard tools, two of the flowcharts refer to an IPsec policy refresh script, a description of which is provided in the "Support Script Examples" section later in this chapter. Figure 7.1 is used for initial diagnosis and to determine the type of problem: •
Is it a network connectivity problem? If so, attempt basic network troubleshooting. If unsuccessful, escalate to Tier 2 support.
•
Is it a name resolution problem? If so, attempt basic name resolution troubleshooting. If unsuccessful, escalate to Tier 2 support.
•
Is it an application problem? If so, escalate to Tier 2 support.
•
Is it an IPsec problem with the caller's computer? If so, go to Figure 7.2.
•
Is it an IPsec problem with the target computer the caller is trying to reach? If so, go to Figure 7.3.
Chapter 7: Troubleshooting IPsec
157
Figure 7.1 Troubleshooting process for failure to communicate with a target computer Note This flowchart assumes the caller computer is running IPsec and that DNS reverse lookup zones are configured to allow the correct operation of the ping –a command.
Figure 7.2 is designed to help identify problems with the caller's own computer. Note that in addition to diagnostics, this flowchart references the use of an IPsec policy refresh script (see "Support Script Examples" later in this chapter), which may fix the problem without necessarily identifying it. The steps in Figure 7.2 help determine the following potential problems with the caller's computer: •
Is it an RRAS issue? If so, either stop the RRAS service (if RRAS is not required) or escalate the problem to Tier 2 support.
•
Is it a policy issue? If so, try to refresh the Group Policy and the IPsec policy.
•
Is it a domain account issue? If so, create a domain account for the caller's computer.
•
Is it none of the above? If IPsec policy refresh and/or creating a domain account do not solve the problem, escalate the issue to Tier 2 support.
158
Server and Domain Isolation Using IPsec and Group Policy
Figure 7.2 Troubleshooting caller computer IPsec-related problems Figure 7.3 is designed to help identify problems with a particular target computer. Note that this flowchart also references the use of an IPsec policy refresh script that may fix the problem without necessarily identifying it. Figure 7.3 helps determine the following potential problems with the target computer (or the path to it): •
Is it a RRAS issue? If so, escalate to Tier 2 support.
•
Is it an IPsec policy issue? If so, try to refresh the Group Policy and the IPsec policy. Then check network connectivity.
•
Is it a network connectivity issue? If so, escalate to Tier 2 support.
•
Is it a logon right issue? If so, escalate to Tier 2 support.
Chapter 7: Troubleshooting IPsec
159
Figure 7.3 Troubleshooting target computer IPsec-related problems After the Tier 1 support staff has worked through the flowcharts, the problem status will be one of the following: •
Fixed understood. This status means the problem has been resolved and the reason for the problem may have been determined.
•
Fixed unclear. This status means the issue is resolved the issue but the reason for the problem is not fully understood. For example, an IPsec policy refresh may solve the problem but does not necessarily explain why an incorrect policy, or no policy at all, came to be applied.
•
Not fixed. This status means the problem is still outstanding but with likely problem issues identified as the issue is escalated to Tier 2 support.
160
Server and Domain Isolation Using IPsec and Group Policy
Prevention of Social Engineering Attacks In an isolation solution, help desk personnel may become aware of specific areas within the IT environment that are not protected by IPsec, such as computers that are members of the exemption list. They may not be used to protecting sensitive information, because in other security solutions such critical information is usually only available to higher-level support teams. For this reason, help desk personnel should be trained in how to detect and resist social engineering attacks. In a social engineering attack, an untrusted person attempts to gain information about how security is implemented and where security is weak, often by simply taking advantage of the human tendency to trust other people. The following information should be carefully controlled by help desk personnel: •
Members of the exemption list. The list of IP addresses in the exemption list filters is likely available to local administrators on all trusted hosts by using the IPsec Monitor MMC snap-in, or by viewing the domain IPsec policy cache in the local registry. In addition, the security settings used in the organization may provide nonadministrative users with read access to the cache. After domain isolation is fully implemented, attackers must scan the network to detect exempted computers, which will be able to respond to TCP and UDP connection requests. Note that DNS servers, DHCP servers, and WINS servers are easily identified from the DHCP configuration, and domain controllers are easy to locate by using either a DNS query or a UDP Light Directory Access Protocol (LDAP) query.
•
Computers in the organization that are not participating in the isolation solution. For example, certain domains or server types may not be included in the solution.
•
Computers that do use server isolation or require machine-based access control. The servers that contain the most sensitive information usually have the most security protections in place.
•
Users who are administrators or have special roles in the IT organization. In some cases, e-mail addresses are used as computer names or part of the computer name, thereby revealing logon names or e-mail addresses.
•
Subnets that are being used for specific purposes or by certain organizations. If this information is known, an attacker can then focus their attack on the most sensitive and valuable parts of the network.
•
Other network-based security measures that are being used. For example, knowledge of whether firewalls exist, whether router filters permit certain traffic, or whether network intrusion detection is being used is very helpful for an attacker.
Help desk personnel should also be trained to be wary if a caller asks them to connect to their computer IP address to see what it wrong—for example, if an attacker asks someone at the help desk to connect to their computer using file sharing, Remote Desktop, Telnet, or other network protocol. If a help desk person makes the connection without IPsec, the attacker's computer can learn information about the password or (in some cases, such as with Telnet) steal the password. This situation can occur because some client network protocols do not first authenticate and establish a strong trust with the destination computer, or they do not require strong password protections before revealing user identity or password-related information.
Chapter 7: Troubleshooting IPsec
161
Support Script Examples For most troubleshooting scenarios, a solution can be quickly determined after the right information is identified. This information may be found using various Windows tools, such as those referenced in the flowcharts. In the Woodgrove Bank solution, a number of scripts were developed to provide key information without requiring Tier 1 support staff to have detailed knowledge of tool operations and syntax. These scripts are available in the Tools and Templates folder of the download for this guide.
Scripts Available for Tier 1 Support If the user is a local administrator of their computer, help desk personnel can have them run one of three scripts provided with this solution. These scripts are examples of the customized scripts used for the Woodgrove Bank environment that is detailed in this guide. They are described in this chapter to illustrate how scripts can be used to support the troubleshooting process. Note These scripts are tested examples but are not supported by Microsoft. They should be used as a basis for an organization's own customized solution.
IPsec_Debug.vbs In addition to providing debug information, this script may actually fix some problems. It stops and restarts the IPsec service (which deletes all current IKE and IPsec security associations), forces a Group Policy refresh to reload the current domain-assigned IPsec policy from the Active Directory® directory service, and updates the policy cache. To avoid loss of connectivity for remote desktop sessions, the script should be downloaded to the caller's computer and run locally by an account that has administrative privileges. Use the following syntax to run the script at a command prompt: cscript IPsec_Debug.vbs The script performs the following functions: •
Discovers the operating system version
•
Calls Detect_IPsec_Policy.vbs
•
Increases Group Policy logging
•
Increases Kerberos version 5 authentication protocol logging
•
Purges current Kerberos protocol tickets
•
Refreshes Group Policy
•
Enables IPsec logging
•
Performs PING and SMB (Net View) tests
•
Detects IPsec file versions
•
Runs policy and network diagnostic tests
•
Copies IPsec 547 events to a text file
•
Disables IPsec logging
•
Restores Kerberos protocol logging
•
Restores Group Policy logging
This script also enables all IPsec-related logs for troubleshooting by Tier 2 support.
162
Server and Domain Isolation Using IPsec and Group Policy
Detect_IPsec_Policy.vbs This script determines whether the computer is running the correct IPsec policy by checking the current local registry cache for policy version information for the domain IPsec policy. Use the following syntax to run the script at a command prompt: cscript Detect_IPsec_Policy.vbs Note This script is also called from IPsec_Debug.vbs, and therefore does not need to be run in addition to that script.
Refresh_IPsec_Policy.vbs This script is the IPsec policy refresh script referenced in the troubleshooting flowcharts. It refreshes computer Kerberos authentication protocol tickets and Group Policy, and may fix the problem if it is caused by an incorrect IPsec policy assignment or a Group Policy download failure. Use the following syntax to run the script at a command prompt: cscript Refresh_IPsec_Policy.vbs
Escalation When help desk personnel need to escalate a likely IPsec problem, the following information should be collected by Tier 1 and passed with the service request: •
Log files generated with IPsec_Debug.vbs script.
•
The caller's machine name so that the next support tier can identify the log file generated by the script.
•
The destination computer to which access is denied, so that escalation can be directed to the proper support group.
Server isolation scenarios often have their own support team to investigate membership of network access groups.
Tier 2 Troubleshooting Preparation Tier 2 support has two main roles. First, as the recipient of all Tier 1 escalations, Tier 2 validates issues and reviews the steps taken by Tier 1 to ensure that no troubleshooting steps were missed. In this respect, Tier 2 should confirm that any escalated issue is really due to IPsec, and not a misdiagnosis. Second, as skilled network support engineers, Tier 2 support staff members should be able to use their skills and experience (listed in the following section) to successfully resolve the problem through log analysis without gaining administrative control of the computer. However, logs only capture information, and corrective actions require administrative access. It is not expected that a Tier 2 support person should be a domain administrator or be able to make changes in domain-based IPsec policy or computer group memberships.
Chapter 7: Troubleshooting IPsec
163
Tier 2 Support Skills Support staff that provide Tier 2 IPsec support should have skills and expertise in the following areas: •
Group Policy. Know what policies should be assigned, how they are assigned, and be able to perform the following tasks: •
Check access control lists (ACL) on Group Policy objects (GPO).
•
Check GPO settings.
•
Check group memberships for computers and users.
•
Experience with third-party software used by the organization.
•
Authentication failure identification. •
•
•
Be able to verify that a domain computer account is OK by using the netdiag and nltest utilities.
IPsec configuration. Be able to perform the following tasks: •
Verify IPsec filter configurations.
•
Reload IPsec domain policy.
•
Disable IPsec entirely, or just the domain policy to use local policy for testing.
•
Troubleshoot the IPsec IKE negotiation process and security protocols.
Networking. Be able to perform the following tasks: •
Troubleshoot the network protocol stack on a host machine.
•
Understand and troubleshoot the information that is gathered in a network trace.
•
Troubleshoot network path problems, including TCP Path MTU discovery and virtual private network (VPN) remote access solutions.
Issues Inherent with the Use of IPsec As indicated in the previous section, Tier 2 support personnel for a server and domain isolation solution will need to know the details of IPsec-protected communications, but they also must be able to isolate problems related to other technology components. For successful IPsec communication between two computers, both computers usually require a compatible IPsec policy. For example, an IPsec policy may block communication if the remote computer does not have an appropriate IPsec policy. Although this may be an intended or acceptable behavior during the rollout of a policy change, it may not be immediately apparent whether it blocks network connectivity with one or more computers and causes any application warnings or errors. In a worst case scenario, an administrator might accidentally assign an IPsec policy to all domain members that blocks all traffic. Unless the mistake is realized immediately, with a correct assignment that quickly replicates after the original assignment, replication of the damaging policy is not easily stopped. This type of mistake results in a situation in which communications between a client and a domain controller would be required to use IPsec. Because the authentication used in this solution relies on the Kerberos protocol, any client that inherits this policy would not be able to complete the logon process— because they would be unable to obtain the required Kerberos ticket to secure the communications. Administrators must carefully plan any policy changes and ensure that procedural safeguards exist to mitigate this type of situation.
164
Server and Domain Isolation Using IPsec and Group Policy
Background information on troubleshooting TCP/IP is provided in the troubleshooting guides listed in the "More Information" section at the end of this chapter. However, many of the procedures referred to in these guides will only work while IPsec is providing successful connectivity. If IKE or IPsec is failing, then most of these procedures and tools will probably become ineffective. In a server and domain isolation scenario, some of the procedures documented in the background guides may not work at all, even if IPsec is providing successful connectivity. A support organization should expect to update and customize troubleshooting tools and procedures to remain effective within a server and domain isolation environment. Because there are many different ways that IPsec policies can be deployed to control and help secure traffic, it is unlikely that organizations will be able to rely solely on existing procedures and a generic toolkit. It is important for support personnel to have documented examples of the expected output of network troubleshooting tools that are obtained from a lab environment where server and domain isolation or some other IPsec deployment is functioning correctly. In many cases, network diagnostic tools do not expect three-second delays for Fall back to clear, or the small delays required for IKE initial negotiation of IPsec security associations (SA). Therefore, the tools may display one result when run initially but a different result when run a few seconds later. Furthermore, where network access is deliberately denied by IPsec, the tools will report failures. The type of failure will depend on the tool and the IPsec environment. Note In the Tier 1 section the terms caller and target were used to help the support staff troubleshoot common problems. In the Tier 2 section it is preferable to use the IPsec terms initiator and responder to help make the more advanced troubleshooting processes clearer. The remainder of this chapter uses these IPsec terms.
Group Policy and Group Memberships Domain-based IPsec policy depends upon Group Policy and the download of GPOs. If the client Group Policy system experiences errors in detecting GPO changes or in downloading them, then IPsec connectivity may be affected. If Group Policy assignment is controlled by organizational unit (OU) membership and computer accounts are inadvertently moved to a different OU, deleted, or recreated in the wrong OU, then an inappropriate IPsec policy may become assigned. This solution uses domain security groups to control policy assignment and to control network access. Group membership is contained within Kerberos version 5 authentication protocol tickets (both TGT and service tickets) that have fairly long lifetimes. Therefore, administrators must plan for the time required for computers to receive new Kerberos TGT and service ticket credentials that contain group membership updates. The Kerberos protocol makes it extremely difficult to determine if the Kerberos tickets for a computer contain the proper group memberships. This difficulty is "by design," as all the information about group membership is stored in an encrypted form within the ticket. Group membership must be determined by using the information within the directory service, not from the tickets themselves.
Kerberos Authentication The server and domain isolation design uses the Kerberos version 5 protocol for IKE authentication. Because the Kerberos protocol requires successful network connectivity and available service from DNS and domain controllers, lack of connectivity will cause Kerberos authentication and IKE to fail. (IKE will also fail if Kerberos itself fails.), Therefore, connectivity problems between computer A and computer B may be caused by blocked network connectivity between computer A and computer C, which are caused by the inability of the Kerberos protocol to authenticate with a domain controller. In situations like this, the information provided in the 547 events in the Windows audit and security logs generally provides invaluable guidance on the source of the problem.
Chapter 7: Troubleshooting IPsec
165
IPsec-Protected Inbound Traffic Required This server and domain isolation solution specifies that IPsec-protected communication is required for inbound access. This requirement will cause remote monitoring tools that run on untrusted computers or dedicated network monitoring devices to report that a remote computer is not contactable. If these computers or devices are not able to join the "trusted" environment, they will not be able to perform the monitoring role unless some specific exemptions are added to the design. Troubleshooting is complicated by the fact that IPsec may be required to establish connectivity to a trusted host, which means that an administrator may not be able to connect to a trusted host and then stop the IPsec service without losing connectivity. If the administrator's IPsec policy allows Fall back to clear, then the remote connection will experience a three or four second delay after the service is stopped on the remote computer. However, stopping the IPsec service on a remote computer will delete the IPsec SAs that are in use by all other currently connected computers. If these other computers are not able to Fall back to clear, then communications will stop and TCP connections will eventually time out. Because sudden breaks in TCP communications can cause data corruption in applications, stopping the IPsec service should be used only as a last option in the troubleshooting process. Before IPsec service is stopped, the computer should be prepared to be shut down so that all connected users and applications can properly terminate communications.
Communication Direction Issues One common troubleshooting scenario is successful communication in one direction but failed communication in the reverse direction. IKE authentication typically requires mutual authentication between computers. If one computer can not obtain a Kerberos ticket when it initiates IKE main mode for a remote computer, then IKE will fail. This situation could happen if the Kerberos client from the initiating computer could not access a domain controller in the domain of the destination computer. If computers are members of domains that are not mutually trusted (two-way trust), then IKE main mode negotiations will succeed when one computer initiates and fail if the other computer initiates. Similarly, inbound network logon rights may differ on two computers. It is possible for IKE main mode and quick mode negotiation to fail in one direction not only for these reasons, but also if the IPsec policy designs are not compatible on both sides. Host-based firewalls that intercept traffic above the IPsec layer can enforce directionality on connections. Some host-based firewalls intercept traffic below IPsec layer. After successful IPsec communication is established, IPsec-protected traffic is likely to be allowed in both directions for a period of time. Stateful filtering by a network router or firewall can also block IKE rekey actions or IPsec traffic flow without affecting other diagnostic protocols such as ICMP. TCP and UDP ports may not be accessible on one computer because a service is not running, or because a device that works above the IPsec layer (such as Windows Firewall or a network router) is blocking access.
Network Traces and Advanced Network Path Troubleshooting Failures in IKE negotiation often cause the computer that experiences the failure to stop responding to the IKE negotiation, or in some cases to resend the last "good" message until the retry limit expires. IKE must be able to send fragmented UDP datagrams that contain the Kerberos tickets, because such packets often exceed the path maximum transmission unit (PMTU) for the destination IP address. If fragmentation is not properly supported, such fragments may be dropped by network devices along a certain path. In addition, the network may not pass IPsec protocol packets or fragments of IPsec packets
166
Server and Domain Isolation Using IPsec and Group Policy
correctly. IPsec integration with TCP enables TCP to reduce the packet size to accommodate the overhead of IPsec headers. However, the TCP negotiation of the maximum segment size (MSS) during the TCP handshake does not take into account IPsec overhead. Consequently, there is an increased requirement for ICMP PMTU discovery in the network to ensure successful IPsec-protected TCP communication. Therefore, troubleshooting connectivity failures may require network traces of one or both sides of the communication, as well as logs from both sides of the communication. Technical support engineers should understand how to read network traces, and also understand the IKE negotiation. Servers should have the Windows Network Monitor software installed. Windows 2000 Network Monitor provides parsing of IPsec AH and IKE. Windows Server 2003 adds support for parsing IPsec ESP-null, parsing ESP when encryption is offloaded, and parsing UDP-ESP encapsulation used for NAT traversal. When troubleshooting IPsec and taking network traces between hosts, it is considered best practice to lower the ESP encryption level (if it’s currently at DES/3DES) to ESP-null. This will help in reading and understanding the network trace much better than going through the encrypted traffic capture.
The Troubleshooting Toolkit Before starting troubleshooting, it is important to identify utilities that can abstract information to aid the troubleshooting process. This section does not attempt to duplicate information that is found in Windows 2000, Windows XP, or Windows Server 2003 Help or that is accessible through the IPSec Troubleshooting Tools page. Detailed tool information is only provided in this section if it is not readily found through the referenced Troubleshooting tools page or where it is useful to have summaries across operating system versions.
IP Security Policy Management MMC Snap-In The IP Security Policy Management MMC snap-in is used to create and manage local IPsec policies or IPsec policies stored in Active Directory. It can also be used to modify IPsec policy on remote computers. The IP Security Policy Management MMC snap-in is included in Windows Server 2003, Windows XP, Windows 2000 Server, and Windows 2000 Professional operating systems and it can be used to view and edit IPsec policy details, filters, filter lists, and filter actions and to assign and un-assign IPsec policies.
IP Security Monitor MMC Snap-In The IP Security Monitor MMC snap-in shows IPsec statistics and active SAs. It is also used to view information about the following IPsec components: •
IKE main mode and quick mode
•
Local or domain IPsec policies
•
IPsec filters that apply to the computer
Although this snap-in is part of the Windows XP and Windows Server 2003 operating systems, there are functionality and interface differences between the Windows XP and Windows Server 2003 versions. Also, the Windows Server 2003 version has the following additional features: •
Provides details on the active IPsec policy, including the policy name, description, date last modified, store, path, OU, and Group Policy object name. To obtain the same information in Windows XP you must use the IPseccmd command-line tool (described later in this section).
Chapter 7: Troubleshooting IPsec
•
167
Statistics are provided separately for main mode or quick mode, in folders under each mode rather than in one display.
Note In Windows 2000, IP Security Monitor is a stand-alone executable program (IPsecmon.exe) with its own graphical user interface (GUI). This tool and how it can be used is described in Microsoft Knowledge Base article 257225, "IPsec troubleshooting in Microsoft Windows 2000 Server".
An update to this snap-in is available for Windows XP as part of the update that is described in Microsoft Knowledge Base article 818043, "L2TP/IPSec NAT-T update for Windows XP and Windows 2000". This update makes it possible to view Windows Server 2003 computers from Windows XP. The updated IP Security Monitor MMC snap-in can also read advanced features created in Windows Server 2003 (for example, DiffieHellman 2048 group information, certificate mappings, and dynamic filters), but cannot edit them. For more information see the referenced Knowledge Base article.
Netsh Netsh is a command-line scripting utility that allows you to display or modify the network configuration. In addition, you can use Netsh either locally or remotely. Netsh is available for Windows 2000, Windows XP, and Windows Server 2003. However, the Windows Server 2003 version is enhanced to provide IPsec diagnostic and management functionality. The Netsh commands for IPsec are only available for Windows Server 2003; they replace Ipseccmd in Windows XP and Netdiag as used in Windows 2000.
Ipseccmd Ipseccmd is a command-line alternative to the IP Security Policy MMC snap-in. It is only available for Windows XP, and Windows XP Service Pack 2 provides additional functionality for this tool. Ipseccmd must be installed from the Support Tools folder on the Windows XP CD. An updated version is available with Windows XP SP2, which must be installed from the Support Tools folder on the Windows XP SP2 CD. The pre-SP2 version does not work on updated computers, and the updated version does not work on pre-SP2 computers. The updated Ipseccmd utility has the following capabilities: •
Dynamically turns IKE logging on and off
•
Displays information about a currently assigned policy
•
Enables you to create a persistent IPsec policy
•
Can display the currently assigned and active IPsec policy
For more information on the updated Ipseccmd utility, refer to Microsoft Knowledge Base article 838079,”Windows XP Service Pack 2 Support Tools”. To display all IPsec policy settings and statistics for diagnostics, use the following syntax: ipseccmd show all To display currently assigned and active IPsec policies (local or Active Directory), use the following syntax: ipseccmd show gpo Note
This command only works with the SP2 version.
To enable debug logging in Windows XP SP2, use the following syntax (no IPsec service restart is required): ipseccmd set logike
168
Server and Domain Isolation Using IPsec and Group Policy
To turn off debug logging, use the following syntax (again, no IPsec service restart required): ipseccmd set dontlogike Note You can only use Ipseccmd to enable Oakley logging in Windows XP SP2; the above commands do not work on pre-SP2 computers.
Netdiag Netdiag is a command-line diagnostic tool that is used to test network connectivity and configuration, including IPsec information. Netdiag is available in Windows 2000, Windows XP, and Windows Server 2003, but its functionality changes with the operating system version. In Windows Server 2003, Netdiag no longer includes IPsec functionality; instead, you can use the netsh ipsec context, and basic network testing is also obtainable from Netsh. For all operating system versions, it is important to make sure you are using the latest version by checking the Microsoft Download Center. Netdiag must be installed from the Support Tools folder of whichever Windows operating system CD is used. Note
Netdiag is not updated when Windows XP SP2 is installed.
The relevance of Netdiag to IPsec troubleshooting depends on the operating system version. Functionality differences are described in the following table. Table 7.1 Netdiag IPsec Functionality in Different Operating Systems Command
Description
Windows 2000?
Windows XP?
Windows Server 2003?
netdiag /test:ipsec
View the assigned IPsec policy
Yes
Yes
No**
netdiag /test:ipsec /debug
Display the active IPsec policy, filters, and quick mode statistics
Yes
Yes*
No**
netdiag /test:ipsec /v
Display the active IPsec policy, filters, and main mode statistics
Yes
Yes*
No**
* Provides network diagnostics, but displays IPsec policy name only. Additional IPsec information is available by using Ipseccmd. ** Provides network diagnostics, but does not display any IPsec information. Instead, use the following syntax: netsh ipsec dynamic show all.
Chapter 7: Troubleshooting IPsec
169
Other Useful Tools for Supporting IPsec In addition to the IPsec-specific tools noted earlier, the following table lists other tools that may be useful in troubleshooting and should be included in your Tier 2 troubleshooting toolkit. Table 7.2 Miscellaneous Useful Tools for IPsec Troubleshooting Tool
Supported How to operating obtain systems
Role
More information
Ipsecpol.exe Windows 2000 only
Windows 2000 Resource Kit
Configures Windows 2000 Resource Kit IPsec Tools Help policies in the directory or in a registry
Gpresult
Windows 2000, Windows Server 2003, Windows XP
Windows 2000– Resource Kit; for Windows XP and Windows Server 2003, it is part of the operating system
Check when Windows 2000 Resource Kit Group Tools Help, Windows XP and Policy was Windows Server 2003 Help last applied
Resultant Set of Policy (RSoP) MMC snap-in
Windows Server 2003, Windows XP
Part of the operating system
View IPsec Windows Server 2003 Help policy for a computer or for members of a Group Policy container
Srvinfo
Windows 2000, Windows Server 2003, Windows XP
Windows 2000 and Windows Server 2003 Resource Kits
Services, device drivers, and protocols information
PortQry
Windows 2000, Windows Server 2003, Windows XP
Windows Network Server port status 2003 reporting Resource Kit
Windows Server 2003 Resource Kit Tools Help
http://support.microsoft.com/kb/31 0099
170
Server and Domain Isolation Using IPsec and Group Policy
Tool
Supported How to operating obtain systems
Role
More information
NLTest
Windows 2000, Windows Server 2003, Windows XP
Support Tools
Test trust Windows Server 2003 Support relationships Tools Help and Netlogon secure channels
KList
Windows 2000, Windows Server 2003, Windows XP
Windows Kerberos 2000 and ticket Windows reporting Server 2003 Resource Kits
Windows Server 2003 Resource Kit Tools Help
Pathping
Windows 2000, Windows Server 2003, Windows XP
Part of the operating system
Network connectivity and path testing
Windows Help
LDP
Windows 2000, Windows Server 2003, Windows XP
Support Tools
LDAP client for Active Directory testing
Windows Server 2003 Support Tools Help
Using ICMP-Based Tools with IPsec Windows XP and Windows Server 2003 Ping, Pathping, and Tracert are aware of IPsec, but may not function correctly until soft SAs are established (if Fall back to clear is allowed). If IPsec SAs were negotiated successfully to encapsulate the ICMP traffic used by these utilities, they would not be able to detect any intermediate hops (routers) between the client and the target destination. Calculations on packet loss for Ping may show packets lost during the time required for IKE to successfully negotiate an IPsec SA pair with the target. Calculations on packet loss for each intermediate hop will not be available when ICMP traffic is encapsulated by IPsec. These ICMP utilities are designed to detect whether the IPsec driver matched an IPsec filter to the outbound ICMP echo request packet, and therefore requested IKE to negotiate security. When this happens, the message "Negotiating IP security" is displayed by the utility. A known bug in Windows 2000 causes the Ping utility to not wait the proper amount of time before retrying the next echo request, which means that the command may complete immediately instead of waiting three seconds until the soft SA is established. The Ping utility in Windows XP and Windows Server 2003 waits the expected number of seconds before the next echo request is sent.
Chapter 7: Troubleshooting IPsec
171
The "Negotiating IP security" message will not display under the following conditions: •
If the IPsec driver drops the outbound ICMP packet because of a blocking filter.
•
If the IPsec driver allows the ICMP packet to pass unsecured because of a permit filter or a soft SA.
•
If the IPsec driver does not detect the outbound packet (for example, if it was dropped by layers above the IPsec driver).
Note Some tools that use ICMP may not be able to detect that IPsec is negotiating security and may produce inconsistent or erroneous results.
The IPsec Troubleshooting Process If Tier 1 support has clearly identified the problem, then Tier 2 support will be able to quickly find the relevant troubleshooting procedure in the following sections. In this model, Tier 1 support primarily handles client-related access problems. It is expected that administrative owners of servers will be able to perform basic network connectivity diagnostics and may skip Tier 1 support. However, each organization should adjust the model for their support environment. Tier 2 support should focus on identifying where the failure to communicate is happening, then investigate related possibilities in the architecture of the system. If your organization is using the scripts that are provided as part of the troubleshooting process, you will have access to a number of text log files that can be used to help diagnose the problem. Descriptions of the files that the script generates are provided in the following table. Table 7.3 Files Created from the IPsec_Debug.vbs Script File name
Description
_FileVer.txt
Lists the file versions of various IPsec-related DLLs.
_gpresult.txt
Output of the gpresult command.
_ipsec_547_events.txt
Output of any IPSEC 547 errors in the Security event log.
_ipsec_policy_version.txt Output of the Detect_IPsec_Policy.vbs script. Shows the current policy version on the box and if it matches the Active Directory policy. _ipseccmd_show_all.txt
Only on Windows XP. This file captures the output of the ipseccmd command.
_kerberos_events.txt
Output of any Kerberos events in the System event log.
_klist_purge_mt.txt
Output from KList while purging machine tickets.
_lsass.log
Copy of the lsass.log file if present.
_netdiag.txt
Output from running netdiag.
_netsh_show_all.txt
Only on Server platforms. Output from the show all command in netsh.
172
Server and Domain Isolation Using IPsec and Group Policy
File name
Description
_netsh_show_gpo.txt
Only on Server platforms. Output from the show gpo command in netsh.
_oakley.log
Copy of the Oakley.log file, if present.
_OSInfo.txt
Output of current operating system information.
_RegDefault.txt
Output of the original registry key values prior to changing. Can be used to manually reset the registry to previous values if the script fails for some reason.
_userenv.log
Copy of the userenv.log file, if present.
__netview.txt Output of the net view command against . __ping.txt
Output of the ping command against .
_winlogon.log
Copy of the winlogon.log file, if present.
Because there are many potential points of failure, this section addresses each architectural component in order, starting with network connectivity. Procedures are defined that will help you perform the following tasks: •
Verify IP network configuration, network connectivity and service with domain controllers, and client-server path connectivity for IPsec-related protocols.
•
Verify correct application of Group Policy and IPsec policy on both client and server.
•
Investigate issues with IKE negotiation and IPsec-protected communication.
•
Identify the cause of a problem for Tier 3 escalation, if required.
Consider the following example scenario: a client reports being able to ping a server, but not being able to connect to a file share on that server. This is the only server the client cannot access. A quick review of the Security Log for event 547 (IKE negotiation failure), which contains the IP address of the server, will indicate that the client has an IPsec policy and that IKE is being initiated. If the client event 547 indicates that the client IKE negotiation timed out, the server IKE likely failed the negotiation. Tier 2 support would then review the MOM event database for 547 events that are collected from the specified server, which will contain the current client IP address.
Warning: Starting and Stopping the IPsec Service The Windows Server 2003 TCP/IP Troubleshooting document and other references describe how to determine if IPsec is causing a connectivity problem by stopping the IPsec service. Although this will stop IPsec filtering on the computer, it will also disable the protection that IPsec provides, expose the computer to untrusted network access, and disable packet protection. Also, in a domain isolation environment, TCP and UDP traffic that is not protected by IPsec will be dropped by other isolation domain members. If IPsec is disabled on one computer, it will cause connectivity interruptions with those remote computers that currently have IPsec security associations established. When the IPsec service is stopped, IKE sends delete notifications for all IPsec SAs and for the IKE SA to all actively connected computers. Remote computers with IPsec policy that allowed Fall back to clear will re-establish connectivity after a three second delay. Remote
Chapter 7: Troubleshooting IPsec
173
computers with IPsec policy that does not allow Fall back to clear will be unable to communicate. Therefore, it is important to use the techniques discussed in the following sections to troubleshoot isolation scenarios without stopping the IPsec service. The IPsec service should be disabled only as a last resort to rule out IPsec-related problems for the following situations: •
Broadcast and multicast traffic environments
•
Connections to remote computers that do not require IPsec for inbound access (for example, the computers that are members of the exemption list)
In Windows 2000, stopping the IPsec service will unbind the IPsec driver from TCP/IP and unload the IPsec driver from memory. In Windows XP and Windows Server 2003, stopping the IPsec service will delete all filters from the IPsec driver and set the driver mode to PERMIT. It does not unload the IPsec driver from memory. The IPsec service must be disabled and the computer restarted to avoid loading the IPsec driver. In Windows 2000 and Windows XP SP1, IKE logging to the Oakley.log file requires a restart of the IPsec service. Stopping the service is not required to enable and disable IKE logging to the Oakley.log file in Windows XP SP2 and Windows Server 2003. The latest update to Ipseccmd for Windows XP SP2 provides the syntax ipseccmd set logike and ipseccmd set dontlogike to dynamically enable and disable IKE logging to the Oakley.log file. Windows Server 2003 IKE logging can be enabled dynamically using the Netsh commands described in online Help.
Verifying Network Connectivity If Tier 1 support identifies possible network connectivity issues, then the first step is to determine if basic network connectivity exists. This determination involves verifying that the proper IP configuration is being used, that there is a valid network path between the initiator and the responder computer, and that name resolution services are working.
Network IP Address Configuration Problems If dynamic IP configuration is not successful, or if communications are blocked after restarting the computer (or even during normal operation), IPsec may be the cause. In Windows Server 2003, such problems may be related to IPsec failsafe behavior (for example, if the computer is started in Safe Mode or Active Directory Recovery Mode). Note For details about Windows Server 2003 failsafe behavior, see "Understanding IPSec Protection During Computer Startup".
Windows Server 2003 resorts to failsafe behavior if the IPsec service cannot successfully start or cannot apply the assigned policy. Failsafe only applies when an IPsec policy is assigned to the computer and when the IPsec service is not disabled. Consequently, connectivity to or from a computer could fail during normal operation because the IPsec driver is not enforcing the domain-based IPsec policy. After you determine what traffic is allowed and blocked by bootmode and persistent configurations, a communications failure may be easy to explain. To obtain alternative or additional information, you can query the current state from the command line by using the following syntax: netsh ipsec dynamic show config For Windows Server 2003, the IPsec driver is loaded at computer startup time with the TCP/IP driver. Therefore, to remove the IPsec driver failsafe behavior, the IPsec service must be disabled and the computer restarted. The previously referenced IPsec deployment chapter includes recommended configuration of boot exemptions to exempt
174
Server and Domain Isolation Using IPsec and Group Policy
inbound Remote Desktop Protocol connections, which will ensure that remote access to the server is available when other traffic is blocked. In a server and domain isolation solution, broadcast traffic and traffic to the DHCP servers is exempt to ensure that dynamic IP configuration works properly. However the exemption list must be maintained manually and may become outdated. If a computer cannot obtain proper DHCP configuration (for example, if it uses an Auto-configuration IP address of 169.254.x.x) or has problems renewing the lease, then the IPsec policy should be examined for proper exemptions. With the IPsec service running, use Ipconfig to confirm there are no problems obtaining an address. For DHCP clients, open a command window and enter the following: ipconfig /release ipconfig /renew If the address configuration problems only happen during computer startup for Windows XP SP2 and Windows Server 2003, the configuration for exemptions (default exemptions and boot exemptions) should be inspected.
Name Resolution Problems The IPsec policy design used in the server and domain isolation scenarios should not interfere with typical procedures that are used to determine if name resolution is working. For example, in the Woodgrove Bank scenario, the IPsec policy design exempts all traffic to DNS and WINS servers. However, it is possible that DNS and WINS servers could be configured to not respond to Ping requests. Answer the following questions to confirm that name resolution is working properly while the IPsec service is running: •
Can the client ping the DNS server IP address listed in its IP configuration?
•
Can nslookup find a DNS server?
•
Can the client ping the fully qualified DNS name of the target?
•
Can the client ping the shortened DNS or NetBIOS name of the target?
Potential sources of name resolution problems include an active and misconfigured HOSTS file, a misconfigured DNS server entry in IP properties, incorrect DNS record registrations, zone file update problems, Active Directory replication issues, Fall back to clear used for DNS servers, and DHCP auto-update issues. Possible reasons for NetBIOS name resolution failures include an active and misconfigured LMHOSTS file, a misconfigured WINS server entry in IP properties, WINS server unavailability, incorrect WINS record, WINS replication problems, WINS proxy failures, and network timeouts reaching the WINS server. For procedures to help troubleshoot Active Directory-integrated DNS, refer to the Active Directory Operations Overview: Troubleshooting Active Directory-Related DNS Problems page. Some high-security environments may require DNS and WINS servers to be protected with IPsec, which can result in name resolution problems. For example, if DNS is integrated within Active Directory and there are duplicate filters for the same IP address in the IPsec policy, one filter may negotiate security to the DNS server and one may exempt the domain controllers. For more information, see the "Troubleshooting IPsec Policy" section later in this chapter.
Chapter 7: Troubleshooting IPsec
175
If name resolution problems persist, you can get the filter list from the initiator and check for duplicate filters. You can use the following command line options to view the filter lists for this task: Ipseccmd show filters Netsh ipsec static show all If the name resolution problems still persist, the IPsec service should be stopped briefly (if possible) while name resolution tests are repeated. If name resolution tests only fail when the IPsec service is running, investigation should continue to determine which IPsec policy is being applied, as discussed later in this section.
Verifying Connectivity and Authentication with Domain Controllers Because IPsec policy delivery, IKE authentication, and most upper layer protocols depend on access to domain controllers, tests for network connectivity and successful operation of authentication services should be performed before IPsec-specific troubleshooting steps (described in the next section) are performed. In a scenario such as Woodgrove Bank, IPsec policy design exempts all traffic to all domain controllers, so network connectivity tests to the domain controllers should not be affected by IPsec. However, the list of domain controller IP addresses in the exemption list must be maintained manually. If IKE negotiation is seen to a domain controller IP address, then the IPsec policy may be incorrectly assigned or not updated. To troubleshoot access to network services in Active Directory •
Check that the client can ping each domain controller IP address. If not, refer to the network connectivity steps above.
•
Identify which IP addresses are used for the domain member's domain controllers. Use nslookup to return the full list of IP addresses. In a server and domain isolation scenario there should be a quick mode-specific filter with a negotiation policy (filter action) of permit for each of these addresses.
•
Use version 2.0 or later of the portqry.exe tool or the PortQueryUI tool to test access to the domain controller UDP, LDAP, and RPC ports. The UDP protocol messages used by portqry do not usually require upper layer protocol authentication, so they can verify service availability even if authentication is not available. These steps are explained in Microsoft Knowledge Base article 816103, “HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues”.
•
When connected to the internal network, use netdiag /v >outputfile.txt to perform many DNS-related and domain controller-related connectivity tests. Netdiag uses multiple network connections and protocols to perform testing; if any of these connections trigger IKE negotiations and the authentication fails because IKE is unable to locate a domain controller for Kerberos authentication, the Event 547 failure error may be logged in the security log.
The Windows Support tool klist.exe can be used to verify successful Kerberos login and authentication. Klist must be run in the local system context to view the Kerberos tickets for the computer. To view Kerberos service tickets for the logged in domain user •
Open a command prompt and type the following: klist tickets
176
Server and Domain Isolation Using IPsec and Group Policy
To view domain computer tickets 1. Verify the Task Scheduler service is running and the logged on user is a member of the Local Administrators group. 2. At a command line prompt, chose a time one minute ahead of the current system time (such as 4:38 pm) and type the following: at 4:38pm /interactive cmd /k klist tickets Note that the command window title bar contains C:\Windows\System32\svchost.exe. Although Kerberos tickets contain group information for the user or the computer, this information is encrypted so that the groups cannot be viewed. Therefore group membership must be confirmed manually by inspecting the group membership in Active Directory. To ensure that computers have the latest group membership information in their Kerberos tickets, use klist to purge the current Kerberos tickets. When IKE negotiation is attempted again, new Kerberos tickets will be obtained automatically. To purge the Kerberos tickets for the computer (Steps 1-4 must be run in Local System context) 1. Verify the Task Scheduler service is running and the logged on user is a member of the Local Administrators group 2. At a command-line prompt, chose a time one minute from the current system time (such as 4:38 pm) and type the following: at 4:38pm /interactive cmd 3. Type klist purge and press Y for each ticket type to delete all Kerberos tickets. 4. Type klist tickets to confirm that no tickets exist. 5. If this procedure is part of troubleshooting IKE negotiation failure, wait one minute for IKE negotiation to time out and then try to access the target server again with the application. New IKE main mode negotiations will request new Kerberos TGT and service tickets for the destination computer, which will have the latest group information available. Be careful not to execute the application from the command window that is running in Local System context. Additional detailed procedures for troubleshooting Kerberos are published in the following white papers: •
Troubleshooting Kerberos Errors.
•
Troubleshooting Kerberos Delegation.
Verifying Permissions and Integrity of IPsec Policy in Active Directory It may be necessary to verify information about the IPsec policy container in Active Directory. The following procedure uses the support tool ldp.exe. To verify information about the IPsec policy container 1. Click Start, Run, type ldp.exe and press ENTER. 2. Select Connection, and then Connect. Specify the name of the target domain. 3. Select Connection, and then Bind. Specify logon credentials for the target domain.
Chapter 7: Troubleshooting IPsec
177
4. Select View, and then Tree. Either specify no base DN and navigate to the IPsec policy container, or specify the LDAP DN for the IPsec policy container as a base location. 5. Click the plus sign (+) next to the container node in the tree view. If you have Read permissions on the container, all IPsec policy objects in the container will display. Note Some domain users may not have Read access to the container because of the way permissions are configured. For more information, see Microsoft Knowledge Base article 329194, "IPSec Policy Permissions in Windows 2000 and Windows Server 2003".
For advanced troubleshooting of policy retrieval and corruption problems, ldp.exe can be used to manually inspect the contents of the IP Security container and the relationship of among IPsec policy objects. Windows 2000, Windows XP, and Windows Server 2003 use the same basic directory schema for IPsec policy that is shown in the IPsec Policy Structure diagram in the Windows Server 2003 How IPsec Works technical reference. The following table shows the relationship between the Active Directory object names and the IPsec policy component names that are configured in the IPsec Policy Management MMC snap-in: Table 7.4 IPsec Policy Component to Active Directory Object Name Mapping IPsec policy component name
Active Directory object name
IPsec Policy
ipsecPolicy{GUID}
IKE Key Exchange Security Methods
ipsecISAKMPPolicy{GUID}
IPsec Rule
ipsecNFA{GUID}
IPsec Filter List
ipsecFilter{GUID}
IPsec Filter Action
ipsecNegotiationPolicy{GUID}
Ldp.exe provides the ability to identify the last time IPsec policy objects were modified, which can help troubleshoot object version and replication issues. It can be launched from a command window in the context of the local system to troubleshoot Read permission issues for the IPsec service. Caution: It is strongly recommended that all objects in the IP Security container have the same permissions. Microsoft does not recommend setting permissions on individual IPsec policy objects. To control Read and Modify access for IPsec policy, permissions should be managed on the IP Security container itself as explained by Knowledge Base article 329194, "IPSec Policy Permissions in Windows 2000 and Windows Server 2003".
Corruption of the IPsec policy is the most common reason for situations in which an IPsec object contains a DN reference to an object that no longer exists. However, corruption may also occur if control characters become part of the name of an object, individual objects are unable to be read due to permission problems, or identical names for objects cause improper IPsec policy design (for example, two versions of the same filter list). See the following "IPsec Service" troubleshooting section for more information about how to correct IPsec policy corruption. Note The design details of these objects are considered an internal private data structure and are not published by Microsoft. Differences exist within the format of these objects in different Windows releases, and Microsoft may make changes in these formats at any time. Therefore, these objects should only be managed using the IPsec Policy Management MMC snap-in and the command-line tools that are available for each platform. You should only delete objects by using LDP as a final option, when corruption prevents the IPsec Policy Management MMC snap-in or command-line tools from being used.
178
Server and Domain Isolation Using IPsec and Group Policy
Network Path Connectivity Microsoft recommends that the ICMP protocol be exempted in server and domain isolation solutions. There are several reasons for this recommendation, including the need to use ICMP for network path testing by utilities such as Ping, Pathping and Tracert. These utilities should, therefore, work properly and not display the "Negotiating IP security" message. If this message displays, then an improper IPsec policy may have been assigned. To determine whether the problem is related to basic network configuration or path connectivity •
Can the client ping its own IP address or the local loopback address 127.0.0.1? If not, then there could be a problem with the TCP/IP configuration, a third-party firewall may be installed, the Ping utility is missing, or the IP configuration is invalid. Use other TCP/IP configuration troubleshooting procedures to investigate.
•
Can the client ping the default gateway shown in its IP configuration? If not, then the IP configuration on the client may be a problem, the local interface may not be connected or may have limited connectivity, local or network filters may be blocking traffic, or the network path to the default gateway may be interrupted. Use other TCP/IP troubleshooting procedures to investigate.
•
Can the client ping the DNS servers shown in its IP configuration? If not, then the DNS servers may not allow themselves to receive ICMP echo request messages, the IPsec policy may not be exempting the proper DNS server IP addresses, or any of the possible issues mentioned previously may exist. Use other TCP/IP troubleshooting procedures to investigate.
•
Can the client ping an IP address in the exemption list, such as a DC? If not, then IPsec is not causing the problem or IPsec does not have a filter for that exempted IP address. The latter can be confirmed by inspecting the filter configuration. See the following IPsec policy section later in this chapter.
•
Can the client ping the IP address of the target destination? If yes, then basic network connectivity exists between the client and the target without IPsec. If no, then try tracert to the target and other destination IP addresses to determine how far the network path is valid. Use other TCP/IP and core network troubleshooting procedures to investigate.
Path connectivity tests may succeed for ICMP, but not when using IKE or IPsec protocols. In particular, the IPsec overhead for IKE main mode authentication packets that contain the Kerberos ticket is often larger than the PMTU for the destination IP address, which requires fragmentation. Therefore, host-based firewalls, filtering in routers, network firewalls, and filters on the target host must be open to the following protocols and ports and support fragmentation: •
IKE. UDP source port 500, destination port 500 and fragments
•
IKE/IPsec NAT-T. UDP source port 4500, destination port 4500
•
IPsec ESP. IP protocol 50 and fragments
•
IPsec AH. IP protocol 51 and fragments
Stateful Filtering in the Path Is Not Recommended Stateful filtering may cause connectivity problems for IKE, AH, and ESP because the state is typically based on activity timeouts. Devices cannot inspect IKE traffic to determine when IPsec SAs are deleted because these messages are encrypted by IKE. By definition, IKE is required to be able to rekey in either direction, which means delete messages may be sent in either direction. If one side does not receive a delete message, it may believe that an IPsec SA pair still exists when the peer no longer recognizes it and
Chapter 7: Troubleshooting IPsec
179
discards those packets that use it. The direction that IKE will rekey is based on the direction of traffic flow that expires the byte-based lifetime more quickly, the small offsets for rekey when the time-based lifetime expires, and the direction that packets flow after idle IPsec SAs are deleted. Host-based stateful filtering of IKE traffic on clients that initiate connections (and thus IKE negotiations) through Windows Firewall usually does not cause a problem. Windows Firewall does not filter IPsec packets, because the IPsec driver processes packets at a lower layer than the layer at which the firewall filtering is performed. However, the IKE ports should be configured open in the host firewall to receive incoming IKE negotiations for upper layer protocol connections that are allowed through the firewall (for example, for file sharing using SMB protocol over TCP port 445).
Support for ICMP PMTU Required by TCP The default setting in Windows 2000 and later releases is for each TCP packet to have the Don't Fragment bit set in the IP header. This setting is preserved when either AH or ESP IPsec transport mode is used to secure the packet. Therefore, a packet that is too big will be dropped at the router and the router should return an ICMP Destination Unreachable message that specifies the maximum size allowed. This behavior is called TCP Path MTU Discovery. Both the client and the target computer must be able to receive ICMP PMTU messages for IPsec packets that are too big. It is especially important for IPsec-protected traffic to avoid fragmentation, because hardware acceleration typically does not process fragmented packets. Fragmented IPsec packets must be processed by the IPsec driver in software. Windows 2000 and Windows XP do not support ICMP PMTU discovery processing for IPsec transport mode packets that use the NAT traversal encapsulation (UDP port 4500). Windows Server 2003 does support this discovery processing. See the "Troubleshooting Translational Bridging" page. Note There is a known issue that requires TCP PMTU detection to be enabled for IPsec to secure traffic in a NAT traversal scenario where IPsec UDP-ESP connections are initiated from a host outside of the NAT to a host behind a NAT. If this scenario is required, confirm that TCP PMTU detection is enabled either by ensuring that the following registry key is not defined or set to 1 on both sides: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\EnablePMTUDiscovery=1 (This key may display on more than one line; it is a single line in the registry.) The Microsoft Windows Server 2003 Member Server Baseline Security Policy template and other third-party configurations may configure this registry key in order to disable TCP PMTU.
Support Required for Fragmentation Network paths and filters must support passing fragments for the IKE, IPsec, AH, and ESP protocols. IKE uses UDP packets and allows them to be fragmented as necessary. The IPsec NAT traversal implementation added support for IKE fragmentation avoidance only when IKE authenticates with certificates (for example, in L2TP/IPsec VPN scenarios). IKE authentication that uses Kerberos does not support fragmentation avoidance and must be able to send and receive fragmented UDP packets that contain the Kerberos ticket. The network path must support passing fragments for AH and ESP because IPsec secures the entire original IP packet before outbound fragmentation at the IP layer. IPsec is integrated with TCP so that when TCP packets have the DF (Don’t Fragment) flag set (the default setting), TCP will reduce its packet size to accommodate the additional bytes that are added by IPsec encapsulation. IPsec is not integrated with UDP, and UDP applications do not have a method to detect if IPsec is protecting their traffic. Consequently, when IPsec AH or ESP is applied, UDP
180
Server and Domain Isolation Using IPsec and Group Policy
packets that use the full MTU size will become fragmented by the host when transmitted. Similarly, if IPsec policy filters do not exempt ICMP, use of the Ping utility may produce ICMP packets that appear as fragmented IPsec AH or ESP packets on the wire. For more information, see Microsoft Knowledge Base article 233256, “How to Enable IPSec Traffic Through a Firewall”.
Support Required for Broadcast or Multicast Traffic The IPsec policy design for server and domain isolation uses filters from Any Subnet. Therefore, the outbound filter Subnet -> Any will match outbound broadcast and multicast traffic sent from hosts using an internal subnet IP address. However, because IPsec cannot secure multicast or broadcast traffic, it must discard such traffic if it matches the filter. Inbound multicast and most types of broadcast will not match the corresponding Any -> Subnet inbound filter. If multicast or broadcast traffic is required, then you can set the registry key to NoDefaultExempt=1, which allows multicast and broadcast traffic to bypass IPsec filtering in Windows XP and Windows Server 2003. This configuration prevents known problems with Real Time Communications (RTC) clients and Windows Media Server, both of which use multicast traffic. For details about the use and security implications of the NoDefaultExempt registry key, see the following Knowledge Base articles: •
810207, IPSec default exemptions are removed in Windows Server 2003.
•
811832, IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios.
Note
Windows XP SP2 uses the same default exemptions as Windows Server 2003.
The registry key can be set to control the default exemptions as necessary for all platforms. IPsec filtering does not support configuring destination addresses for specific broadcast or multicast addresses.
Diagnostics in Network Devices May Not Be Useful One of the impacts of using IPsec encapsulation is that applications which assume TCP/IP traffic is in plaintext can no longer inspect traffic within the network. Network diagnostic tools that inspect or provide reports based on TCP and UDP ports are unlikely to be able to interpret the IPsec-encapsulated packets, even if AH or ESP encryption is not used. Updates to such tools may be required from vendors to inspect IPsec AH or ESP-null packets.
Network Interface Card and Driver Issues IPsec packet loss can sometimes be caused by network interface cards (NIC) that perform special functions. Cards that perform clustering or "teaming" should be tested for IPsec compatibility. NIC drivers that accelerate non-IPsec functions may have problems with IPsec-protected traffic. NICs that accelerate TCP functions may be ones that support TCP checksum calculation and validation (checksum offload), as well as the ability to efficiently send large TCP data buffers (large send offload). Windows 2000 and later releases automatically disable these TCP offload functions in the TCP/IP stack when the IPsec driver has filters, even if IPsec is performing only permit and block functions. Network card drivers that are not certified and signed by the Windows Hardware Quality Lab (WHQL) may cause problems when IPsec is used to protect traffic. An extensive set of tests is used by WHQL to certify NIC drivers that are designed to support IPsec offload. To assist troubleshooting, the Windows 2000, Windows XP and Windows Server 2003 TCP/IP stack supports a registry key option to disable all forms of TCP/IP offload. Some NIC drivers also support the ability to disable offload by using the Advanced
Chapter 7: Troubleshooting IPsec
181
properties of the network connection. The computer may need to be restarted for driverlevel configuration changes to take effect.
Troubleshooting Packet Loss in IPsec Protocols Packets can be discarded or lost, which may affect application connectivity. This section reviews common cases in which packets are discarded by IPsec. As previously mentioned, certain network devices may not allow IP protocol types 50 or 51 or UDP port 500 or 4500 to pass. Similarly, IPsec-encapsulated packets may cause some packets to fragment and not pass through the network. In such cases, a network monitor trace is usually needed from both sides of the communication to identify and correlate which packets are being sent and which received. Look for retransmissions indicated by the same size of packet appearing repeatedly. It may be necessary to capture a trace of the typical protocol behavior without IPsec and then compare it with the protocol behavior of IPsec-protected traffic.
Event Error 4285 Event title: Hash Authentication Failure IKE and IPsec provide protection against modification of packets while they transit the network. If a device modifies a part of the packet that is protected by an integrity hash, then the receiving IKE or IPsec driver will discard this packet and cause the Hash Authentication Failure error, which is logged in the System Log as event 4285. Experience has shown that some devices, network drivers, and third-party packet processors occasionally corrupt packets of a certain size, those with a certain number of fragments, those of certain protocol types, or under certain conditions (such as when the device is congested, monitors traffic, or reboots). This error may also represent an attack on the packet by a malicious application, or by an application that did not realize it was protected. The error may also be an indicator of a denial of service attack. To detect IPsec packet discards of corrupted packets, the following techniques can be used. However, it is also important to correlate these observations with a network monitor trace so that the source of the corruption can be found. •
Examine the IPsec Packets Not Authenticated counter. In Windows Server 2003, this counter can be checked by using the IPsec counter in Performance Monitor, by using the netsh ipsec dynamic show stats command, or by looking at Statistics in the IPsec Security Monitor MMC snap-in. In Windows XP, this counter can be checked by using the ipseccmd show stats command or by looking at Statistics in the IPsec Security Monitor MMC snap-in. Windows 2000 shows this counter in the ipsecmon.exe graphical display, or by using the netdiag /test:ipsec /v command.
•
Enable IPsec driver logging and look for event 4285 in the System Log from source IPsec. See the "Toolkit" section in this chapter for details on how to enable IPsec driver logging. The event text will be similar to the following: Failed to authenticate the hash for 5 packet(s) received from 192.168.0.10. This could be a temporary glitch; if it persists please stop and restart the IPSec Policy Agent service on this machine.
Although the event text suggests that a restart of the IPsec service may fix the problem, the source of most packet loss problems is not the IPsec system. Restarting the service will not fix the problem and may cause more problems. The IPsec service should be stopped only as a last resort to identify whether a problem is IPsec-related or not. Resolution of this error requires investigation to identify a pattern of source IP addresses, times of day, adapters, or conditions in which the error occurs. If the number of packets is small, then this error may not warrant investigation. It is important to start by trying to exclude sources of corruption in the local system. Disable IPsec offload, try to disable
182
Server and Domain Isolation Using IPsec and Group Policy
advanced or performance features of the driver using the configuration provided by Advanced Properties, and use the latest NIC drivers that are available from the vendor, preferably those certified and signed by the Windows Hardware Quality Lab. Then investigate the characteristics of the network paths through which the packet would be transmitted. Look for other evidence of packet corruption in TCP/IP packet discard statistics and on other computers that use the same configuration. The IP counter for Datagrams Received Discarded will increase each time IPsec discards a packet. Note To disable TCP/IP offload functionality, use the following registry key for computers running Windows 2000, Windows XP, or Windows Server 2003: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\ EnableOffload DWORD registry value to 0 (This key may display on more than one line; it is a single line in the registry.) Then restart the computer.
Event Error 4268 Event title: Received Packets with Bad Security Parameters Index (SPI) The Windows 2000 and Windows XP (including SP1) implementation of IKE has a known issue that results in packet loss under particular conditions. This issue is fixed in Windows Server 2003 and Windows XP SP2. The impact on upper layer protocol communications is usually negligible, because protocols already expect some packet loss for a variety of other reasons. This issue can be identified by the following issues: •
Slow but consistent increase in Bad SPI counter values.
•
System Log event 4268 messages (if enabled). By default, Windows 2000 logs these messages to the System Log as event 4268. Windows XP does not log this event by default; driver logging must be enabled. Event text is similar to the following: "Received packet(s) with a bad Security Parameters Index from . This could be a temporary glitch; if it persists please stop and restart the IPSec Policy Agent service on this machine."
Although the event text suggests that a restart of the IPsec service may fix the problem, the source of this type of packet loss is part of the design of the IPsec system. Restarting the service will not fix the problem and may cause more problems. As noted earlier, the IPsec service should be stopped only as a last resort to identify whether a problem is IPsec-related or not. An IPsec security parameter index (SPI) is a label in the packet that tells the responder which security association should be used to process the packet. If an SPI is not recognized, it is called a "bad SPI." This error indicates that the receiving computer received IPsec-formatted packets when it did not have an IPsec SA with which to process them. Therefore, it must discard the packets. These are benign error messages, although the packets are being discarded. The number of bad SPI events that are generated depends on how busy the computers are at the time and how fast IPsec-protected data is being transmitted at the time of rekey. The following conditions are likely to generate more of these events: •
Transferring high volumes of IPsec traffic over 1 Gigabit or higher connections.
•
When there are heavily loaded (slow) servers and fast clients.
•
When there are slow clients communicating to a fast server.
•
When there are many active clients for a server, which causes IKE to constantly rekey with many clients simultaneously.
Chapter 7: Troubleshooting IPsec
183
The impact is that an IPsec-protected TCP connection will slow down for a few seconds to retransmit the lost data. If several packets are lost, TCP may go into congestion avoidance mode for that connection. In a few seconds the connection should resume full speed. File copy, Telnet, Terminal Server, and other TCP-based applications should not notice these few lost packets. However, there have seen some cases in which TCP loses a burst of packets on a fast link and must reset the connection. When the connection is reset, the socket is closed and applications are notified of a connection break, which may interrupt file transfers. The most common cause of this error is a known issue with Windows 2000 that involves how IKE synchronizes IPsec SA keying. When an IKE quick mode initiator is faster than the responder, the initiator is able to send new IPsec SA secured packets sooner than the responder is ready to receive them. As specified in the Internet Engineering Task Force (IETF) IPsec Requests for Comment (RFC), when IKE establishes a new IPsec security association pair the initiator must use the new outbound IPsec SA to transmit data, and the slower responder receives IPsec-protected traffic that it doesn't yet recognize. Because IKE rekey is dependent on both the elapsed time and the amount of data sent under the protection of an IPsec SA, bad SPI events may be seen periodically (although not necessarily at specific intervals). In third-party client interoperability scenarios, a bad SPI error may indicate that an IPsec peer did not accept and process a delete message or had problems completing the last step of IKE quick mode negotiation. The error can also mean that an attacker is flooding a computer with spoofed or injected IPsec packets. The IPsec driver counts these events and logs them to keep a record of bad SPI activity. The LogInterval registry key can be used to investigate and minimize these events. When troubleshooting, set it to the minimum value (every 60 seconds) so the events are registered quickly. In Windows 2000, you can stop and restart the IPsec Policy Agent service to reload the IPsec driver. In Windows XP and Windows Server 2003, the computer must be restarted to reload TCP/IP and IPsec drivers. In Windows 2000, these events cannot be eliminated by any current registry key settings or patches. The default setting in Windows XP and Windows Server 2003 is to not report these events. Reporting of these events can be enabled by using the IPsecDiagnostics configuration through the netsh ipsec command-line option, or through the registry key directly. The following techniques can help minimize these errors: •
Adjust the IPsec policy settings. Increase the quick mode lifetimes (if security requirements will allow it) to 21 or 24 hrs (idle IPsec SAs are deleted in 5 minutes if they are not used). To avoid potential security weaknesses introduced by using the same key to encrypt too much data, do not set a lifetime greater than 100 MB when using ESP encryption.
•
Use main mode or quick mode perfect forward secrecy (PFS), which will not cause this problem for the particular IPsec SA that is being negotiated. However, either setting will substantially increase the load on the computer that services many clients, and therefore may contribute to the delay in response to other negotiations.
•
Add CPU or other hardware to increase performance or reduce application loads.
•
Install an IPsec hardware acceleration NIC if one is not already installed. These cards substantially reduce the amount of CPU utilization that IPsec uses for high throughput data transfer.
184
Server and Domain Isolation Using IPsec and Group Policy
•
If CPU utilization remains high, investigate use of a hardware accelerator product to speed up Diffie-Hellman calculations. These products are typically a PCI card with Diffie-Hellman exponentiation offload capability that accelerate the Diffie-Hellman calculations. This acceleration also benefits public and private key operations for certificates that use the Secure Sockets Layer (SSL) protocol. Verify with the vendor that their card specifically supports the "ModExpoOffload interface in CAPI for DiffieHellman calculations."
•
If possible, create a filter to permit certain high-speed traffic that does not need IPsec protection (for example, server backup traffic over a dedicated LAN).
If these options do not work, and upgrading to Windows XP SP2 or Windows Server 2003 is not possible, then contact Microsoft Product Support Services to see if there are other options currently available.
Event Error 4284 Event title: Packets in the clear that should be secured This event indicates that an IPsec security association was established at a time when packets were received in plaintext that should have been inside the IPsec security association. These packets are discarded to prevent packet injection attacks on IPsecsecured connections. Although the IP counter for Datagrams Received Discarded will be incremented, IPsec does not have a counter value that records packets dropped for this reason. This issue can only be identified from System Log error event 4284, which reads as follows: "Received packet(s) in the clear from which should have been secured. This could be a temporary glitch; if it persists please stop and restart the IPsec Policy Agent service on this machine." As with previous errors, the event suggestion should not be followed. It is unlikely that restarting the IPsec service will correct the error. The most likely cause of the error is a policy configuration problem that causes one side to send traffic in the clear because of a more specific outbound permit filter. For example, if a client has a filter to secure all traffic with a server and the server policy has a more specific filter to permit plaintext HTTP replies, the server will secure all traffic to the client except outbound HTTP packets. The client receives these packets and discards them for security reasons, because it expects all traffic to and from the server to be secured inside the IPsec SA pair. This event can also occur during regular operations and during third-party client interoperability cases in which one peer deletes an IPsec security association or a filter in the IPsec driver while traffic is flowing between the computers. For example, one side may unassign IPsec policy, or may experience a policy update that deletes IPsec SAs and filters. Because one peer has already deleted the filter while an active upper-level protocol communication is taking place, the IKE delete message may not arrive and be processed by the other peer before the plaintext packets arrive, which causes the error. Also, the amount of time it takes to process the delete message depends on the current load on the peer computer. The error message may also happen while a large policy is being loaded, because IPsec security associations may become established before the full filter set is applied to the IPsec driver. If this situation occurs, IPsec SAs may be negotiated for traffic that will be exempt after policy loading has completed.
Chapter 7: Troubleshooting IPsec
185
The error message can also be an indication of an injection attack where plaintext traffic is being sent that matches (either deliberately or by chance) the traffic selectors for a particular active inbound security association. This problem should be escalated to the IPsec policy designer.
IPsec NAT-T Timeouts When Connecting Over Wireless Networks A recent problem was found that causes connections to time out when Windows Server 2003 or Windows XP-based client computers attempt to connect to a server on a wireless network that uses IPsec NAT-T. For more information, see Microsoft Knowledge Base article 885267, “Connections time out when client computers that are running Windows Server 2003 or Windows XP try to connect to a server on a wireless network that uses IPsec NAT-T”.
Verifying the Correct IPsec Policy This section describes steps for detecting problems with IPsec policy assignment and interpretation. Filters from a properly interpreted IPsec policy must be in the IPsec driver for IPsec to permit and block packets, as well as to trigger IKE to negotiate IPsec SAs with remote IP addresses to secure traffic. Appropriate filters must also be in place to guide IKE as a responder. In this solution, the IPsec policy design requires all traffic (except ICMP) to be secured by IPsec. The policy also contains filters for each IP address in the exemption list. Note In Windows 2000, the IPsec service is called the IPsec Policy Agent; in Windows XP and Windows Server 2003 this service is called the IPsec Service.
Support engineers must be familiar with the use of Group Policy by IPsec, IPsec policy precedence, and IPsec policy interpretation. References to information about these topics can be found in the "More Information" section at the end of this chapter.
Troubleshooting Group Policy for IPsec Group Policy provides the mechanism for assigning a domain-based IPsec policy to a domain member. The retrieval of assigned GPOs by the domain member is what delivers the IPsec policy assignment to a host computer. Therefore, any problems with GPO retrieval will cause computers to not apply the proper IPsec policy. Common issues with Group Policy for IPsec policy management include the following: •
Replication delays of various configuration components in Active Directory
•
Problems with the Group Policy polling and download process
•
Confusion over which IPsec policy version is assigned
•
IPsec service is not running
•
IPsec policy in Active Directory cannot be retrieved, so a cached copy is used instead
•
Delays because of IPsec policy polling for retrieval of currently assigned IPsec policy
Replication may be delayed because of the number of IPsec-related objects in Active Directory, such as IPsec policies, GPOs, attribute changes in GPO IPsec policy assignments and IPsec policy, and security group membership information. Careful planning must be done to assess the impact of an IPsec configuration change as it gradually takes effect on domain members.
186
Server and Domain Isolation Using IPsec and Group Policy
For Group Policy troubleshooting procedures, see the following white papers: •
Troubleshooting Group Policy in Windows 2000
•
Troubleshooting Group Policy in Microsoft Windows Server
Domain-based IPsec policy assignment is implemented by two components: •
The IPsec Policy Management MMC snap-in (an extension of the Security Policy MMC snap-in) for assignment of an IPsec policy in the GPO
•
The Group Policy client side extension (CSE) for IPsec (implemented in gptext.dll) that processes the IPsec-related information in the GPO
Domain-based IPsec policy assignment is implemented by two components: •
The IPsec Policy Management MMC snap-in (an extension of the Security Policy MMC snap-in) for assignment of an IPsec policy in the GPO
•
The Group Policy client side extension (CSE) for IPsec (implemented in gptext.dll) that processes the IPsec-related information in the GPO
The IPsec Policy Management MMC snap-in assigns policy to a GPO by storing the selected IPsec policy information in the IPsec component of the GPO, which is referenced as the LDAP Distinguished Name (DN): CN=IPSEC,CN=Windows,CN=Microsoft,CN=Machine,CN={GPOGUID}, CN=Policies,CN=System,DC=domain,DC=Woodgrove,DC=com The LDAP DN of the assigned IPsec policy is stored in the GPO attribute ipsecOwnersReference. When Group Policy retrieves the list of GPOs that apply to the computer, the GPOs that contain IPsec policy assignments are stored in the registry under the GUID for the IPsec client side extension at the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ Group Policy\History\{e437bc1c-aa7d-11d2-a382-00c04f991e27} The IPsec CSE is activated by the security policy CSE whenever an IPsec policy assignment exists in a GPO. If there are problems processing security policy, then there may also be problems processing IPsec policy. To locate the GUID for each Group Policy extension, look under the following location in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ WinLogon\GPExtensions IPsec deployment-related GUIDs for Group Policy CSEs are as follows: •
Security. {827D319E-6EAC-11D2-A4EA-00C04F79F83A}
•
IP Security. {E437BC1C-AA7D-11D2-A382-00C04F991E27}
•
Scripts. {42B5FAAE-6536-11D2-AE5A-0000F87571E3}
The IPsec CSE copies the LDAP DN and related information about the assigned IPsec policy in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\GPTIPSECPolicy If multiple GPOs contain IPsec policy assignments, then the IPsec CSE is called for each GPO. GPO precedence rules apply to the order in which the IPsec CSE receives the GPOs to process. The order may also be affected by settings in the GPOs themselves and by Read ACLs that prevent some assigned GPOs from being retrieved. Each time the IPsec CSE is called, the IPsec-related information in the GPO (including the DN) is
Chapter 7: Troubleshooting IPsec
187
overwritten to this registry key. When all GPOs have been processed, the CSE signals the IPsec service that a domain-based IPsec policy is assigned. The IPsec service then reads the GPTIPsecPolicy\DSIPSECPolicyPath value to retrieve the proper IPsec policy. The IPsec service continues to poll for changes in the assigned IPsec policy based on last update time of any of the assigned IPsec policy directory objects. The service maintains the cached IPsec policy as the latest domain policy. A known issue exists that allows the name of the assigned IPsec policy to become out of sync with the name of the IPsec policy that is actually in use (and which is cached). The IPsec service does not update the information in the GPTIPsecPolicy registry key, such as DSIPSECPolicyName, and the name of the IPsec policy only changes when the IPsec CSE is called. However, the IPsec CSE is not called unless there is a change in the IPsec policy assignment DN attribute in the GPO. This registry value is used by the IPsec Monitor MMC snap-in and the command-line tools to report the name of the currently assigned IPsec policy. Therefore, IPsec tools may report an IPsec policy name that was last processed by the CSE, not the one that is in current use. There are several workarounds for this bug; for more information see the "Policy Versioning" section in Chapter 5, "Creating Isolation Policies for Isolation Groups," in this guide. Note Microsoft recommends that IPsec policy naming conventions include a version number in the name, so that the currently applied version of the policy can be easily found. It is not otherwise possible to easily detect version changes if the policy name remains the same.
If the proper IPsec policy is not assigned, even after a forced refresh of Group Policy, Application Log errors from sources Userenv or SceCli will indicate Group Policy processing problems. Group Policy logging must be enabled to investigate this issue in more detail. There are many different types of Group Policy logs and logging levels. Logs for the Security CSE are necessary to see any errors processing security policy, as well as any errors reported by the IPsec CSE. There is no log specifically for the IPsec CSE. Network monitor traces may be needed to capture traffic at the time of the Group Policy refresh to confirm which domain controller IP address is being used for the retrieval of each object. Problems may include: •
Replication problems or delays that lead to objects not being found.
•
The load balancing logic of the domain controller locator may cause a GPO to be retrieved from one domain controller while the LDAP query for the assigned IPsec policy is retrieved from a different domain controller in the same site.
To create a detailed log file for the Security CSE, use the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ CurrentVersion\Winlogon\GpExtensions\{827d319e-6eac-11d2-a4ea00c04f79f83a}\ Set the ExtensionDebugLevel entry to a REG_DWORD value of 0x2. The log file will be created at %windir%\Security\Logs\Winlogon.log. Note An invalid DNS entry can mean that Group Policies are not downloaded from Active Directory, even though computer and user logon are successful. For more information on DNS problems, refer to the earlier "Name Resolution Problems" section.
Troubleshooting the IPsec Service The IPsec service does not need to be running to use the IPsec Policy Management MMC snap-in. However, if an administrator then assigns a local policy, the Policy Assigned column will display an error.
188
Server and Domain Isolation Using IPsec and Group Policy
The following common problems can cause the IPsec service to fail during startup: •
The computer was started in Safe Mode or Active Directory Recovery Mode. In these cases, the IPsec driver will provide stateful outbound communication by default if there is an IPsec policy assigned. Inbound connectivity will be blocked unless there is a bootexemption configured.
•
IKE cannot obtain exclusive control of UDP port 500 and port 4500. Use netstat –bov to show the processes and code modules for each port. The command portqry –local –v provides even greater detail. Some Winsock Layered Service Providers (LSP) may be installed that are interfering with IPsec. For more information about LSPs and IPsec, refer to the "Troubleshooting Application Related Issues" section later in this chapter.
•
IPsec Policy corruption. The assigned IPsec policy cannot be read entirely or applied entirely, which causes the IPsec service to report a number of errors. These errors do not cause the service itself to fail, but may cause communications to fail in many ways, such as by blocking Group Policy and the IPsec service from retrieving corrected policies. In Windows XP and Windows Server 2003, attention should be paid to the design of persistent policy or local policy as a "safe" policy to be applied in case of errors that occur when domain-based policy is applied. Both persistent policy and computer startup policy (bootmode exemptions) should be part of the troubleshooting investigation. These policies should permit remote access to the computer by other means in case they are the only policies applied because of to other failure conditions.
The Windows 2000 IPsec implementation uses a module called the IPsec Policy Store (polstore.dll) so that the IPsec Policy Agent and the IPsec Policy Management MMC snap-in can use one module to access all three supported policy storage locations: local, remote computer, and Active Directory. This design is changed and improved in Windows XP and Windows Server 2003 with the addition of new IPsec policy types (startup policy and persistent policy) and the Security Policy Database (SPD) component, which maintains the run-time state of IPsec policy for IPsec monitor queries and IKE queries. This architectural change means that the text of logged IPsec events in Windows 2000 has changed in Windows XP and Windows Server 2003. This architectural change also means that significant changes had to be made in the RPC interfaces that are used for remote management. For Windows Server 2003, the RPC interfaces were again significantly updated. Consequently, the IPsec Policy Management MMC snap-in is not able to connect to remote computers that do not have the same operating system version installed. In addition, the security model for Windows XP SP2 and Windows Server 2003 SP1 was fundamentally changed to limit remote RPC connections and to activate Windows Firewall by default. For more information, see Changes to Functionality in Microsoft Windows XP Service Pack 2 - Part 2: Network Protection Technologies. Because of these changes, the remote RPC interfaces for the IPsec service were disabled as a safety measure. Therefore the IPsec Monitor and IPsec Policy Management MMC snap-ins are not able to perform remote monitoring on these computers. Remote management for IPsec should be performed using Remote Desktop (Terminal Server) connections, which execute the IPsec MMC snap-ins as local processes. In Windows 2000, the IPsec driver is loaded by default at the end of the startup process by the Policy Agent service. The IPsec driver is not part of IP packet processing until the first time the Policy Agent informs the IPsec driver of an active policy. If there is no active IPsec policy, the IPsec driver is not included in inbound and outbound IP traffic processing. In Windows XP and Windows Server 2003, this design was improved so that the IPsec driver is loaded by the TCP/IP driver during the startup process. The driver does not process packets until it has filters loaded by the IPsec service.
Chapter 7: Troubleshooting IPsec
189
In Windows 2000, errors may be logged by the IPsec Policy Agent for problems with service startup. These errors include the following: •
IP Security Policy Agent could not be started. No IP Security policy will be enforced. This error is probably caused by problems the IPsec Policy Agent encountered when registering itself with the RPC subsystem. It may also be caused by IKE failing to initialize because of third-party Winsock LSPs.
•
Policy Agent RPC Server failed to… •
register protocol sequence
•
register interface
•
register interface bindings
•
register interface endpoint
•
register authentication mechanisms
•
listen
Any of these errors can be caused by changes to advanced security settings or problems within the RPC service that cause the IPsec Policy Agent service to not properly initialize during service startup. Therefore, the IPsec Policy Agent will not function correctly, may hang, and may shut down. •
Policy Agent failed to start. Failed to connect to SCM Database Error: . The IPsec service cannot open the service control manager database, which may occur because the IPsec service was configured to run as a nonprivileged service account. It must run as local system. Otherwise, investigate problems with the service control manager.
•
Policy Agent failed to connect to the IPSEC Driver. The IPsec driver could not be successfully loaded and interfaced with the TCP/IP stack. Windows 2000 is designed to do this when the IPsec service starts. There may be third-party software inhibiting the connection, or the operating system may be missing code modules that are required for this functionality.
•
Policy Agent failed to load IPSEC policies. An error occurred while the IPsec Policy Agent was loading all the filters into the IPsec driver. This error may have been caused by insufficient kernel memory or improper initialization of the IPsec driver. If the problem persists, contact Microsoft Product Support Services.
•
Policy Agent failed to start ISAKMP service. This error usually occurs because IKE cannot gain exclusive control over UDP port 500 or port 4500 because another service is already using them. It may also be caused by third-party security software preventing the network port allocation, or the IPsec service not running in the local system context.
•
Failed to determine SSPI principal name for ISAKMP/Oakley service. Windows 2000 logs this message when the security support provider interface (SSPI) function call QueryCredentialsAttributes fails. This failure may indicate that the computer is not able to successfully log in to the domain.
•
Failed to obtain Kerberos server credentials for ISAKMP/Oakley service. This Windows 2000 error message commonly occurs when the IPsec service starts (perhaps at computer startup time) on a remote network where an IPsec policy is assigned (perhaps from registry cache of domain policy) that requires Kerberos authentication and a domain controller is not available. Therefore, Kerberos authentication will not function. On the internal network, this event would be logged on a computer that is not a member of the domain, or that cannot reach the domain controllers using the Kerberos protocol during IPsec service initialization.
190
•
Server and Domain Isolation Using IPsec and Group Policy
A Secure communications policy cannot be enforced because the IP Security driver failed to start. Contact your system administrator immediately. This error is caused by a problem with the IPsec driver loading, binding to the TCP/IP stack, or initializing before attempting to add policy to it. File corruption or permissions may be the cause. Look for security settings or third-party security software that may inhibit driver loading. If FIPS.sys internal signatures cannot be verified during initialization, it will fail to load and the IPsec driver will also fail to load. FIPS.sys signature failure requires a replacement of the original signed binary file or a new binary file from Microsoft. Restart the computer. If problems persist, then contact Microsoft Product Support Services.
In Windows XP and Windows Server 2003, the following IPsec service error events indicate that the service cannot start: •
IPSec Services failed to initialize IPSec driver with error code: . IPSec Services could not be started. The IPsec driver was unable to load for some reason. If problems persist, contact Microsoft Product Support Services.
•
IPSec Services failed to initialize IKE module with error code: . IPSec Services could not be started. Common sources of this problem are third-party Winsock LSPs, which prevent IKE from using certain socket options. This error will also be reported when IKE cannot gain exclusive control of UDP ports 500 and 4500.
•
IPSec Services failed to initialize RPC server with error code: . IPSec Services could not be started. The IPsec service depends upon the RPC subsystem for interprocess communication between IKE, the SPD, and the Policy Agent. Use RPC troubleshooting techniques to confirm that RPC is working properly. After restarting the computer, if problems persist, contact Microsoft Product Support Services.
•
IPSec Services has experienced a critical failure and has shut down with error code: . Stopped IPSec Services can be a potential security hazard to the machine. Please contact your machine administrator to re-start the service. The IPsec service encountered the error indicated by the in the event text and is no longer running. The IPsec driver is still loaded and may either be in normal mode (enforcing IPsec policy filters) or in block mode. A separate event would indicate if the IPsec driver was put into block mode. If the driver is in normal mode, then permit and block filter actions still function as expected. Filters with a negotiate action simply drop traffic because IKE is not available.
•
IPSec Services put IPSec driver in block mode due to previous failures error code . This message is a notification that the IPsec driver was put into block mode as a failsafe behavior because of errors encountered processing IPsec policy. This behavior is available only in Windows Server 2003. Block mode still allows inbound exemptions that were configured by using the netsh ipsec command.
Troubleshooting the Retrieval of IPsec Policy The IPsec service uses an authenticated and encrypted TCP LDAP query to download the assigned IPsec policy for all platforms. There are options for LDAP signing and sealing using the Kerberos session key. Therefore, the IPsec service running as Local System must be able to obtain a Kerberos service ticket for the LDAP service on the Active Directory server. If the proper IPsec policy assigned is confirmed to be stored by the IPsec CSE under the GPTIPsecPolicy registry key and the service is running, then the following issues may cause the IPsec service to be unable to retrieve the policy from Active Directory: •
Problems with communication to domain controllers.
•
Problems with computer account logon to a domain controller.
•
Problems with issuing Kerberos tickets.
Chapter 7: Troubleshooting IPsec
191
•
Problems with availability of the LDAP service.
•
Problems finding the particular IPsec policy or component objects requested in the LDAP query.
•
Problems with read permissions for any of the requested IPsec policy objects.
•
Policy corruption because of problems when saving objects to the store or because of accidental or intentional deletion of objects in the store.
Note An IPsec policy that was created in Windows XP or Windows Server 2003 and uses new features that were made available in those releases may have those features silently removed if the policy is later edited and saved by the Windows 2000 IPsec Policy Management MMC snap-in. However, if a Windows 2000 system retrieves an IPsec policy with additional features it will simply ignore them, which may or may not change the behavior of the IPsec policy when enforced on the Windows 2000 system.
A known issue with the IPsec Policy Management MMC snap-in occurs when managing IPsec policy in Active Directory or on a remote computer. If the MMC snap-in is run over a slow link, it may take some time to save all changes in a large policy. If the MMC snapin window is closed, any IPsec policy objects or changes that are not yet saved are lost. This functionality could cause an IPsec policy to become corrupted. If the IPsec Policy Management MMC snap-in is run over a slow link, use a Remote Desktop session to execute the snap-in as a local process. Generally, any command-line tool script that creates IPsec policy should be tested. To do so, create policy in the local store and view it with the IPsec Policy Management MMC snap-in to verify its integrity. Test computers should apply local IPsec policy and examine the details in the IPsec Monitor MMC snap-in to confirm expected filter ordering. Procedures to troubleshoot and fix IPsec policy read errors and corruption depend on the storage location. This solution uses only domain-based IPsec policy, but other types of IPsec policy may have been configured in ways that cause problems. Troubleshooting procedures for each type of policy are reviewed in the rest of this section. Generally, Tier 2 support should be able to use either command-line or GUI tools to confirm that the correct IPsec policy is being retrieved and that the policy is being correctly interpreted. Steps to delete each type of policy are shown here with the expectation that a policy refresh will cleanly install a correct policy. If a proper policy does not appear to be retrieved or installed from scripts, then the problem is escalated to Tier 3 support.
Startup IPsec Policy The Netsh utility allows the configuration of the bootmode and bootexemptions options that are supported by Windows Server 2003 only. The configuration is stored in the following registry keys with default values shown: •
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\ OperationMode=3 (Stateful)
•
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\ BootExemptList = (exemption for inbound DHCP, see below)
The default OperationMode value requires the IPsec driver to perform stateful filtering of outbound traffic. If the IPsec service is running, use the Netsh ipsec dynamic show config command to display the startup configuration. If the IPsec service is not running (for example, when started in Safe Mode), registry tools can be used to examine and change the registry key value.
192
Server and Domain Isolation Using IPsec and Group Policy
To troubleshoot traffic problems that are potentially caused by IPsec stateful filtering during startup, set the IPsec driver to permit traffic at startup instead of performing stateful filtering. If the IPsec service is running, then use netsh ipsec dynamic set config bootmode value=permit to set the startup mode to permit. If the IPsec service is not running, use a registry tool to change OperationsMode=1 for permit. Alternately, the IPsec driver does not apply the startup security mode if the IPsec service is configured for manual start or if it is disabled. After the service is configured for manual start or is disabled, restart the computer for the IPsec driver to load in permit mode.
Persistent IPsec Policy Persistent policy is supported by Windows XP and Windows Server 2003. One common error situation occurs when an existing persistent policy is not deleted before a new persistent policy is defined, and the new policy conflicts with other settings that are already assigned. The solution described in this guide does not use persistent policy. However, because it may be used in some environments troubleshooting instructions are provided in this chapter. The persistent policy registry key exists by default and is empty: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Persistent In Windows XP, the best way to detect persistent policy is to see that this registry key is not empty. The ipseccmd show command reports active policy that is contained in the IPsec service and does not report that a particular setting originated from persistent policy. The IPsec service discards names for the persistent policy rules when interpreting the policy into the active settings. Because ipseccmd does not provide names for filters and filter actions, naming conventions cannot be used to indicate filters and filter actions that originated from persistent policy. Filters have "text2pol{GUID}" style names whenever they are created by ipsecpol.exe or ipseccmd.exe, which will include entries from persistent policy. However, local or domain policies that were created using scripts may also have these names. Persistent policy is applied first and merges with local or domain IPsec policy. Therefore, both local and domain policy must be unapplied before only the persistent settings can be viewed. Use ipseccmd show all to show all active policy, including any persistent settings, when the IPsec service is started. To delete all of the objects (rules, filter lists, and filter actions) that are associated with a particular persistent policy, specify the persistent policy name in the following command: ipseccmd.exe -w PERS -p "policy name" –o The easiest way to ensure that all persistent policy is removed is to delete all subkeys under the Persistent key. However, if you delete the Persistent key itself, future ipseccmd commands will fail when attempting to create persistent policy. To resolve corruption in persistent policy and policy conflicts, delete all objects in the persistent policy store and execute the ipseccmd script again to create it. In Windows Server 2003, the persistent policy has full management capabilities that are similar to local and domain IPsec policy. The persistent policy is stored at the same registry location referenced earlier. The following Netsh command script will display the configured persistent policy by using the commands in the show_persistent.netsh file: Netsh –f show_persistent.netsh
Chapter 7: Troubleshooting IPsec
193
The show_persistent.netsh file is a text file that contains the following lines: Pushd ipsec static Set store persistent show all exit The following Netsh command script can be used to delete all persistent policy: pushd ipsec static set store persistent delete all exit
Local IPsec Policy Local IPsec policy is supported by Windows 2000, Windows XP, and Windows Server 2003 and is stored under the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Local If a local policy is assigned, the assigned policy will be stored in the key as follows: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Local\ActivePolicy If domain policy is not assigned, then the assigned local policy will be added to any configured persistent policy to become the active policy. For significantly easier troubleshooting, IPsec policies that are created by ipsecpol or ipseccmd scripts should be edited by the IPsec Policy Management MMC snap-in to define filter names for each filter before they are used in production environments. Alternatively, the netsh ipsec command can be used to create the policy on a Windows Server 2003-based computer and then exported to a file that can be imported on Windows 2000 and Windows XPbased computers or imported into a domain after the policy has been tested. In Windows 2000, use the netdiag /test:ipsec /debug command to view assignment and active policy details. The IPsec Policy Management MMC snap-in or registry tools should be used to delete IPsec policy objects in the local store. To force a reload of the assigned IPsec policy, stop and restart the service. In Windows XP, use the ipseccmd show gpo or the netdiag /test:ipsec command to view the assignment and active policy details. Use the IPsec Policy Management MMC snap-in, registry tools, or the ipseccmd.exe -w REG -p "" –o command to delete the named IPsec policy. To easily remove all local policy, delete all subkeys to the previously referenced storage location. To force the IPsec service to reload the policy, stop and restart the IPsec service or unassign and reassign the IPsec policy using the IPsec Policy Management MMC snapin. It is also possible to use the sc policyagent control 130 command to reload policy. When policy is reloaded, all IPsec and IKE SAs are deleted, which may cause connectivity delays or interruptions with computers that were actively using IPsec SAs to transmit and receive traffic. In Windows Server 2003, use the netsh ipsec static show gpoassignedpolicy command, the IPsec Policy Management MMC snap-in, or the IPsec Monitor Active Policy node to display the currently assigned local policy.
194
Server and Domain Isolation Using IPsec and Group Policy
Use the netsh ipsec dynamic show all command to see the current active policy configuration. Alternatively, IPsec Monitor can be used to inspect different parts of the active policy. To delete and reload the local policy on Windows Server 2003, use the same commands that were listed for Windows XP. The netsh ipsec command can be used to unassign, reassign, and delete policy.
Active Directory IPsec Policy This policy is supported by Windows 2000, Windows XP, and Windows Server 2003. The assigned domain IPsec policy is stored in the local registry at the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\GPTIPSECPolicy The local registry cache of the domain policy is stored at: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Cache The directory store should be managed by the IPsec Policy Management MMC snap-in or the netsh ipsec command running as local processes against Active Directory. No available tool exists that will allow you to directly view the contents of the cache. A registry tool should be used to determine whether the cache exists and contains the proper contents. Similarly, registry tools are used to delete the domain policy by deleting the GPTIPsecPolicy and Cache registry keys. Then either the IPsec service must be restarted or the service control command used to force an IPsec policy reload without the domain policy. To refresh the domain-based IPsec policy assignment and reload the IPsec policy and update the cache contents, use gpudpate /force. To temporarily block domain policy from applying to the local computer, you can configure the permissions on both the GPTIPsecPolicy and Cache registry keys to deny read access to the local system account. The IPsec Security Monitor MMC snap-in and command-line tools will still show the domain policy as assigned because these tools read the GPTIPsecPolicy information that runs in the context of the local administrator user. For longer term blocking of domain-based IPsec policy, the computer should be prevented from reading the appropriate GPO in Active Directory. In Windows 2000, the following errors may be seen when there are problems with the policy: •
Failed to bind to Directory schema. The IPsec Policy Agent service could not perform an authenticated LDAP bind to the Active Directory IP Security Policies container. This error is probably caused by the computer account failing to login successfully and receive Kerberos credentials. It may also be caused by a failure of the Kerberos protocol to issue the LDAP service ticket to the IPsec Policy Agent service.
•
Failed to bind to IPSEC Policy Storage object. An object was defined in the IPsec policy (such as a rule or filter list) that currently does not exist. The IPsec policy may have become corrupt, the Active Directory storage policy may have become corrupt, or the object was deleted (although existing IPsec policies still reference the object). Examine the IPsec policy by using the IPsec Policy Management MMC snap-in to see if all of the policy rules appear intact and if the Key Exchange properties (on the General tab) can be viewed properly.
•
Failed to locate Domain Controller. Make sure the computer is a member of the domain and check network connectivity. The IPsec policy storage module could not find an LDAP directory from which to retrieve domain-based IPsec policy.
Chapter 7: Troubleshooting IPsec
195
•
Failed to communicate with Directory Service on the Domain Controller. Please contact your System Administrator. The IPsec storage module was not successful in using LDAP signing and sealing to download the assigned IPsec policy.
•
Failed to locate Object in storage. This error is usually serious, because the IPsec policy cannot be completely retrieved and therefore will not properly function. The IPsec Policy Storage module could not find the GUID for the object (rule, filter list, filter action, or ISAKMP settings) that is contained in the IPsec policy or one of the rules, either by using an LDAP call or a remote registry call. This error may be caused by any of the following: •
Replication delays in which the referencing object arrives before the referenced object or if the queries become targeted at two different domain controllers.
•
The object may have been deleted while it was still being used in the IPsec policy.
•
The object may have permissions that deny the ability to enumerate it or read it, or the IPsec policy storage was restored to an earlier time when the object did not exist.
•
IPsec policy corruption may cause an invalid GUID in the query.
•
Network connectivity may not be available to the destination IP address.
•
The LDAP or remote registry service may not be available.
•
Cannot complete requested operation. Policy Storage is not Open. The Active Directory, remote computer, or local computer store cannot be opened. This error is usually caused by a permission or authentication failure.
•
Using the Active Local Registry policy, as (i) there's no Active Directory Storage policy or (ii) the Active Directory Storage policy couldn't be applied successfully and there's no Cached policy. This event identifies that IPsec policy is locally defined on the computer and that domain-based policy could not be applied to override it.
•
Not using any IPsec policy, as (i) there's no Active Directory Storage or Active Local Registry policy or (ii) the Active Directory Storage policy couldn't be applied successfully and there's no Cached policy or no Active Local Registry policy. This event identifies the default state, in which no policy is assigned to the computer.
In Windows XP and Windows Server 2003, the following events indicate that the IPsec service was unable to retrieve a particular policy type. If a local policy cannot be successfully read in Windows Server 2003 and Windows XP SP2, the policy is ignored and the next assigned policy in the order of persistence is read. •
PAStore Engine failed to load persistent storage IPSec policy on the machine for "" with error code . The IPsec service detected that persistent policy was assigned and stored in the local registry, but failed to read the contents of at least one of the persistent policy objects. Check permissions on all registry keys. The policy may have become corrupt. Try deleting all persistent policy and then recreating it.
•
PAStore Engine failed to load local storage IPSec policy on the machine for "" with error code . The IPsec service detected that a local policy was assigned and attempted to read the policy, but that a failure occurred when reading at least one of the objects associated with the assigned policy. Check permissions on all registry keys. The policy may have become corrupt and should be deleted and recreated.
196
Server and Domain Isolation Using IPsec and Group Policy
•
PAStore Engine failed to load directory storage IPSec policy on the machine for "" with error code . The IPsec service encountered at least one error when reading the assigned IPsec policy from Active Directory. This error may have been caused by a lapse in network connectivity before all policy objects were retrieved, or it may have been caused by missing IPsec policy objects or objects to which read permission is not granted.
•
PAStore Engine polled for changes to the Active Directory IPSec policy, detected that Active Directory is not reachable and migrated to using the cached copy of the Active Directory IPSec policy. Any changes made to the Active Directory IPSec policy since the last poll could not be applied. This message simply indicates that at a regular polling interval the IPsec service did not successfully contact Active Directory (for example, because of loss of DNS service) and that no changes in the current active IPsec policy were made. Connectivity to Active Directory was originally available when the active policy was applied, and the IPsec service will have retrieved and stored the latest version in the cache. Therefore, the IPsec service now considers the registry cache of the IPsec domain policy to be the primary source of policy. Polling will continue to try to reach the directory.
Troubleshooting the Interpretation of IPsec Policy The interpretation of IPsec policy is performed after the complete policy is successfully retrieved from the appropriate storage location. The current network interface IP addresses are used to expand the policy's generic filters into specific filters. Then the list of inbound and outbound specific filters is loaded into the IPsec driver for packet processing. Interface change events are signaled to the IPsec service, which adjusts the IPsec filter configuration in the IPsec driver as quickly as possible if necessary (for example, for My IP Address filters). In Windows 2000, the following messages may indicate a problem with proper interpretation or configuration of the IPsec components to enforce the policy: •
Data Type attribute specifies unrecognized data format. Part of the IPsec policy contains a data format that the policy storage engine does not recognize. This error is an indication of policy corruption or it may indicate a policy version problem at some point in the future. IPsec policy features in Windows XP and Windows Server 2003 are designed to be transparent to the Windows 2000 IPsec Policy Agent.
•
Failed to read data from blob. The data format of the IPsecData attribute in an IPsec policy object is not what it expected. This error almost always indicates a policy corruption or version problem. It must be corrected before all IPsec policy settings are successfully applied as intended.
•
Policy Agent has not interface list. The IPsec Policy Agent did not find any IP network interfaces to filter. Note that the error in the text of this message comes from the Windows source code directly and will appear as shown here.
•
IP Public Help API failed to get the Interface Table. Filters based on Interfaces will not be expanded and plumbed to the IPsec Driver. An error occurred when the IPsec Policy Agent tried to enumerate the list of interfaces on the computer. There may be no network interfaces or an internal error within the network interface manager. Devices that are not fully PnP compliant, file corruption, or problems within the NIC driver or with other related Windows networking components may be the cause. IPsec filters based on interface type, such as those configured in a rule for a particular connection type (remote access, for example) rather than for all connections. If the problem persists after a restart, contact Microsoft Product Support Services.
Chapter 7: Troubleshooting IPsec
197
•
IP Public Help API failed to get the IP Address Table. Filters based on Interfaces will not be expanded and plumbed to the Ipsec Driver. An error occurred when the IPsec Policy Agent tried to enumerate all IP addresses on the computer by using a function call in the IP Helper API. There may be no IP addresses configured, or there may be problems similar to the above.
•
IP address entry index not found in the Interface Table. Discarding the IP address. The IPsec Policy Agent confirms that all IP addresses appear in the network interface list. Transient conditions when a new network interface is added or removed can cause this problem. The message indicates that the IPsec service will not create specific filters for this discarded IP address for generic My IP Address filters in policy, which may in turn appear as temporary unexpected connectivity behavior when using this IP address. Otherwise, this error indicates a problem in the internal state of the IP interface configuration, which Microsoft Product Support Services would need to investigate further. Because the IP address is discarded by the IPsec Policy Agent (not by the TCP/IP stack), no IPsec filters will be created for that IP address. Therefore no security actions (such as permit or block) and no negotiation of IPsec SAs will be performed for traffic using this IP address.
•
Matching filter mirror exists in filter list. This error indicates a duplicate filter condition in the IPsec policy. The IPsec policy design should be analyzed to ensure the quick mode specific filters for inbound and outbound directions are not duplicated.
•
No filters were added to the main filter list. The IPsec Policy Agent found no filters in the IPsec policy that was retrieved from storage. The IPsec policy may only contain the default response rule, or errors were encountered when the rules or filter lists were read.
•
Zero Phase 1 offers. Discarding the ISAKMP policy. The IPsec policy is probably corrupt if no IKE main mode security methods (ISAKMP policy objects) are found.
•
Zero Phase 2 offers. Discarding the Negotiation policy. With no filter action security methods (IKE quick mode Phase 2 offers), IKE will fail in quick mode negotiations for traffic that matches the corresponding filters. The IPsec policy is probably corrupt.
•
Policy contains no valid offers. The IPsec policy contains no valid security methods in the filter action of a rule, or it does not contain settings for IKE main mode (Key Exchange settings configured from the General tab).
•
Policy Agent attempted to insert an existing filter into IPsec. The IPsec driver detects that there is a duplicate filter and rejects the duplicate. This situation might be benign if the duplicate filter has the same action as the one already processed into the IPsec driver. However, if the filter actions are different, this is an unsupported IPsec policy design. Results after an elapsed period of time may differ, and depend on the order in which the policy change is processed. The IPsec policy should be designed to avoid duplicate filters.
•
Could not add an entry to the IPSEC Policy table. A new filter could not be added to the IPsec driver by the IPsec Policy Agent. This error means that any traffic that would match that filter will not be secured. A low kernel memory condition might cause this error. If the error persists, contact Microsoft Product Support Services.
•
Policy Agent failed to insert or update a filter in IPsec. Like the previous message about inserting a filter, the list of filters in the IPsec driver is not what the assigned IPsec policy requires. Therefore, security is not being provided as intended.
198
•
Server and Domain Isolation Using IPsec and Group Policy
Using Cached policy, as Active Directory Storage policy couldn't be applied successfully (network unreachable, policy integrity invalid, etc.). When a domain-based IPsec policy is assigned, the IPsec Policy Agent attempts to read the latest policy from the Active Directory first. This message reports that it was unable to retrieve the IPsec policy from the directory and is applying policy from the last domain policy, which is cached in the registry.
In Windows Server 2003, the following events indicate that a problem may have occurred interpreting IPsec policy. In most cases, Windows XP uses the same event text. These issues must be resolved for the IPsec policy to function properly. •
PAStore Engine failed to apply persistent storage IPsec policy on the machine for "" with error code: . The IPsec service found persistent policy configured in the registry, but could not apply all of it successfully. Any persistent policy that had been already applied is removed, and the IPsec driver will be set programmatically to block mode (with boottime exemptions) as indicated by a separate message.
•
PAStore Engine failed to apply local registry storage IPsec policy on the machine for "" with error code . This message indicates that the service encountered at least one error in applying local IPsec policy from the local registry. This message could indicate that the policy is corrupt or that permissions were incorrect.
•
PAStore Engine failed to apply Active Directory storage IPsec policy on the machine for DN "
