Server and Domain Isolation Using IPsec and Group Policy
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.
Chapter 1: Introduction to Server and Domain Isolation. 1
Chapter 1: Introduction to Server and Domain Isolation. 7
Chapter 2: Understanding Server and Domain Isolation. 7
Chapter 3: Determining the Current State of Your IT Infrastructure. 7
Chapter 4: Designing and Planning Isolation Groups. 8
Chapter 5: Creating IPsec Policies for Isolation Groups. 8
Chapter 6: Managing a Server and Domain Isolation Environment 8
Chapter 7: Troubleshooting IPsec. 8
System and Management Architecture Overview.. 11
Chapter 2: Understanding Server and Domain Isolation. 15
Organizational Prerequisites. 16
Who Should Read This Chapter 16
Ensuring Regulatory Compliance. 17
Business Risk Assessments of IT Infrastructure. 19
Invest in Long-Term Directions for Information Security. 20
Identifying Trusted Computers. 20
Goals Directly Achievable Using Server and Domain Isolation. 22
Risks Addressed Using Server and Domain Isolation. 23
How Does Server and Domain Isolation Fit into My Overall Network Security Strategy?. 24
Comparison of SSL/TLS and IPsec. 26
How Can Server and Domain Isolation Be Achieved?. 30
Server and Domain Isolation Components. 31
What Does Server and Domain Isolation Protect Us From?. 39
Modeling and Categorizing Threats. 39
How Can We Deploy Server and Domain Isolation?. 40
IPsec Deployment Process Overview.. 41
Chapter 3: Determining the Current State of Your IT Infrastructure. 43
Organizational Prerequisites. 44
IT Infrastructure Prerequisites. 44
Who Should Read This Chapter 44
Active Directory Information. 58
Capturing Upgrade Costs for Current Hosts. 64
Chapter 4: Designing and Planning Isolation Groups. 69
Organizational Prerequisites. 70
IT Infrastructure Prerequisites. 70
Creating the Server and Domain Isolation Design. 70
Modeling Foundational Groups. 71
Planning the Computer and Network Access Groups. 75
Creating Additional Isolation Groups. 77
Gathering Network Traffic Requirements. 79
Assigning Computer Group and Network Access Group Memberships. 83
Group Implementation Methods. 86
Group Implementation for Woodgrove Bank. 89
Chapter 5: Creating IPsec Policies for Isolation Groups. 93
Organizational Prerequisites. 94
IT Infrastructure Prerequisites. 94
IPsec Policy Component Overview.. 97
How to Apply IPsec Policies to Individual Computers. 119
How to Apply IPsec Policies Using GPOs. 120
IPsec and Windows Firewall 130
IPsec and Internet Connection Firewall (ICF) 130
Chapter 6: Managing a Server and Domain Isolation Environment. 133
IPsec Policy Change Procedures. 137
Changing an Existing IPsec Policy in the Domain. 138
Moving Hosts Between Isolation Groups. 142
Adding or Removing Hosts and Users in Existing Groups. 142
Adding New Network Access Groups. 144
Disabling IPsec in an Isolation Group. 147
Re-Enabling IPsec in an Isolation Group. 147
Removing IPsec from an Isolation group. 148
Backup/Restore Considerations. 148
Mitigation of Network-Based Infections. 149
Isolating the Isolation Domain. 149
Isolation to Within Child Domain Only. 151
Isolation to Predefined Groups. 151
Chapter 7: Troubleshooting IPsec. 153
Support Tiers and Escalation. 153
Troubleshooting Flowcharts. 156
Prevention of Social Engineering Attacks. 160
Tier 2 Troubleshooting Preparation. 162
Issues Inherent with the Use of IPsec. 163
The Troubleshooting Toolkit 166
The IPsec Troubleshooting Process. 171
Warning: Starting and Stopping the IPsec Service. 172
Verifying Network Connectivity. 173
Verifying the Correct IPsec Policy. 185
Troubleshooting Application-Related Issues. 207
Engaging Microsoft Product Support Services. 209
Appendix A: Overview of IPsec Policy Concepts. 213
Understanding IPsec Filtering. 214
IKE Main Mode SAs and IPsec SAs. 218
IPsec Encapsulation Modes and Protocol Wire Formats. 219
IPsec Encapsulation Modes. 219
IPsec Protocol Wire Formats. 219
IKE Authentication Process. 220
IKE Authentication Methods. 221
Kerberos Version 5 Protocol Authentication. 221
Public Key Certificate Authentication. 221
IKE Authentication Methods and Security Method Preference Order 223
Security Negotiation Options. 224
Session Key and Master Key PFS. 225
Appendix B: IPsec Policy Summary. 227
General Policy Configuration. 227
No Fallback Isolation Group Policy. 231
Boundary Isolation Group Policy. 232
Encryption Isolation Group Policy. 233
Appendix C: Lab Build Guide. 235
Organizational Prerequisites. 235
IT Infrastructure Prerequisites. 236
Baseline Implementation Prerequisites. 236
Deployment of the Baseline Policy. 237
Implementing the IPsec Policies. 237
Copying Configuration Scripts. 237
Installing the Group Policy Management Console. 238
Implementing IPsec Filter Lists and Filter Actions. 238
Implementing IPsec Policies. 239
Creating GPOs for IPsec Policies. 239
Setting the Security on the IPsec Group Policies. 240
Adding Domain Computers to the Boundary Group. 244
Adding Infrastructure Servers to the CG_NoIPSec_Computers Group. 244
Linking IPsec Policies and GPOs in a Domain Environment 245
Using the Policy Build-up Method to Enable the Baseline IPsec Policy. 245
Adding Subnets to the Secure Subnets Filter List 246
Verifying the Baseline Deployment 247
Test Tools and Scripts for the Functionality Tests. 248
Verifying IPsec Policy Application. 248
Using IP Security Monitor to Determine SA Type. 250
Enabling Organization Secure Subnets Filter List on Remaining Policies. 250
Enabling Network Access Group Configuration. 251
Implementing Network Access Groups. 251
Verifying Deployment of Network Access Groups. 255
Enabling the Isolation Domain. 256
Implementing the Isolation Domain. 256
Verifying Deployment of the Isolation Domain. 257
Enabling the No Fallback Isolation Group. 258
Implementing the No Fallback Isolation Group. 258
Verifying Deployment of the No Fallback Isolation Group. 259
Enabling the Encryption Isolation Group. 260
Implementing the Encryption Isolation Group. 260
Verifying the Encryption Isolation Group Deployment 261
Enabling the Boundary Isolation Group. 262
Implementing the Boundary Isolation Group. 262
Verifying the Boundary Isolation Group Deployment 262
Configuring the Isolation Domain as the Default Isolation Group. 264
Reordering the IPsec Policy Link Order 264
Final Functional Tests—All Isolation Groups Enabled. 265
Appendix D: IT Threat Categories. 271
Threats Identified by STRIDE. 271
Spoofing Identify Threats. 271
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 secwish@microsoft.com.
We look forward to hearing from you.
Chapter 1: Introduction to Server 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 end-to-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 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.
· 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.
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.
· 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.
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 up-to-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.
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.
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.
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
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
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.
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.
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 Server 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.
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.
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 (e-authentication) 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
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.
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
· 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 re-establish 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.
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).
· 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, anti-replay 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 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.
· 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-detect-react realizes that attacks will occur and understands that detecting them quickly and minimizing service interruptions or loss of data is paramount. Practicing protect-detect-react 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 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 defense-in-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.
· 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, 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).
· 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.
· 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.
· 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.
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.
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) 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 non-encrypted 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.
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.
· 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.
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.
The following flowchart illustrates the complete process from steps 2 and 3:
Figure 2.3 Computer host access permissions-checking process
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 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 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.
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 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-to-date 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.
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.
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 (ESP-Null).
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.
· 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 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.
· 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.
· 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 | 5,000 | Forest root global catalog |
| 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 |
| London, U.K. | europe.corp.woodgrovebank.com | 5,200 | Forest root GC |
| 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, South Africa | europe.corp.woodgrovebank.com | 37 | Europe regional GC |
| Tokyo, Japan | asia.corp.woodgrovebank.com | 500 | Forest root GC |
| 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.
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.
· 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 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\<systemname>_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.
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.
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.
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.
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.
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.
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).
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.
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 Administrator-level 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.
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.
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 required | Details | Projected cost |
| HOST-NYC-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. |
| SERVER-LON-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.
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.
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 network-borne 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 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.
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.
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 IPsec-secured 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
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 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. 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.
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.
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
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.
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
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.
· 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 non-IPsec 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.
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.
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 reqs met? | Software reqs met? | Configuration required | Details | Projected cost | Group |
| HOST-NYC-001 | No | No | Upgrade both hardware and software | Current operating system is Windows NT 4.0. Old hardware not compatible with Windows XP. | $XXX. | ID |
| SERVER-LON-001 | Yes | No | Join Trusted domain, upgrade from NT 4 to Windows 2000 or later | No antivirus software present. | $XXX. | EN |
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 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 | This group is for all users that are authorized to make inbound IPsec-protected connections to the Encryption isolation group computers. |
| ANAG_EncryptedResource | IPS-SQL-DFS-01 IPS-ST-XP-05 | This group contains all computers that are authorized to make inbound IPsec-protected connections to the Encryption isolation group computers. |
| DNAG_EncryptionIG_ | 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.
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
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-IPsec-based computer. The IPsec Encryption policy requires encrypted IPsec to be negotiated at all times.
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 Apply Group Policy | None |
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 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 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."
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.
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.
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 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
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 |
| ICMP, All Traffic | Contains the filter that allows the Internet Control Message Protocol (ICMP) to function within the organization for troubleshooting purposes |
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, dial-up 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.
· 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 host-based 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 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.
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 Any <-> 172.10.1.0/24 | All |
| DNS Exemption List | Any <-> 192.168.1.21 Any <-> 192.168.1.22 | All |
| Domain Controllers Exemption List | Any <-> 192.168.1.21 Any <-> 192.168.1.22 | 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 |
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 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 SHA-1 | Provides both IP payload (data) and IP header (address) integrity and authenticity without encryption. AH cannot traverse devices running NAT. |
| ESP – Integrity | <None> MD5 SHA-1 | 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.. |
| ESP – Encryption | <None> 3DES DES | With DES or 3DES, provides IP payload (data) encryption. Can be used with a null encryption algorithm when encryption is not necessary. |
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.
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.
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.
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 (Accept Inbound, Allow Outbound) | 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. |
| 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, <None> ESP – SHA-1, 3DES |
| IPsec – Secure Request Mode (Ignore Inbound, Allow Outbound) | ESP – SHA-1, <None> ESP – SHA-1, 3DES |
| IPsec – Full Require Mode (Ignore Inbound, Disallow Outbound) | ESP – SHA-1, <None> ESP – SHA-1, 3DES |
| IPsec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) | 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.
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
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 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) 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 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 access-based 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. |
| 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) |
| IPSEC – Boundary Isolation Group IPsec Policy (1.0.041001.1600) | Woodgrove Bank 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 non-domain-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 Directory-based 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 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 re-authenticate 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 <number> 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 <number> 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.
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 Diffie-Hellman 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.
A simple versioning method is to create a version ID based on the following formula:
<Major Change>.<Minor Change>.<Date:yymmdd>.<Time:24 Hour>
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 <DomainName>\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.
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.
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 <scriptfile>
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=<domain> 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 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.
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. |
| 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 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 | No IPsec | Deny Apply Group Policy |
| CG_BoundaryIG_computers | Allow Read and Apply Group Policy | |
| IPSEC – No Fallback Isolation Group Policy | No IPsec | Deny Apply Group Policy |
| CG_NoFallbackIG_computers | Allow Read and Apply Group Policy | |
| IPSEC – Encryption Isolation 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.
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 IPS-ST-XP-05 is added to the ANAG_EncryptedResourceAccess_Computers network access group. The encryption server accounts themselves, IPS-SQL-DFS-01 and IPS-SQL-DFS-02, 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 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 IPS-SQL-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
· 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\NoDefaultExempt 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.
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.
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 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 Server 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.
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
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.
· 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.
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: <domain name>, expand Domains, and then expand <domain name>.
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 <domain name>.
6. In the right pane, right-click <IPsec policy name> and then click Assign.
7. Ensure that <IPsec policy name> 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 snap-in 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 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 <computer name> 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 <computer name> system.
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 <IPsec policy name>, and then click Properties.
4. In the IP Security Rules list, click <rule name>, and then click Edit.
5. On the Filter Action tab, in the Filter Actions list, click <new filter action> 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 <IPsec policy name>, and then click Properties.
4. In the IP Security Rules list, click <rule name>, 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.
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.
To modify an IPsec policy to use a new filter list and filter action
1. Right-click <IPsec policy name> 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.
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 <NAG> 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 <computer name> 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 <computer name> and then click Remove.
c. Click Yes to remove the <computer name> 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.
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 <user name> 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 <user name>, and then click Remove.
c. Click Yes to remove the <user name> 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.
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 <initiator name> 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.
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 <user name> 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 |
| <NAG Implementation Policy Name> | <NAG 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: <domain name>, expand Domains, and then expand <domain name>.
4. Right-click Group Policy Objects, and then click New.
5. In the Name text box, type <GPO name> and then click OK.
6. Right-click <GPO name>, 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: <domain name>, expand Domains, expand <domain name>, and then expand Group Policy Objects.
4. Right-click <GPO name>, 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.
3. Expand Forest: <domain name>, expand Domains, expand <domain name>, and then expand Group Policy Objects.
4. Right-click <GPO name>, 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: <domain name>, expand Domains, and then expand <domain name>.
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 <domain name>.
6. In the right pane, right-click <IPsec policy name>, and then click Un-assign.
7. Ensure that <IPsec policy name> 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.
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 Directory-based 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.
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 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.
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 non-domain-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 <destination name> and nslookup.
· Applications. Some applications work (for example, net view), but others do not when communicating with the same destination.
· 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.
· 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.
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.
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.
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.
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 non-administrative 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.
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.
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.
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.
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.
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 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).
· 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, Diffie-Hellman 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
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.
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 operating systems | How to obtain | Role | More information |
| Ipsecpol.exe | Windows 2000 only | Windows 2000 Resource Kit | Configures IPsec policies in the directory or in a registry | Windows 2000 Resource Kit Tools Help |
| 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 Group Policy was last applied | Windows 2000 Resource Kit Tools Help, Windows XP and Windows Server 2003 Help |
| Resultant Set of Policy (RSoP) MMC | Windows Server 2003, Windows XP | Part of the operating system | View IPsec policy for a computer or for members of a Group Policy container | Windows Server 2003 Help |
| Srvinfo | Windows 2000, Windows Server 2003, Windows XP | Windows 2000 and Windows Server 2003 Resource Kits | Services, device drivers, and protocols information | Windows Server 2003 Resource Kit Tools Help |
| PortQry | Windows 2000, Windows Server 2003, Windows XP | Windows Server 2003 Resource Kit | Network port status reporting | http://support.microsoft.com/kb/310099 |
| NLTest | Windows 2000, Windows Server 2003, Windows XP | Support Tools | Test trust relationships and Netlogon secure channels | Windows Server 2003 Support Tools Help |
| KList | Windows 2000, Windows Server 2003, Windows XP | Windows 2000 and Windows Server 2003 Resource Kits | Kerberos ticket reporting | 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.
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 |
| <CompName>_FileVer.txt | Lists the file versions of various IPsec-related DLLs. |
| <CompName>_gpresult.txt | Output of the gpresult command. |
| <CompName>_ipsec_547_events.txt | Output of any IPSEC 547 errors in the Security event log. |
| <CompName>_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. |
| <CompName>_ipseccmd_show_all.txt | Only on Windows XP. This file captures the output of the ipseccmd command. |
| <CompName>_kerberos_events.txt | Output of any Kerberos events in the System event log. |
| <CompName>_klist_purge_mt.txt | Output from KList while purging machine tickets. |
| <CompName>_lsass.log | Copy of the lsass.log file if present. |
| <CompName>_netdiag.txt | Output from running netdiag. |
| <CompName>_netsh_show_all.txt | Only on Server platforms. Output from the show all command in netsh. |
| <CompName>_netsh_show_gpo.txt | Only on Server platforms. Output from the show gpo command in netsh. |
| <CompName>_oakley.log | Copy of the Oakley.log file, if present. |
| <CompName>_OSInfo.txt | Output of current operating system information. |
| <CompName>_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. |
| <CompName>_userenv.log | Copy of the userenv.log file, if present. |
| <CompName>_<SrvName>_netview.txt | Output of the net view command against <SrvName>. |
| <CompName>_<SrvName>_ping.txt | Output of the ping command against <SrvName>. |
| <CompName>_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 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 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.
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 <domain name> 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
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.
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.
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 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 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 properties of the network connection. The computer may need to be restarted for driver-level 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 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 <number> packet(s) with a bad Security Parameters Index from <ip address>. 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.
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.
· 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 Diffie-Hellman 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 IPsec-secured 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 <number> packet(s) in the clear from <IP address> 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.
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.
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 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-a4ea-00c04f79f83a}\
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.
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.
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: <number>. 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.
· 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: <number>. 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: <number>. 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: <number>. 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: <number>. 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 <number> 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 <number>. 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.
· 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 snap-in 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.
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
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 XP-based 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 "<policy_name>" –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 snap-in. 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.
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.
· 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 "<policyname>" with error code <number>. 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 "<policyname>" with error code <number>. 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.
· PAStore Engine failed to load directory storage IPSec policy on the machine for "<policyname>" with error code <number>. 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.
· 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.
· 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 "<policyname>" with error code: <number>. 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 "<policyname>" with error code <number>. 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 "<CN=ipsecPolicy{GUID}" with error code: <number>. The IPsec service found the domain policy that was specified by the DN in the GPTIPsecPolicy registry key but was not able to apply it. This message is informational, and is often a notification that the domain controller is not reachable for mobile clients; this message should be followed by a successful application of cached policy (if it exists). However, it may indicate that a GPO is delivering an IPsec policy that does not exist, cannot be read, or that the policy is corrupt.
· PAStore Engine failed to apply locally cached copy of Active Directory storage IPSec policy on the machine for "<policyname>" with error code: <number>. This message indicates that the IPsec service knows that domain policy should be assigned, and that it had already failed to apply the policy that was retrieved from Active Directory. Now it has encountered at least one error when applying the cached copy of assigned domain policy from the local registry. This error could indicate that the cache is corrupt or that permissions were incorrect. This condition is serious because none of the domain-based policy could be applied, which will likely affect connectivity with other isolation domain members. Local policy (if defined) would be next in the precedence order.
· PAStore Engine failed to apply some rules of the active IPSec policy "<policyname>" on the machine with error code: <number>. Please run IPSec monitor snap-in to further diagnose the problem. This problem usually occurs in combination with other problems discussed here, such as if there are no quick mode security methods (offers).
· IPSec Services failed to get the complete list of network interfaces on the machine. This can be a potential security hazard to the machine since some of the network interfaces may not get the protection as desired by the applied IPSec filters. Please run IPSec monitor snap-in to further diagnose the problem. This message replaces the several IP Helper API messages that were used in Windows 2000. This is a benign error if it occurs when interfaces are added and removed or when connection states change, such as when a wireless network is no longer in range. It is also benign when it occurs during resumption from standby or hibernate modes and a different network interface configuration exists that is being detected during the resumption.
Policy Configuration Issues with RRAS VPN
As noted in the Tier 1 support section earlier in this chapter, the RRAS service is a common source of IPsec policy conflict in some organizations. This section explains why the built-in IPsec policy for L2TP/IPsec VPN servers creates a conflict with the domain policy used in this solution. This situation is one example of a duplicate filter problem.
In the following discussion, the IPsec policy design used in the Woodgrove Bank scenario is used to illustrate the issues. However, the principles will apply to many enterprise-wide IPsec deployments.
The IPsec policy for L2TP/IPsec servers is automatically generated by the RAS Manager service (RASMAN) and includes the following filters:
· From Any IP Address to My IP Address, UDP, source 1701, dest Any (inbound)
· From My IP Address to Any IP Address, UDP, source Any, destination 1701 (outbound)
Note For more information on this policy, see Knowledge Base article 248750, "Description of the IPSec policy created for L2TP/IPsec".
Consequently, the main mode-specific filter that controls IKE negotiation response to this server is the address part of the inbound filter:
· From Any IP Address to My IP Address -> Certificate authentication
Note that the use of "My IP Address" causes the inbound filter to be expanded for each IP address on the VPN server. Assuming the VPN server has an external interface IP address for Internet connectivity and an internal interface for LAN connectivity, the IKE main mode-specific inbound filters are:
· From Any IP Address to <external interface IP address> -> Certificate authentication
· From Any IP Address to <internal LAN interface IP address> -> Certificate authentication
The second filter, for the internal LAN interface, is more specific than the server and domain isolation IKE main mode inbound filter, which is:
· From Any IP to Subnet -> Kerberos authentication
Consequently, when an administrator uses a trusted client to manage the VPN server, it will initiate IKE to the VPN server's internal IP address. The IKE inbound policy lookup will match the more specific main mode filter and reply with the IKE main mode settings for L2TP. Certificate authentication will be used instead of the Kerberos authentication that was used for this solution.
A second case of conflict can occur if the Internet VPN client uses the quarantine capabilities of the Connection Manager client. The quarantine client must pass a "quarantine key" to the internal LAN IP address of the VPN server to end the quarantine and gain full VPN access to the network. In this scenario, the VPN client's domain IPsec policy is applied from cache when the laptop starts. When the VPN quarantine connection is successfully established, an internal IP address is assigned to the VPN client. The client internal IP address may be covered by one of the subnet filters (Any <-> Internal Subnet) defined in the domain isolation IPsec policy. This filter is required so that VPN clients have IPsec-authenticated access end-to-end through the VPN tunnel to internal servers and any other workstations they may access.
However, the subnet filters in this solution will initiate an IKE negotiation from the internal IP address of the client VPN tunnel virtual interface to the internal LAN interface of the VPN server. IKE main mode will fail because the server will respond to accept only certificate authentication, which is not compatible with the policy used for domain and sever isolation. Even if the policy did allow certificate authentication, the IKE quick mode from the client will propose the filter for all traffic, and the VPN server would fail the negotiation because the proposed filter is too general. The VPN server will only accept quick mode filters that are specific to L2TP: UDP source 1701, destination Any, or UDP source 1701, destination 1701.
The following options can be used to resolve the conflict between RRAS server L2TP/IPsec policy and the isolation policy:
· Include RRAS server internal LAN IP addresses in the exemption list.
· Disable the L2TP ports on the VPN servers. Use only PPTP.
· Disable automatic IPsec policy for L2TP by using the ProhibitIPsec registry key for RASMAN. Manually customize the IPsec policy configuration for L2TP to use only the external IP address for certificate authentication for UDP 1701 traffic, and only Kerberos authentication for all traffic for domain isolation using the internal IP address.
Note For more information about this configuration, see Knowledge Base article 240262, "How to Configure a L2TP/IPSec Connection Using Preshared Key Authentication".
The simplest solution in this list is the first, which exempts the internal NIC of the RRAS server from using IPsec.
Troubleshooting IKE
IKE and IPsec most commonly fail when first deployed because network filtering does not permit UDP 500 or IPsec protocol packets. For this reason, it is helpful to establish a static IP workstation or server for testing that will have a simple policy assigned, such as the predefined example Server (Request) policy that uses a preshared key. Auditing must be enabled to capture IKE audit events. A default domain IPsec policy is deployed to all domain members that authenticates with the same preshared key and contains one rule with one filter for all traffic (including ICMP) to the test computer's IP address.
Then a domain logon script is deployed to perform ping <testserver> or
nbtstat –n <testserver>, which will trigger the IKE negotiation from all domain members to the test server. By analyzing and summarizing the IP addresses in the IKE main mode success audits, you can determine if all computers are receiving policy and verify that all areas of your network can reach the test computer by using IKE and IPsec protocols.
A more advanced test would be to confirm that IPsec encapsulation works with fragmentation to each area of the network by using ping –l 5000 <IP address> from the test server to computers located in each area. The –l 5000 option causes Ping to create a 5000-byte ICMP packet payload. This full IP packet will be encapsulated by the IPsec protocol, then fragmented by the IP layer before being sent on the wire. All fragments must be received at the destination, and a reply that consists of an equal number of fragments is sent back. Experience has shown that devices that are congested or that serve as boundaries between different speed networks (for example, between 1gigabit and 100 megabit Ethernet) may have problems passing fragments. Similarly, hosts that reside on different MTU links (such as Asynchronous Transfer Mode (ATM), Fiber Distributed Data Interface (FDDI), and Token Ring) require ICMP PMTU messages to properly discover the network path MTU for IPsec-protected TCP packets. See Knowledge Base article 314496, "Default MTU Size for Different Network Topology".
Troubleshooting IKE Negotiation
IKE can be difficult to troubleshoot because errors may only occur under certain conditions, such as when IKE quick mode is initiated only from a computer that is typically the responder. Errors can also be caused by failures in the authentication system, such as any Kerberos protocol errors, or when incompatible policy designs or pre-existing policy is merged with domain policy. IKE failures cause the computer that experiences the failure condition to stop participating in the IKE negotiation, and the other computer in the negotiation will usually exhaust its retry limit and time out. If IKE fails, try to study the failure and capture logs without making any changes. Standard auditing can be enabled dynamically without changing the IPsec configuration or the running state of the service. However in Windows 2000, the IPsec service must be restarted to enable detailed IKE logging to the Oakley.log file, in Windows XP SP2 and Windows Server 2003, IKE logging can be enabled and disabled via command line when needed.
In some situations, it may be necessary to stop and restart the IPsec service to study the network traffic and capture Oakley.log file results from a clean state. When the IPsec service is stopped manually or as part of a computer restart or shutdown, IKE attempts to send delete messages to clean up the IPsec SA state on all actively connected peers. Sometimes the operating system disables the ability to send packets before IKE is done sending delete messages to all active peers, which causes IPsec SA state to remain on the peer. When this happens, the peer can believe it is securely connected to the computer that is being restarted. After the restart, if the computer does not initiate a new IKE negotiation to its peer, the peer will have to wait five minutes for the IPsec SAs to time out before attempting to re-establish them. To re-establish SAs, a quick mode negotiation is first attempted for one minute, and then an IKE main mode initiation.
IKE logging has been improved in each release since Windows 2000. The events documented in this section apply to Windows XP and Windows Server 2003, although Windows 2000 events are similar in nature.
The Windows Security Log is the recommended starting point when trying to determine the reason for an IKE negotiation failure. To see IKE events, auditing must be enabled for success or failure in the group security policy setting "Audit Logon Events." After auditing is enabled, the IKE service will make audit entries and provide an explanation for why negotiation failed. However, the explanation for IKE negotiation failures is almost always reported as an Event 547 failure, and there may be several possible causes for the same error message. The list of Event 547 failures and potential causes are described in detail in the following sections.
In Windows XP SP2 and Windows Server 2003, all IKE audits can be disabled with a DisableIKEAudits registry key. Be sure to check this value on computers that are being investigated. IKE audits may be disabled in cases where IKE auditing generates so many success or failure events that other Logon/Logoff category events cannot be effectively monitored.
Error code values are often reported in IKE audit events and log details. Descriptions of these error code values are available from Microsoft MSDN® on the System Code Errors (12000-15999) page.
Troubleshooting IKE negotiation requires in-depth knowledge of the expected behavior of IPsec policy design, the IKE negotiation process, and IKE failure events. This section attempts to explain only the most common events related to the Woodgrove Bank domain isolation scenario. It does not address all IKE audit events or failure conditions.
After the IKE negotiation process is well understood, a network trace from at least one side of the communication should be obtained (if possible) to identify problems within IKE before attempting to gather an Oakley.log file. Deployed servers in server and domain isolation scenarios should have the ability to capture a trace with Network Monitor.
The Oakley.log file provides the most detailed logging available and may be required from both sides of the negotiation (with synchronized times). However, if you enable this log the IKE negotiation may slow down, which will change timing conditions and cause all of the existing state to be lost if the service is restarted to re-read the registry key (required in Windows 2000 and Windows XP SP1). Currently, there is no published guidance for interpreting the Oakley.log file. For purposes of this guide, such interpretation is considered part of the Tier 3 skill set. Because of space constraints, brief excerpts from log details are provided here for only a few errors. For help with interpreting the Oakley.log file, contact Microsoft Product Support.
The following four detailed logging files are maintained for IKE:
· Oakley.log. Current log for IKE, limited to 50,000 lines.
· Oakley.log.bak. After 50,000 lines are accumulated in Oakley.log, this file is created and a new empty Oakley.log file is started. This file continues to be overwritten as necessary by the newer Oakley.log file for as long as the IPsec service is running.
· Oakley.log.sav. The previous Oakley.log file is saved under this name when the IPsec service starts.
· Oakley.log.bak.sav. The previous Oakley.log.bak file is saved under this name when the IPsec service starts.
A common mistake that is often made during troubleshooting is not synchronizing the time on the two computers from which logging and network traces are captured. This makes log correlation difficult, although not impossible. Correlation of IKE messages to packets in a network trace should be cross-checked using the ISAKMP header cookies and IKE quick mode message ID fields.
Expected IKE Behaviors
If the IKE main mode initiation is blocked by the network from reaching the intended destination IP address, IPsec-secured communication cannot be negotiated. If the initiator is not configured to Fall back to clear, then failure to contact the destination will appear as an audit event 547 in the Security Log with one of the following text entries:
· No response from peer
· Negotiation timed out
· IKE SA deleted before establishment completed
However, for domain isolation clients this condition may not appear as a failure if their policy allows Fall back to clear. An IKE main mode success event 541 is created when a soft SA is established. The indication that a 541 event shows a soft SA is that the outbound SPI is zero and all algorithms are shown as None. The following example shows how these parameters will look in a 541 event:
ESP Algorithm None
HMAC Algorithm None
AH Algorithm None
Encapsulation None
InboundSpi 31311481 (0x1ddc679)
OutBoundSpi 0 (0x0)
Lifetime (sec) <whatever is configured for QM lifetime>
Lifetime (kb) 0
Note Soft SA events to the same destination IP address will have a different timestamps and different inbound SPI values.
One minute connectivity delays are experienced whenever two computers become unsynchronized with regard to whether an active IKE main mode exists between them. Five minute delays may be experienced if one computer believes there is an active IPsec SA pair between them and the other computer (for example, a server) has deleted these SAs and is not initiating a quick mode rekey. Windows 2000 IKE supported single delete messages, which were sometimes lost. Windows XP and Windows Server 2003 added support for "reliable" delete functionality in the form of multiple delete messages as a safeguard against dropped packets.
The most common scenario for this situation is one in which a domain isolation laptop user ejects the laptop from a docking station to go to a meeting. The docking station has a wired Ethernet connection, and the act of removing that network interface requires that all filters associated with that interface be deleted (if they were filters expanded from My IP address).
However, none of the filters with a negotiate action use My IP Address in the domain isolation solution—they are all Any <-> subnet filters. Consequently, the IPsec SA and IKE SA states remain active in the laptop because these filters are not deleted on each address change. If filters had been expanded from "My IP Address," then these filters would have been deleted when the IP address disappeared.
Whenever a filter of any type is deleted in the IPsec driver, the driver informs IKE that all IKE SAs and IPsec SAs using that IP address must also be deleted. IKE will attempt to send delete messages for these SAs and will delete them internally. These delete messages will have the same source IP that was used for the IKE SA, although a different source IP may be present on the connected interface at the time the delete is sent. The source IP address does not matter to the remote computer if the ISAKMP header cookie pair is recognized and cryptographic checks on the packet are valid. However, delete messages often do not get sent because there is no network connectivity in the seconds after the disconnection occurs (the laptop is ejected).
In this particular case of Any <-> subnet filters the filters are never deleted, which means the IKE and IPsec SAs are not immediately deleted. Meanwhile, the IPsec SAs time out on remote computers that were formerly connected, and IKE quick mode deletes are sent to the former address of the laptop. The IKE main mode SAs continue to live for a default time of 8 hours on these remote computers, but may be deleted any time before that for internal reasons known to IKE. Of course, the IKE SA delete messages are not received by the laptop at its former IP address. When the laptop finally reconnects to the docking station, it receives the same IP address again. File shares, e-mail clients and other applications typically reconnect to the same destinations. However, there may now be a difference in IKE state between the laptop and these remote destinations. If the laptop still has an IKE main mode, it will attempt an IKE quick mode negotiation. The quick mode uses a cryptographic state that the remote peer has deleted, so it does not recognize these messages and does not reply. On the laptop, IKE expires the retry limit after one minute and attempts a new IKE main mode negotiation, which now succeeds. Accordingly, the laptop user may notice a one minute delay when reconnecting to remote resources. Microsoft expects to be able to improve this behavior in future updates for all versions of Windows that support IPsec.
The IKE negotiation may report a timeout for a variety of reasons. The "Negotiation timed out" event occurs when any step of an IKE negotiation (except Fall back to clear) fails because the retry limit is exhausted, except when IKE terminates the negotiation with an "IKE SA deleted before establishment completed" event. These two events are essentially the same. They are often common, benign, and expected during regular operations for mobile clients, which frequently and quickly change network connectivity states when the following events occur:
· Users insert and remove laptops computers from docking stations
· Users unplug a wired connection
· Laptop computers hibernate or go into standby mode
· Computers go beyond the range of a wireless connection
· A VPN connection is disconnected
· A PCMCIA network card is ejected while it is connected
To a remote computer, any of these events make it appear as if the peer computer just dropped off the network. The remote computer will attempt to rekey or renegotiate until the IKE negotiation step times out.
Negotiation timeout failures were enhanced in Windows Server 2003 to identify where in the IKE negotiation the timeout occurred by identifying the last successful step in the negotiation. These events can also be caused by the presence of network address translation (NAT) when IKE is negotiating without NAT-T capabilities. However, IKE negotiation will also time out if the remote peer encounters a reason to fail the IKE negotiation.
Therefore, in all cases of negotiation timeouts and "IKE SA deleted before establishment completed" events, Tier 2 support should identify if the remote computer actually failed the negotiation by checking for 547 failure audit events on that computer for up to one minute before IKE logs the timeout.
IKE Negotiation Success Events
If IKE negotiation is successful, IKE main mode SAs will display in the IPSec Monitor MMC snap-in and through command-line query tools.
To show a list of the current IKE main mode SAs
· For Windows 2000:
ipsecmon.exe, netdiag /test:ipsec /v
Note This command shows only IPsec SAs, not IKE main mode SAs
· For Windows XP:
IPsec monitor snapin, ipseccmd show sas
· For Windows Server 2003:
IPsec monitor snapin, netsh ipsec dynamic show [mmsas | qmsas]
Successful main mode and quick mode SAs will generate the following events in the Security Log if auditing is enabled:
· 541. IKE Main Mode or Quick Mode established
· 542. IKE Quick Mode was deleted
· 543. IKE Main Mode was deleted
IKE Main Mode Informational Log Entries
To determine whether there is a problem with main mode exchange, look for the following logged events in the computer’s events logs:
Table 7.5 IKE Main Mode Informational Log Messages
| Log text | Description |
| New policy invalidated SAs formed with old policy | A Windows 2000 message that indicates an IPsec policy change caused deletion of current IKE or IPsec SAs. This error is benign. New IPsec SAs will be formed based on current traffic flow that use the new IPsec policy. |
| IKE has a large number of pending Security Association establishment requests, and is beginning denial of service prevention mode | This condition could be normal, caused by high machine loads and/or a large number of client connection attempts. It also could be the result of a denial of service attack against IKE. If so, there will usually be many audits for failed IKE negotiations to spoofed IP addresses. Otherwise, the computer is just under an extreme load. Indicates that IKE believes it has been flooded with IKE main mode SA establishment requests so it is going to drop many of them as part of a denial of service attack response strategy. |
| IKE has recovered from denial of service prevention mode and has resumed normal operation | IKE has recovered from what it believed was a denial of service attack condition and resumed normal operation. |
Existence of these entries does not indicate a failure to communicate. These entries are informational and can be used to provide additional information to help determine the real cause of a problem.
IKE Main Mode Negotiation Failure Events #547
The following IKE failure events can occur when an IKE main mode negotiation fails:
· No response from peer. This event would be expected for outbound connections to computers that are not using IPsec and that are not members of the exemption list. However, Tier 2 support should be alert to connectivity problems that block IKE negotiation, which will also produce this event.
· No policy configured. This event indicates a problem if the source IP address is an address within the internal subnets or may indicate a mismatched filter set. Otherwise, it may be expected that computers do not have a rule to negotiate with certain address ranges or subnets. Computers on those subnets may attempt IKE initiation, but will not get replies because no policy is configured.
· IKE security attributes are unacceptable. This event should not happen on properly configured systems. Complete the steps in the "Verifying the Correct IPsec Policy" section to investigate.
Any of the following "Negotiation timed out" messages could be expected for reasons discussed previously. They can also indicate that the remote computer failed the IKE negotiation. Typically, Tier 2 support focuses on investigating the IKE failure on the remote computer rather than negotiation timeouts, which are so common for disconnected computers, and policy design incompatibility in which the responder to an IKE main mode or IKE quick mode negotiation does not find a specific filter to match the incoming request.
· Negotiation timed out
· Negotiation timed out-Processed first (SA) payload Responder. Delta Time 63
· Negotiation timed out-Processed second (KE) payload Initiator. Delta Time 63
· Negotiation timed out-Processed second (KE) payload Responder
IKE Quick Mode Audit Failures (547)
The following IKE failure events can occur when an IKE quick mode negotiation fails:
· No policy configured-Processed third (ID) payload Initiator
· Security association negotiation failure because of attribute mismatch
· General processing error
· Failed to obtain new SPI for the inbound SA from IPsec driver
· IPsec driver failed the Oakley negotiation, no filter exists
· Failed to add Security Association to IPsec driver
· Negotiation timed out
IKE quick mode should not fail for properly designed IPsec policies and under typical operational loads. If any of these errors are received, Tier 2 support should first follow the steps in the "Verifying the Correct IPsec Policy" section. Then, Tier 2 support should attempt to correlate these events with unusual performance conditions, such as 100% CPU utilization or a very low kernel memory conditions.
Note that IKE quick mode failures with negotiation timed out would be expected if the computer was no longer using its former IP address for any of the reasons explained earlier.
Troubleshooting IKE Failures Caused by Authentication
The following messages are related to IKE authentication failures:
· Specified Target is Unknown / No authority could be contacted for authentication
· The specified target is unknown or unreachable-Processed first (SA) payload Initiator. Delta Time 0
· IKE Authentication Credentials Are Unacceptable
· The Logon Attempt Failed
· Failed to Authenticate Using Kerberos
· IKE failed to find valid machine certificate
The first two messages indicate that the Kerberos identity of the remote computer can not be used to obtain a service ticket for the remote computer. This situation could exist because there is no domain trust, or because access to domain controllers is not available.
If an inbound IKE negotiation fails because of "Access This Computer From Network" settings, then the IKE negotiation on the side that enforces the access rights will report a 547 event "Failure to Authenticate using Kerberos" as described earlier. That event does not specifically indicate that the problem is the failure when checking "Access This Computer From Network rights," and therefore an Oakley.log file must be obtained from the server to see the specific error generated. The group membership of the IKE initiator should be investigated to see if it is in fact a member of an authorized group. If the computer is a member of a group that has authorized access, then the computer may not have Kerberos tickets that reflect the new membership. Alternatively, the computer may not be able to obtain proper Kerberos tickets. Complete the procedures discussed in the "Verifying Connectivity and Authentication with Domain Controllers" section earlier in this chapter.
Troubleshooting Application-Related Issues
This section discusses how application design may interact with the use of IPsec in Microsoft Windows. The IPsec policy designer should understand these impacts, and support personnel should be aware of these impacts so that they can assist with rapid problem classification and identification. Applying IPsec policy should be largely transparent to applications. However, there are circumstances in which having IPsec policy assigned or protecting traffic may cause the application to behave differently. The following sections highlight these in the context of the Woodgrove Bank domain isolation solution.
ICMP Permitted, But TCP and UDP Require IPsec
Some applications use an ICMP echo request (Ping) message to determine whether a destination address is reachable. For example, IPsec does not protect ICMP traffic in this solution, so an application may receive an ICMP response from a target destination. However, the application may not be able to connect to the target destination by using IPsec-protected TCP and UDP traffic when the IKE negotiation fails.
Initial Connection Delays
The IKE negotiation involves substantially more processing and time to complete than a TCP three-way handshake or an unauthenticated Nbtstat single packet query and response. Applications that expect a quick TCP or UDP connection response from a target destination may determine that the destination is not responding and take some other action, such as report an error or try to connect to an alternate destination. IKE negotiations using Kerberos authentication typically complete successfully within 1-2 seconds. However, this timing is dependent on many factors, particularly the CPU utilization of both computers and network packet loss. Fall back to clear always requires three seconds before it allows the first packet of the TCP handshake to be sent unprotected.
Application Hangs Waiting on Network Response
Some applications are written to assume that the time to connect or to receive an error message is very quick. These applications will wait for the connection to complete (for the socket bind operation to complete) before they display changes in the user interface. When this application traffic is protected by IPsec, the application may appear to hang briefly during successful connections. The application may hang until it is terminated or encounter other unusual errors if the connection does not succeed because of an IKE negotiation failure or an IPsec block filter. The network socket layer is not aware of IPsec filters or that IKE is negotiating security for traffic. The application usually interprets these conditions as being caused by the remote host being down or a network failure. However, applications may also interpret failures to reach domain controllers as being caused by the destination computer being unavailable, or that the connection was refused.
Kernel Mode Network Packet Processing Affected
Applications that involve network drivers or other kernel-level packet processing may not work properly when IPsec secures traffic. These applications may make modifications to the packet, which will cause IPsec to drop the packet. Alternatively, the application may be confused by IPsec modifications, which can result in a system error (blue screen).
Network Scanning from Hosts in Isolation Domain Affected
Host-based tools that seek to rapidly probe remote IP addresses or open ports on the network may run much slower if IPsec attempts to secure their probe traffic. The probe traffic may cause a denial of service on the local host by triggering IKE to initiate to hundreds of IP addresses within a few seconds or minutes. Some SNMP-based tools depend upon SNMP trap events being sent to untrusted hosts that serve as event collectors. Even if IPsec is allowed to Fall back to clear, the outbound SNMP trap packets may be discarded by the IPsec driver before the soft SA is established. Similarly, some UDP-based applications (such as NTP and the Windows domain controller locator) only wait three seconds for a reply to be received, which results in application failure or false reports that a destination cannot be reached.
Winsock Layered Service Provider Issues
Some legitimate applications (such as personal firewalls) and some malicious applications (such as spyware) can cause problems by inserting their own network traffic inspection functions, which are called Winsock Layered Service Providers (LSPs).The IKE component of the Microsoft implementation of IPsec uses an extended Winsock API function whose function pointer is determined by calling WSAIoctl(). If this function call is not allowed to pass through any installed LSP, IKE cannot monitor the required UDP ports. In Windows Server 2003, IPsec interprets this as a failure of the component to enforce required security policy and reacts defensively. "Fail to a Secure Mode" is invoked, and the IPsec driver is put in block mode. An administrator must log in by using a desktop login to stop the IPsec service and restore connectivity. If the IPsec service does not respond to the stop request, then the IPsec service must be configured as disabled and the computer restarted.
Even if IKE does appear to have proper initialization, the ability for the computer to send and receive IKE and IPsec protocols may be blocked by the LSP or another installed third-party program.
For Tier 2 support, Winsock LSP troubleshooting consists of identifying that LSPs exist. Tier 3 support would be engaged to conduct further investigation to identify the application that installed the LSPs and to reorder them or remove them to see if the IPsec service or IKE no longer has problems. Tools for detecting Winsock LSPs include:
· Sporder.exe. An applet that is available for viewing LSPs in the Winsock 2.0 part of the Windows Platform Software Development Kit (SDK).
· Netdiag /debug.
Third-Party IPsec VPN Clients
A number of issues may occur when a third-party IPsec implementation is installed as part of a remote access VPN client. Typically, these clients disable the IPsec service and are not in conflict with native Windows IPsec. However, for members of the trusted domain in this solution, the native IPsec service is required. Therefore, third-party IPsec implementations may conflict for the following reasons:
· Both IKE implementations may need UDP port 500.
· IPsec kernel packet processing for both may require the ESP protocol.
· Winsock LSP functions that are installed as part of the client.
· Firewall functionality provided by the VPN client.
· Layering that prevents native IKE and IPsec encapsulated packets from being passed through the third-party IPsec tunnel.
VPN vendors may be the best source of information about whether they support the native Windows IPsec service being enabled, and whether IPsec-protected transport mode traffic is supported end-to-end through their remote access connection. In some cases, the VPN vendor gateway supports Windows 2000 and Windows XP PPTP and L2TP/IPsec VPN clients. The native Windows VPN clients are compatible with IPsec transport mode end-to-end through the VPN tunnel.
Tier 3 Troubleshooting
If Tier 2 troubleshooting fails to resolve the issue, additional expertise will be required to analyze the problem and find a resolution. This expertise is considered Tier 3 support. In many cases, this support will be provided by contracted IPsec specialists or support organizations, such as Microsoft's own Product Support Services.
Tier 3 IPsec support requires in-depth understanding of IPsec operation and the Microsoft TCP/IP stack. Tier 3 support staff members require significant training on IPsec and the use of IPsec in server and domain isolation scenarios. The skills that Tier 3 staff members acquire may allow them to become responsible for training staff members in lower-level tiers and for developing supporting documentation such as technical briefs, white papers, support guides, FAQs, and information about IPsec architecture and taxonomy. Tier 3 support may also be responsible for developing and documenting disaster recovery plans.
Engaging Microsoft Product Support Services
If the troubleshooting procedures described in this chapter do not help you solve your problem, or if your organization does not have sufficient expertise to use advanced troubleshooting techniques, you may need to escalate the problem to Microsoft Product Support Services. It is important to collect as much diagnostic information as possible, such as from logs and network monitoring, before engaging Product Support Services. Use this list to gather information that Tier 3 support or Microsoft Product Support Services will need to analyze the problem:
· Security requirements for inbound and outbound authentication and authorization for each computer. A brief description should be available to describe how the Group Policy and IPsec configuration on the computer fulfill these requirements.
· A representative diagram of the scenario, showing the names of the source and destination computers, their IP addresses at the time that the log files are collected, and operating system versions (including Service Pack information). Also indicate the IP addresses of the DNS servers, WINS servers, and domain controllers.
· Network monitor traces of communications taken from each side while IPsec policy is active, preferably simultaneously so that the packets can easily be correlated in the two trace files. The network traces should include all inbound and outbound traffic on each computer (if possible) so that authentication requests, DNS lookups, and other related traffic can be identified. Also, if communications fail while IPsec policy is active and they succeed with IPsec policy disabled or the service stopped, a network trace of traffic while IPsec is not active should also be made available. It is very important that system time be synchronized between these systems so that logs and trace files can be correlated.
· For Windows 2000, Windows XP, and Windows Server 2003,
netdiag /debug >netdiag-debug-computername.txt log output run just before or just after capturing the network trace. (Netdiag generates a lot of network traffic, which does not need to be part of the network trace.) For Windows XP and Windows Server 2003, also run
portqry -v -local >portqry-v-computername.txt.
· IKE Oakley.log files from each side that are collected at the time that the problem occurs and the time that the network monitor traces are recorded. The file names for these files should indicate the computer name. If a Windows RAS or VPN client is involved, the RASDIAG tool should be used to collect information.
· The entire System Log, Security Log, and Application Log of each computer at the time that the Oakley.log files and network traces are collected.
· Any Group Policy-specific log files that created at the same time that the Oakley.log and network traces are captured.
· The details of the IPsec policy for each computer. If the IPsec policies that apply to each computer can be easily saved, then they should be included. However the active IPsec policy of the computer is often the combination of several types of IPsec policy configuration, not just domain or local policy. The best format for analyzing the active policy on a computer is a listing of the IKE main mode-specific filters and IKE quick mode-specific filters from the IPsec Monitor MMC snap-in.
To create a formatted text file of these filters
1. Right-click the IKE Quick Mode Specific Filters node in the left pane of the tree.
2. Select Export List.
3. Save the tab-delimited text file as IKE-qm-<specific-computername>.txt or with a similar naming convention that includes the computer name.
A tab-delimited text file with all of the filter details can be imported into a spreadsheet or word processing document.
Summary
This chapter provided detailed information about processes that will help both Tier 1 support (help desk staff) and Tier 2 support (IT professional network support staff) understand how to troubleshoot common IPsec communication problems. It is not possible to provide information about all potential errors, because IPsec and network security are so complex that all variations could not be listed. Where applicable, the developers of this chapter have streamlined the possible options to focus the guidance on those areas that are most likely to experience problems in the type of server and domain isolation environment that was detailed in this guide.
The example scripts provided with this guide were tested in the Woodgrove Bank scenario test lab implementation to prove their effectiveness. However, these scripts are designed to be customized to meet an organization's needs and are therefore unsupported by Microsoft.
It should be obvious to the reader that IPsec troubleshooting is technically complex and requires skills in many areas of technology besides IPsec, including networking, Active Directory, and Group Policy. However, the information provided in this chapter should make it possible for the reader to troubleshoot all but the most obscure issues that can affect a server and domain isolation solution.
For those readers who wish advance their knowledge into the realms of Tier 3 support, there is enough additional reading material referenced in the following section to keep you occupied for several years!
More Information
· For detailed background information on IPsec, see How IPsec Works.
· For detailed information on troubleshooting TCP/IP issues, see the following technical references:
· TCP/IP in Windows 2000 Professional
· The “Troubleshooting Name Resolution and Addressing” section of the “Configuring IP Addressing and Name Resolution” chapter within the Windows XP Professional Resource Kit
· "How to troubleshoot TCP/IP connectivity with Windows XP"
· Windows Server 2003 TCP/IP Troubleshooting
· For online help and resource kit documentation that specifically discusses IPsec troubleshooting in Windows 2000, Windows XP, and Windows Server 2003, see the following references:
· "Basic IPsec troubleshooting in Microsoft Windows 2000 Server"
· Microsoft Windows 2000 Advanced Documentation
· "Basic L2TP/IPSec Troubleshooting in Windows XP"
· The Architecture Overview diagram in the "Windows 2000 TCP/IP Implementation Details" white paper
· Figure B1 in the Overview of Windows 2000 Network Architecture
Appendix A: Overview of IPsec Policy Concepts
This appendix provides a detailed overview of the terms, processes, and concepts of IPsec. It is designed to provide the prerequisite level of understanding for IPsec as described in the Server and Domain Isolation Using IPsec and Group Policy guide.
The content of this appendix was originally published as part of the "Using Microsoft Windows IPsec to Help Secure an Internal Corporate Network Server" white paper which was jointly written by Microsoft and Foundstone Strategic Security.
Additional information in the white paper describes the first model for using IPsec to secure network access to internal Microsoft® Windows® servers that process or store sensitive data. Although this extra information is not required to understand the Server and Domain Isolation Using IPsec and Group Policy guide, it is useful background information.
Introduction
When you create an IPsec policy, you configure IPsec rules (which determine IPsec behavior) and settings (which apply regardless of the rules that are configured). After you configure an IPsec policy, you must assign it to a computer for the policy to be enforced. Although multiple IPsec policies can exist on a computer, only one IPsec policy can be assigned to a computer at a time.
An IPsec rule determines which types of traffic IPsec must examine; whether traffic is permitted, blocked, or security is negotiated; how to authenticate an IPsec peer; and other settings. When you configure an IPsec rule, you configure a filter list that includes one or more filters, a filter action, authentication methods, a connection type, and an IPsec encapsulation mode (transport mode or tunnel mode). An IPsec rule is typically configured for a specific purpose (for example, “Block all inbound traffic from the Internet to TCP port 135”).
Filters define the traffic that you want to inspect, similar to a firewall rule, with source and destination IP addresses, protocols, and port numbers, if applicable. A filter action defines the security requirements for the network traffic. You can configure a filter action to permit, block, or negotiate security (negotiate IPsec). If you configure a filter action to negotiate security, you must also configure key exchange security methods (and their preference order), whether to accept initial incoming unsecured traffic, whether to allow unsecured communication with computers that do not support IPsec, and whether to use perfect forward secrecy (PFS).
Key exchange settings and key exchange security methods determine the IPsec protocol wire formats (authentication header (AH) or encapsulated security payload (ESP)), encryption and hashing algorithms, key lifetimes, and other settings required to configure both the Internet Key Association (IKE) main mode and IPsec security associations (SA). An SA is the agreement of security settings associated with keying material.The SA created during the first IKE negotiation phase is known as the IKE main mode SA (also known as the ISAKMP main mode SA). The IKE main mode SA protects the IKE negotiation itself. The SAs created during the second IKE negotiation phase are known as the IPsec SAs (also known as IKE quick mode SAs because each IKE quick mode negotiation negotiates the IPsec SA for each direction). The IPsec SAs protect application traffic.
This section provides information about the following important IPsec policy concepts:
· IKE negotiation process
· IPsec policy filters
· Security methods
· IPsec protocol wire formats
· IKE authentication
· IKE authentication method and security method preference order
· Security negotiation options
For more information about IPsec policy concepts, see the Help and Support Center for Microsoft Windows Server™ 2003.
IPsec Policy Filters
Filters are the most important part of an IPsec policy. If you do not specify the proper filters in either client or server policies, or if the IP addresses change before the policy's filters are updated, security might not be provided. IPsec filters are inserted into the IP layer of the TCP/IP networking protocol stack on the computer so that they can examine (filter) all inbound or outbound IP packets. Except for a brief delay, which is required to negotiate a security relationship between two computers, IPsec is transparent to end-user applications and operating system services. Filters are associated with a corresponding filter action by the security rule in an IPsec policy. Windows IPsec supports both IPsec tunnel mode and IPsec transport mode as an option in the rule. IPsec tunnel mode rule configuration is very different from IPsec transport mode rule configuration.
The filtering rules associated with an IPsec policy are similar to firewall rules. By using the graphical user interface (GUI) provided by the IP Security Policy Management Microsoft Management Console (MMC) snap-in, you can configure IPsec to permit or block specific types of traffic based on source and destination address combinations and specific protocols and ports.
Note Windows IPsec is not a full-featured, host-based firewall, and it does not support dynamic or stateful filtering features, such as tracking the established bit during the TCP handshake to control the direction in which communication can flow.
Understanding IPsec Filtering
Filter lists are simply listings of known subnets and infrastructure IP addresses. What is important to understand is how all of the filters contained in all of the rules will combine to provide the required inbound and outbound access controls. This section provides the most important details to understand about how IPsec filters affect packet processing.
The Windows Server 2003 IPsec Monitor MMC snap-in provides the most detailed view of the ordering of IPsec filters. When the IPsec service processes a set of IPsec policy rules, the filters are copied into two types in order to provide control of the two phases of the IKE negotiation:
1. IKE main mode filters. These filters use only the source and destination address of the filters defined in IPsec policy to control IKE main mode. The IKE main mode-specific filters each have an IKE main mode negotiation policy associated that defines:
· IKE main mode security methods defined for the IPsec policy under key exchange settings, such as Diffie Hellman master key strength and the encryption and integrity algorithms used to protect the IKE negotiation itself.
· IKE main mode lifetimes and limits on the number of session keys generated from the same master key.
· Authentication method(s).
2. IKE quick mode filters. These filters contain the full filter information about addresses, protocols, and ports. IKE quick mode negotiates this filter definition to determine what traffic can be secured inside an IPsec security association pair. Each specific filter has a corresponding weight and a set of security methods that define:
· Options for AH or ESP encapsulation in transport or tunnel mode.
· A list of encryption and integrity algorithms.
· IPsec security association lifetimes in kilobytes and seconds.
· Perfect forward secrecy security settings.
The IKE quick mode-specific filters are the list of filters that are given to the IPsec driver to enforce. The IPsec driver matches all inbound and outbound IP traffic against these filters, in the order specified by the highest weight. The following section on the IKE negotiation process describes how IKE negotiates and manages IPsec security associations using these policy controls.
Filters defined in IPsec policy are considered "generic" filters because they may have to be interpreted by the IPsec service when the policy is applied. The IPsec service interprets all generic filters into specific filters at the time that the IPsec policy (or change) is being applied on the computer. Specific filters have a built-in algorithm for calculating the weight, or order, which is also referred to a how specific the filter is when selecting traffic. A higher weight value corresponds to a more specific filter. All of the specific filters are sorted according to their weight. The weight of the filter is evaluated first on IP address, then on protocols, and finally on ports that may be defined within the filter. This approach ensures that the order of rules in a policy, and the ordering of filters in each different filter list, have no effect on the filtering behavior enforced by the IPsec driver during packet processing. The packets are matched against the most specific filters first to minimize the time required to process each packet against the total set of filters. The filter action that corresponds to the most specific filter matching a packet is the only action taken for that packet. The most generic filter that can be defined would be one that matches any IP address, all protocols, and ports. For example, consider the following four filter definitions:
· Any <-> Any, any protocol
· Any <-> 192.168.1.0/24, any protocol
· Any <-> 192.168.1.10/24, any protocol
· Any <-> 192.168.1.10/24, TCP source port Any, destination port 25
Any to Any filter is the most general filter possible to define. It is only supported by Windows Server 2003 and Windows XP Service Pack 2 (SP2). Typically, this filter is used with a block action to achieve a default behavior of "Deny All." If this filter is being used to block all traffic, the rest of the more specific filters could be considered exceptions to the first filter. For Windows 2000, the supported, most general filter is Any <-> subnet, any protocol, or Any <-> My IP address if subnets are not used.
All four filters would match inbound traffic from any IP address to 192.168.1.10 using TCP port 25 and the corresponding outbound responses from port 25. The fourth filter is the most specific because it specifies a destination IP address, protocol, and port number. When all four are being enforced by the IPsec driver, an inbound packet destined to TCP port 25 will only match the fourth and most specific filter. If a remote system sends TCP traffic to any port other than 25 to 192.168.1.10, the third filter is matched. Finally, if traffic is sent to any IP address in the 192.168.1.0 subnet with the exception of 192.168.1.10, the second filter will be the most specific for that traffic.
Potential Filter Design Issues
When defining filters, certain combinations of source and destination address options should not be used. As noted above, filters that specify Any IP Address to Any IP Address should be avoided for hosts running Windows 2000.
Generally, the more filters in a policy, the more performance impact to packet processing. This performance impact appears as degraded throughput, increased non-paged pool kernel memory utilization, and increased CPU utilization. The precise impact on performance is very difficult to estimate because it depends on the overall traffic volume, the amount of IPsec-secured traffic being processed, and the CPU loads on the computer. Therefore, performance testing of IPsec policy designs should be factored into the planning effort. The impact of a few hundred filters is not likely to be noticed except on very high throughput computers.
Windows 2000 does not have optimizations for handling large numbers of filters. The IPsec driver must scan the whole filter list sequentially to find a match.
In Windows XP and Windows Server 2003, many optimizations were made to speed up filter processing so that larger numbers of filters can be used in the IPsec policy. Filters of the form From <IP address> To <IP address> regardless of protocol or ports were optimized by using the Generic Packet Classifier (GPC) driver for extremely fast lookup. GPC can handle almost any number of these filters without throughput performance degradation. Therefore, large exemption lists using My IP address to <specific exemption IP address> are easily supported provided there is enough non-paged kernel memory available to hold the entire filter list. Filters that do not have a specific IP address for both source and destination cannot be optimized by GPC, which means that Any IP <-> specific IP (or subnet) filters will require sequential searching. But the implementation is improved over Windows 2000.
The use of My IP Address may be appropriate in many cases but may also cause problems for hosts with many IP addresses, such as a Web server hosting many virtual Web sites. It may also cause a delay in the availability of IPsec driver packet filtering if there are a large number of filters using My IP Address. The IPsec service processes them during service startup and when an address change event happens. The delay may cause a window of vulnerability or delays in connecting securely with IPsec. Again, performance testing should confirm acceptable impacts of a particular policy design.
My IP Address might be most appropriately used when permitting or denying traffic to a specific port or protocol. For example, in the IPsec policy design for Woodgrove Bank, My IP Address filters are used to create a more specific filter that permits Internet Control Message Protocol (ICMP) traffic to be sent and received in clear text among all computers.
If a mobile client in the organization is assigned a My IP Address <-> Any IP Address rule and is then placed on an external network, the mobile client may fail to communicate in that environment. If the client is allowed to Fall back to clear, then the client will experience three-second and greater delays connecting to every destination. If the destination replies with an IKE response, the IKE negotiation will fail because IKE will not be able to authenticate using domain trust (Kerberos). Clearly, if RFC 1918 private addresses are used as internal network subnets, mobile clients will be affected when they connect to hotels, home networks, and potentially other internal networks. If mobile clients experience connectivity problems, they may require Local Administrator rights to stop the IPsec service when connected to other networks. Consequently, a domain logon script may need to be used to check if the IPsec service is running when they connect to the internal network.
Windows 2000 was not originally designed to provide filtering for packets using multicast and broadcast addresses because this traffic could not be secured using IKE negotiation. Therefore, multicast and broadcast packet types were part of the original default exemptions that bypassed IPsec filters. See Microsoft Knowledge Base article 811832, "IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios" for an in-depth explanation of the security implications of default exemptions and the changes implemented by Service Pack 3 to remove some of them by default. The TCP/IP integration with IPsec in Windows XP and Windows Server 2003 was enhanced to filter all types of IP packets. However, because IKE cannot negotiate security for multicast and broadcast, only limited support for filtering is provided. See Knowledge Base article 810207, "IPSec default exemptions are removed in Windows Server 2003" for details on the removal of default exemptions and the degree of filtering support for multicast and broadcast traffic. Windows XP SP2 supports the same filtering capabilities as Windows Server 2003.
IKE Negotiation Process
The IKE protocol is designed to help securely establish a trust relationship between each computer, negotiate security options, and dynamically generate shared, secret cryptographic keying material. In order to ensure successful and secure communication, IKE performs a two-phase operation: Phase 1 (main mode) negotiation and Phase 2 (quick mode) negotiation. Confidentiality and authentication may be ensured during each phase by the use of encryption and authentication algorithms that are agreed upon by the two computers during security negotiations.
Main Mode Negotiation
During main mode negotiation, the two computers establish a secure, authenticated channel. First, the following IPsec policy parameters are negotiated: the encryption algorithm (DES or 3DES), the integrity algorithm (MD5 or SHA1), the Diffie-Hellman group to be used for the base keying material (Group 1, Group 2, or, in Windows Server 2003, Group 2048), and the authentication method (Kerberos version 5 protocol, public key certificate, or preshared key). After IPsec policy parameters are negotiated, the Diffie-Hellman exchange of public values is completed. The Diffie-Hellman algorithm is used to generate shared, symmetric, secret keys between computers. After the Diffie-Hellman exchange is complete, the IKE service on each computer generates the master key that is used to help protect authentication. The master key is used, with the negotiation algorithms and methods, to authenticate identities. The initiator of the communication then presents an offer for a potential SA to the responder. The responder sends either a reply accepting the offer or a reply with alternatives. The result of a successful IKE main mode negotiation is a main mode SA.
Quick Mode Negotiation
During quick mode negotiation, a pair of IPsec SAs is established to help protect application traffic, which can include packets sent over TCP, User Datagram Protocol (UDP), and other protocols. First, the following policy parameters are negotiated: the IPsec protocol wire format (AH or ESP), the hash algorithm for integrity and authentication (MD5 or SHA1), and the algorithm for encryption (DES or 3DES), if encryption is requested. During this time, a common agreement is reached regarding the type of IP packets to be carried in the IPsec SA pair that is established. After IPsec policy parameters are negotiated, session key material (cryptographic keys and key lifetimes, in seconds and kilobits, for each algorithm) is refreshed or exchanged.
Each IPsec SA is identified by a security parameter index (SPI), which is inserted into the IPsec header of each packet sent. One SPI identifies the inbound IPsec SA; the other SPI identifies the outbound IPsec SA.
IKE Main Mode SAs and IPsec SAs
Each time IPsec is used to help secure traffic, one IKE main mode SA and two IPsec SAs are established. In the example scenario, for IPsec-secured communications to occur between CORPCLI and CORPSRV, the following SAs are established:
CORPCLI [IP1] <-------- IKE main mode SA [IP1, IP2] -----> [IP2] CORPSRV
CORPCLI [IP1] ---------- IPsec SA [SPI=x] --------------------> [IP2] CORPSRV
CORPCLI [IP1] <-------- IPsec SA [SPI=y] ---------------------- [IP2] CORPSRV
Where:
· IP1 is the IP address of CORPCLI.
· IP2 is the IP address of CORPSRV.
· x is the SPI that identifies the inbound IPsec SA for CORPSRV from CORPCLI.
· y is the SPI that identifies the outbound IPsec SA for CORPSRV to CORPCLI.
As this summary indicates, the IKE main mode SA between CORPCLI and CORPSRV is bidirectional. Either computer can initiate a quick mode negotiation by using the protection provided by the IKE main mode SA. IPsec SAs are not dependent on the state of upper-layer protocols. For example, TCP connections can be established and ended while IPsec SAs continue, and IPsec SAs can expire before a TCP connection ends. IKE attempts to renegotiate, by using the quick mode negotiation to establish two new IPsec SA pairs before the lifetime of the existing IPsec SA pair expires, to help prevent a connection from being disrupted. Although this process is commonly referred to as rekeying the IPsec SA, two new IPsec SAs are actually established. The life of the IKE main mode SA is measured only by time and the number of IPsec SAs that have been attempted (not by the number of bytes of data that is transferred in the IKE protocol). The IKE main mode SA expires independently of the IPsec SA pair. If a new IPsec SA pair is needed, an IKE main mode SA is automatically renegotiated as required (when a main mode SA has expired). By Internet Engineering Task Force (IETF) design, IKE must be able to rekey the main mode SA and negotiate IKE quick mode in either direction. Therefore, the authentication method that is configured in the IPsec policy on both computers for the IKE main mode SA should allow authentication to succeed in the direction from which the IKE main mode negotiation is initiated. Likewise, the IPsec policy settings in the filter action for quick mode should allow successful bidirectional quick mode negotiation.
Security Methods
Security methods are used during the IKE main mode negotiation to define the encryption and hashing algorithms and the Diffie-Hellman group that is used to create the main mode SA and to help secure the IKE negotiation channel. Security methods are also used during the quick mode negotiation to define the encapsulation mode (transport or tunnel), IPsec protocol wire format (AH or ESP), encryption and hashing algorithms, and key lifetimes that are used to create the quick mode inbound and outbound SAs.
IPsec Encapsulation Modes and Protocol Wire Formats
IPsec helps protect data in an IP packet by providing cryptographic protection of an IP payload. The protection that is provided depends on the mode in which IPsec is used and the protocol wire format. You can use IPsec in transport mode or tunnel mode.
IPsec Encapsulation Modes
IPsec tunnel mode is most commonly used to help protect site-to-site (also known as gateway-to-gateway or router-to-router) traffic between networks, such as site-to-site networking through the Internet. When IPsec tunnel mode is used, the sending gateway encapsulates the entire, original IP packet by creating a new IP packet that is then protected by one of the IPsec protocol wire formats (AH or ESP). For information about IPsec in tunnel mode, see the “Deploying IPsec” chapter in the Windows Server 2003 Deployment Kit.
IPsec transport mode is used to help protect host-to-host communications, and it is the default mode for Windows IPsec. When IPsec transport mode is used, IPsec encrypts only the IP payload; the IP header is not encrypted. Windows IPsec is used in transport mode primarily to help protect end-to-end communication (such as communications between clients and servers).
IPsec Protocol Wire Formats
IPsec supports two protocol wire formats: AH or ESP. IPsec transport mode encapsulates the original IP payload with an IPsec header (AH or ESP).
AH
AH provides data origin authentication, data integrity, and anti-replay protection for the entire packet (both the IP header and the data payload carried in the packet), except for the fields in the IP header that are allowed to change in transit. AH does not provide data confidentiality, which means that it does not encrypt the data. The data is readable but protected from modification and spoofing.
As shown in the following figure, integrity and authentication are provided by the placement of the AH header between the IP header and the TCP data.
Figure A.1 Authentication header in a packet
To use AH, in the properties for the appropriate rule, in the Custom Security Method Settings dialog box, select the Data and address integrity without encryption (AH) check box, and then specify the integrity algorithm to use.
ESP
ESP provides data origin authentication, data integrity, anti-replay protection, and the option of confidentiality for the IP payload only. ESP in transport mode does not protect the entire packet with a cryptographic checksum. The IP header is not protected. As shown in the following figure, the ESP header is placed before the TCP data, and an ESP trailer and ESP authentication trailer are placed after the TCP data.
Figure A.2 ESP data in a packet
To use ESP, in the properties for the appropriate rule, in the Custom Security Method Settings dialog box, select the Data integrity and encryption (ESP) check box, and then specify the integrity and encryption algorithms to use.
IKE Authentication
IKE uses mutual authentication between computers to establish trusted communications and requires the use of one of the following authentication methods: Kerberos version 5 protocol, a computer X.509 version 3 public key infrastructure (PKI) certificate, or a preshared key. The two communication endpoints must have at least one common authentication method, or communication fails.
IKE Authentication Process
During IKE negotiation, the IKE initiator proposes a list of authentication methods to the IKE responder. The responder uses the source IP address of the initiator to identify which filter controls the IKE negotiation. The authentication method list that corresponds to the filter in the responder’s IPsec policy is used to select one authentication method from the initiator’s list. The responder then replies to inform the initiator of the agreed-upon authentication method. If the selected authentication method fails, IKE does not provide a method for trying a different authentication method. If authentication is successful and the main mode negotiation is successfully completed, the main mode SA lasts for eight hours. If data is still being transmitted at the end of eight hours, then the main mode SA is renegotiated automatically.
IKE Authentication Methods
It is important to choose the authentication method that is appropriate for your IPsec policy. An IPsec policy rule associates each IP address in a filter with an authentication method list so that IKE can determine which authentication method list to use with each IP address.
Kerberos Version 5 Protocol Authentication
The Kerberos version 5 protocol is the default authentication standard in Windows 2000 and Windows Server 2003 Active Directory domains. Any computer in the domain or in a trusted domain can use this method of authentication.
When Kerberos authentication is used, during main mode negotiation each IPsec peer sends its computer identity in unencrypted format to the other peer. The computer identity is unencrypted until encryption of the entire identity payload takes place during the authentication phase of the main mode negotiation. An attacker can send an IKE packet that causes the responding IPsec peer to expose its computer identity and domain membership. For this reason, to help secure computers that are connected to the Internet, certificate authentication is recommended.
By default, in Windows 2000 through Service Pack 3 and in Windows XP, Kerberos protocol traffic is exempt from IPsec filtering. To remove the exemption for Kerberos protocol traffic, you must modify the registry and then add an appropriate IPsec filter to help secure this traffic. For information about the default exemptions in Windows 2000 and Windows Server 2003, consult Special IPsec considerations.
Public Key Certificate Authentication
In Windows 2000 Server, you can use Certificate Services to automatically manage computer certificates for IPsec throughout the certificate lifecycle. Certificate Services is integrated with Active Directory and Group Policy, and it simplifies certificate deployment by enabling certificate auto-enrollment and renewal and by providing several default certificate templates that are compatible with IPsec. To use certificates for IKE authentication, you define an ordered list of acceptable root certificate authorities (CAs) to use, not which specific certificate to use. Both computers must have a common root CA in their IPsec policy configuration, and clients must have an associated computer certificate.
During the certificate selection process, IKE performs a series of checks to help ensure that specific requirements are met for the computer certificate. For example, the computer certificate must have a public key length that is greater than 512 bits and use a Digital Signature key usage.
Note Certificates obtained from Certificate Services with the advanced option set for Enable strong private key protection do not work for IKE authentication because you cannot enter the required personal identification number (PIN) to access the private key for a computer certificate during IKE negotiation.
Preshared Keys
If you are not using Kerberos authentication and do not have access to a CA, a preshared key can be used. For example, a stand-alone computer on a network might need to use a preshared key because neither Kerberos authentication (through the computer’s domain account) nor certificates from a CA can enable successful IKE authentication in some scenarios.
Important: Preshared keys are easily implemented but can be compromised if they are not used correctly. Microsoft does not recommend the use of preshared key authentication in Active Directory because the key value is not securely stored, and it is therefore difficult to keep secret. The preshared key value is stored in plaintext in an IPsec policy. Any member of the local Administrators group can view a local IPsec policy, and a local IPsec policy can be read by any system service with Local System user rights. By default, any authenticated user in the domain can view a preshared key if it is stored in an Active Directory-based IPsec policy. Additionally, if attackers can capture IKE negotiation packets, published methods can enable the attackers to discover preshared key values.
For more information, see "Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets" authored by John Pliam of the Institute for Mathematics and its Applications.
Preshared key authentication is provided for interoperability purposes and compliance with RFC standards. If you must use preshared key authentication, use a 25-character or longer random key value and a different preshared key for each IP address pair. These practices result in different security rules for each destination and help ensure that a compromised preshared key compromises only those computers that share the key.
IPsec CRL Checking
If you use certificate-based authentication, you can also enable IPsec certificate revocation list (CRL) checking. By default in Windows 2000, IPsec CRLs are not automatically checked during IKE certificate authentication.
To enable IPsec CRL checking
Caution: Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
1. Under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\, add a new Oakley key, with a DWORD entry named StrongCrlCheck.
2. Assign this entry any value from 0 through 2, where:
a. A value of 0 disables CRL checking (default for Windows 2000).
b. A value of 1 causes CRL checking to be attempted and certificate validation to fail only if the certificate is revoked (default for Windows XP and Windows Server 2003). Other failures that are encountered during CRL checking (such as the revocation URL being unreachable) do not cause certificate validation to fail.
c. A value of 2 enables strong CRL checking, which means that CRL checking is required and that certificate validation fails if any error is encountered during CRL processing. Set this registry value for enhanced security.
3. Do one of the following:
a. Restart the computer.
b. Stop, and then restart the IPsec service by running the net stop policyagent and net start policyagent commands at a command prompt.
Note IPsec CRL checking does not guarantee that certificate validation fails immediately when a certificate is revoked. There is a delay between the time that the revoked certificate is placed on an updated and published CRL and the time when the computer that performs the IPsec CRL checking retrieves this CRL. The computer does not retrieve a new CRL until the current CRL has expired or until the next time the CRL is published. CRLs are cached in memory and in \Documents and Settings\UserName\Local Settings\Temporary Internet Files by CryptoAPI. Because CRLs persist across computer restarts, if a CRL cache problem occurs, restarting the computer does not resolve the problem.
IKE Authentication Methods and Security Method Preference Order
You can configure an IPsec rule to specify only one authentication method or one security method. Alternatively, you can specify a preferred list of authentication and security methods. Preference order applies to authentication methods and security methods so that you can specify each method from most preferred to least preferred. For example, you can specify that both the Kerberos version 5 protocol and public key certificate authentication are offered as authentication methods but give the Kerberos protocol the higher preference, as shown in the following figure.
Figure A.3 Authentication method preference order
If a client attempts to connect to CORPSRV but only accepts public key certificates for authentication, then CORPSRV uses this authentication method and continues establishing communication. IKE must succeed using the selected authentication method, or the communication is blocked. IKE does not attempt to use a different authentication method if the negotiation fails. The same principle applies to security methods, where, for example, ESP might be preferred over AH.
Security Negotiation Options
You can configure whether an IPsec policy allows Fall back to clear (fall back to unsecured communication), Inbound passthrough, and Session key PFS on the Security Methods tab, in the properties for a filter action. You can configure Master key PFS in the Key Exchange Settings dialog box, in the general properties for a rule.
Fall Back to Clear
When Fall back to clear is allowed, traffic is secured by IPsec when possible (if the computer at the other end of the connection supports IPsec with a complementary filter action and filter in its policy), but traffic can be sent unsecured if the peer does not have an IPsec policy to respond to the request for security negotiation. If the peer does not respond to the request for security negotiation within three seconds, an SA for plaintext traffic (a soft SA) is created. Soft SAs allow normal TCP/IP communication with no IPsec encapsulation to occur. Keep in mind that although IPsec might not secure such traffic, another application might help secure the traffic (for example, traffic might be secured by Lightweight Directory Access Protocol (LDAP) encryption or remote procedure call (RPC) authentication mechanisms). If the peer does respond within three seconds and the security negotiation fails, the communication that matches the corresponding filter is blocked.
Fall back to clear is a setting that allows interoperability with the following:
· Computers running operating systems earlier than Windows 2000
· Computers running Windows 2000 or later systems that do not have IPsec policy configured
· Computers running non-Microsoft operating systems that do not support IPsec
To enable or disable Fall back to clear, on the Security Methods tab, in the properties for a filter action, select or clear the Allow unsecured communication with non-IPsec-aware computers check box.
For client policy, you can either enable or disable this option. If you enable this option and the server does not respond to the client’s request to negotiate security, you can allow the client to Fall back to clear. If you clear this check box, and if the server does not respond to the client’s request to negotiate security, communication is blocked. In some cases, it is useful to allow Fall back to clear. However, IKE allows Fall back to clear only if there is no reply. For security reasons, Windows IPsec does not allow unsecured communication if the IKE negotiation fails or if an error is experienced during an IKE negotiation (after the reply), such as failure to authenticate or to reach agreement on security parameters.
For initial deployments, it is recommended that you select this check box so that the client can Fall back to clear and initial connectivity can be established when IPsec is disabled on the server.
Inbound Passthrough
When Inbound passthrough is allowed, normal inbound TCP/IP traffic (traffic that is not secured by IPsec, for example a TCP SYN packet) is accepted if it matches the inbound filter associated with the filter action. The upper-layer protocol response packet (for example, a TCP SYN ACK packet) matches the corresponding outbound filter and triggers a security negotiation. Two IPsec SAs are then negotiated, and the traffic is IPsec-secured in both directions. The Inbound passthrough option allows a server to use the default response rule to initiate the security negotiation to clients. When you enable the default response rule in the client IPsec policy, clients do not need to maintain a filter that contains the IP address of the server. If you do not enable the default response rule in the client IPsec policy, then you do not need to enable the Inbound passthrough option in the server IPsec policy. Additionally, you should never enable this option on computers connected to the Internet.
To enable or disable Inbound passthrough, on the Security Methods tab, in the properties for a filter action, select or clear the Allow unsecured communication, but always respond using IPsec check box.
Session Key and Master Key PFS
PFS is a mechanism that determines whether the existing keying material for a master key can be used to derive a new session key. PFS helps ensure that the compromise of a single key permits access only to data that is protected by PFS, not necessarily to the entire communication. To achieve this, PFS helps ensure that a key used to protect a transmission cannot be used to generate additional keys. Session key PFS can be used without a reauthentication and is less resource-intensive than master key PFS. When session key PFS is enabled, a new Diffie-Hellman key exchange is performed to generate new master key keying information.
If you enable session key PFS in a server policy, you must also enable it in the client policy. You can enable session key PFS by selecting the Use session key perfect forward secrecy (PFS) check box, in the Key Exchange Settings dialog box, in the general properties for a rule. Master key PFS requires a reauthentication and is resource-intensive. It requires a new main mode negotiation for every quick mode negotiation that occurs. You can configure master key PFS by selecting the Master key perfect forward secrecy (PFS) check box. If you enable master key PFS in a server policy, you do not need to enable it in the client policy. Because there is significant overhead in enabling this option, it is recommended that you enable session key PFS or master key PFS only in hostile environments where IPsec traffic might be exposed to sophisticated attackers who will try to compromise the strong cryptographic protection provided by IPsec.
Appendix B: IPsec Policy Summary
This appendix provides a concise listing of information about all policy settings for the isolation groups used in this solution.
General Policy Configuration
The following information is contained in all of the policies that are defined in this solution.
Policy General Settings
· Policy refresh: 5 minutes for test environment rollout. This value should be increased to 60 minutes in production. After 60 minutes, the host refreshes its policy from the Active Directory® directory service. This functionality allows changes to an already assigned IPsec policy to be deployed to the entire organization's network in (at most) an hour, making it possible to quickly respond to any compromises of the network.
· IKE Main Mode Lifetime: 3 hours.
· Sessions Per MM: 0, infinite.
· Master PFS: Not used, this has been deprecated as a feature in Microsoft® Windows® Internet Key Association (IKE) because of lack of support in other products and to eliminate duplicate functionality. The same functionality can be accomplished by setting the Sessions per MM to 1.
· IKE MM Key Exchange security methods: 3DES/SHA1/High (2048), 3DES/SHA1/Medium (2), 3DES/MD5/Medium (2).
Note High (2048) is supported only by Microsoft Windows Server™ 2003 and Windows XP SP2, and will be ignored by Windows 2000 and earlier versions of Windows XP. Windows 2000 and Windows XP SP1 and earlier IKE compatibility is ensured by using Medium (2).
· Default Response Rule = disabled
Rule 1
Filter List: "IPSEC - Cluster VIP Exemption List"
Filter: My <-> Specific IP Address, Mirrored – Currently Empty
Description: "IP addresses for all Cluster VIPs in the organization"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 2
Filter List: "IPSEC - DHCP, Negotiation Traffic"
Filter: My <-> Any, UDP, SRC Port 68 to DST Port 67, Mirrored
Description: "Allows DHCP Negotiation traffic"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 3
Filter List: "IPSEC - DNS Exemption List"
Filter: Any <-> 192.168.1.21, Mirrored
Any <-> 192.168.1.22, Mirrored
Description: "IP Addresses for all DNS servers in the organization"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 4
Filter List: "IPSEC - Domain Controller Exemption List"
Filter: Any <-> 192.168.1.21, Mirrored
Any <-> 192.168.1.22, Mirrored
Description: "IP addresses for all DCs in organization"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 5
Filter List: "IPSEC - WINS Exemption List"
Filter: Any <-> 192.168.1.22, Mirrored
Description: "IP Addresses for all WINS servers in the organization"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 6
Filter List: "IPSEC - LOB Application Servers Exemption List"
Filter: Any <-> 192.168.1.10, Mirrored
Description: "IP Addresses for all LOB servers in the organization"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 7
Filter List: "IPSEC - ICMP, All Traffic"
Filter: My <-> Any, ICMP, Mirrored
Description: "Allows ICMP traffic"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 8
Filter List: "IPSEC - Exempt Addresses"
Filter: Any <-> Specific IP Address, Mirrored – Currently Empty
Description: "Specific IP addresses to be exempted from IPsec communication"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 9
Filter List: "IPSEC - Exempt Subnets"
Filter: My <-> Specific IP Subnet, Mirrored – Currently Empty
Description: "Subnets to be exempted from IPsec communication"
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule 10
Filter List: "IPSEC - Policy Version: (1.0.041001.1600)"
Filter: 1.1.1.1 <-> 1.1.1.2, ICMP, Mirrored
Description: "Not a real filter list. Used to identify IPsec policy version."
Filter Action: IPSEC-Permit
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
Rule Behavior Explained
Rule 1 This rule is required to exempt outbound communication to the cluster VIPs. This rule should not be included if there is no need for this server to communicate to the cluster VIPs.
Rule 2. This rule permits non-IPsec Dynamic Host Configuration Protocol (DHCP) negotiation to be used.
Rule 3. This rule permits non-IPsec communication to Domain Name System (DNS) systems in the exemption list.
Rule 4. This rule permits non-IPsec communication to domain controller systems in the exemption list.
Rule 5. This rule permits non-IPsec communication to Windows Internet Naming Service (WINS) systems in the exemption list.
Rule 6. This rule permits non-IPsec communication to hosts in the exemption list. Woodgrove Bank created this filter list for their line of business application servers.
Rule 7. This rule permits the use of non-IPsec Internet Control Message Protocol (ICMP) traffic.
Rule 8. This rule permits non-IPsec communication to hosts in the exemption list. This rule is not to be included in the policies if the filter list is empty.
Rule 9. This rule permits non-IPsec communication to subnets in the exemption list. This rule is not included in the policies if the filter list is empty.
Rule 10. This rule is only used to track versioning information for the policy. The filter used to implement the filter list is a dummy filter that consists of two specific IP addresses that permit ICMP traffic. This dummy filter is required because one cannot add an empty filter list to a policy.
Isolation Domain Policy
This section provides the details of the filters, filter actions, policy, and Group Policy objects (GPO) used to create the Isolation Domain in the solution for Woodgrove Bank.
Rule 11
Filter List: IPSEC – Organizational Subnets
Filter: Any <-> internal subnets, all traffic, mirrored
Filter Action: "IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound)"
Security Method Preference Order: ESP-null/SHA1, ESP-null/MD5,
ESP-3DES/SHA1 then ESP-3DES/MD5
DO NOT Accept unsecured communications
Allow unsecured communication with non-IPsec-aware hosts
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
All other policy settings are the same as listed in the "General Policy Configuration" section earlier in this appendix.
Rule Behavior Explained
Rule 11. This rule is the most general rule defined in the policy. It matches traffic destined to secure subnets and requests that IPsec be negotiated. It will not accept unsecured communication from non-IPsec-aware clients, but it can communicate with non-IPsec-aware clients if it initiates the communication.
No Fallback Isolation Group Policy
This section provides the details of the filters, filter actions, policy, and GPOs used to create the No Fallback isolation group in the solution for Woodgrove Bank.
Rule 11
Filter List: IPSEC – Organizational Subnets
Filter: Any <-> internal subnets, all traffic, mirrored
Filter Action: "IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound)"
Security Method Preference Order: ESP-null/SHA1, ESP-null/MD5,
ESP-3DES/SHA1 then ESP-3DES/MD5
DO NOT Accept unsecured communications
DO NOT Allow unsecured communication with non-IPsec-aware hosts
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
All other policy settings are the same as listed in the "General Policy Configuration" section earlier in this appendix.
Rule Behavior Explained
Rule 11. This rule is the most general rule defined in the policy. It matches traffic destined to secure subnets and requires that IPsec be negotiated. It does not allow any communication with non-IPsec-aware clients.
Boundary Isolation Group Policy
This section provides the details of the filters, filter actions, policy, and GPOs used to create the Boundary isolation group in the solution for Woodgrove Bank.
The boundary host is assumed not to be mobile and therefore can use subnets to define its network and should be secured almost as a Bastion Host in the Windows Server 2003 security guide. It must be highly protected against untrusted attack. Consequently, the IPsec policy should be merged with filters that reduce the attack surface where possible.
Policy General Settings:
IKE Main Mode Lifetime: 20 Minutes
Rule 11
Filter List: IPSEC – Organizational Subnets
Filter: Any <-> internal subnets, all traffic, mirrored
Filter Action: "IPSEC – Request Mode (Accept Inbound, Allow Outbound)"
Security Method Preference Order: ESP-null/SHA1, ESP-null/MD5,
ESP-3DES/SHA1 then ESP-3DES/MD5
Accept unsecured communications
Allow unsecured communication with non-IPsec-aware hosts
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
All other policy settings are the same as listed in the "General Policy Configuration" section earlier in this appendix.
Rule Behavior Explained
Rule 11. This rule is the most general rule defined in the policy. It matches traffic destined to secure subnets and requests that IPsec be negotiated. It will accept traffic from non-IPsec-aware clients as well as initiate communication to said clients.
Encryption Isolation Group Policy
This section provides the details of the filters, filter actions, policy, and GPOs used to create the Encryption isolation group in the solution for Woodgrove Bank.
Rule 11
Filter List: IPSEC – Organizational Subnets
Filter: Any <-> internal subnets, all traffic, mirrored
Filter Action: "IPSEC – Require Encryption Mode (Ignore Inbound, Disallow
Outbound)"
Security Method Preference Order: ESP-3DES/SHA1, then ESP-3DES/MD5
DO NOT Accept unsecured communications
DO NOT Allow unsecured communication with non-IPsec-aware hosts
Authentication: Kerberos
Tunnel: No
Connection Type: ALL
All other policy settings are the same as listed in the "General Policy Configuration" section earlier in this appendix.
Rule Behavior Explained
Rule 11. This rule is the most general rule defined in the policy. It matches traffic destined to secure subnets and requires that Encrypted IPsec be negotiated. It does not allow any communication with non-IPsec-aware clients.
This appendix provides complete guidance for building the required infrastructure to support isolation groups that use IPsec. This guidance discusses installation and configuration of Microsoft® Windows Server™ 2003, preparation of the Active Directory® directory service, and configuration of IPsec policy.
This appendix also provides the implementation instructions that were used to roll out the baseline IPsec policy for the Woodgrove Bank scenario, which is described earlier in this guide.
This appendix is intended to be used in conjunction with the other chapters in this guide, which explain the design process and rationale behind the implementation decisions that are used in this appendix. This appendix also explains the tasks and processes that are needed to successfully create and implement a baseline IPsec policy infrastructure. If you have not already done so, it is strongly recommended that you read the previous chapters before continuing with this appendix. You should also read and understand the implications of the support requirements detailed in Chapter 6, "Managing a Server and Domain Isolation Environment," before implementing the guidance in this appendix.
Prerequisites
This section contains information that will help you determine your organization's readiness to implement the solution.
Knowledge Prerequisites
You should be familiar with concepts of IPsec, networking, and network architectures. Familiarity with Windows Server 2003 is also required in the following areas:
· Installation of the operating system.
· 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.
Before proceeding with this appendix, you should also have read the planning guidance provided in this guide and have a thorough understanding of the architecture and design of the solution.
Organizational Prerequisites
You should consult with other people in your organization that may need to be involved in the implementation of this solution. Such people might include the following:
· Business 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 The structure of your IT organization will determine whether these roles may be filled by a number of people or whether fewer people span several roles.
IT Infrastructure Prerequisites
The appendix also assumes that the following IT infrastructure exists:
· A 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 does not run 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, it was not used in this solution.
Note Windows Server 2003 introduced a number of improvements that affect IPsec policies. There is nothing specific to Windows Server 2003 that would prevent this solution from working properly with Windows 2000. However, this 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.
· Server hardware that is adequate to run Windows Server 2003.
· Windows Server 2003 Standard Edition and Enterprise Edition licenses, installation media, and product keys.
Baseline Implementation Prerequisites
Before the tasks in this appendix are performed, there are a number of items that should be in place to ensure a successful deployment.
Hardware Requirements
Before the baseline IPsec infrastructure is rolled out, ensure that the current infrastructure is physically capable of supporting the overhead of the IPsec implementation. The process that will help you verify this capability is discussed in Chapter 3, "Determining the Current State of Your IT Infrastructure," of this guide.
Tools
Four primary tools can be used to configure the IPsec policies and enable them through Active Directory GPOs. These tools are:
· Netsh. This command-line tool is provided with Windows Server 2003. It is used to configure both local policy on a Windows Server 2003 system and domain policy. This solution uses Netsh scripts to configure the domain policies.
· Group Policy Management Console (GPMC). This tool is an add-on Group Policy management tool that simplifies the administration of Group Policy across the enterprise. Download the Group Policy Management Console with Service Pack 1 tool.
· IP Security Policy Management Console. This tool allows the administrator to create, view, or modify IPsec policies, filter actions and filter lists. Although it is a Microsoft Management Console (MMC) snap-in, it does not appear in the default listing of Administrative Tools on the computer. To use it, run mmc.exe at a command prompt and add the snap-in manually.
· IP Security Monitor Management Console. This tool allows an administrator to view the various rules applied to a computer in addition to main mode and quick mode security associations (SAs) that have been associated with it. Like the IP Security Management Console, this tool does not appear by default in the Administrative Tools menu but must be loaded manually through the mmc.exe program.
It is recommended that these tools be obtained and installed on the implementation team workstations so that team members can spend some time to familiarize themselves with the functionality of each tool before implementation begins.
Deployment of the Baseline Policy
Woodgrove Bank chose to implement their deployment by first moving all computers into the Boundary isolation group by using the build-up method. This approach allowed administrators to move forward slowly and resolve any outstanding issues without significant impact on the communication between computers. By first deploying a policy without any secure subnets, the administration team was able to identify any computers that had a local IPsec policy assigned and consider that information. As subnets were added to the policy, any additional conflicts that were found were resolved.
After the computers were operating under the Boundary Isolation Group Policy, the team moved on to implement the Standard, Outbound Clear Allowed, and Encryption isolation groups. These isolation groups were deployed by using the "deployment by group" method that is explained in Chapter 4, "Designing and Planning Isolation Groups," of this guide. A set of computers were selected for a pilot and added to the appropriate groups that controlled the new policies. Any issues were resolved and additional computers were added to the groups until the isolation groups were fully populated.
Implementing the IPsec Policies
The process of getting the correct IPsec policy to each intended computer in a large organization can quickly become complex. The policy mechanism that is available in Active Directory can greatly simplify this process. The following sections in this appendix provide the information required to implement the IPsec policies.
Copying Configuration Scripts
To set up the IPsec policies, the first task is to copy the required configuration scripts to the domain controller that will be used to store them. The configuration scripts provided with the solution were used to configure the Woodgrove Bank lab. In the Woodgrove Bank scenario, the following steps were performed:
To copy configuration scripts
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Create the folder C:\IPsec Scripts.
3. Copy the script files from this solution's Tools and Templates folder to the C:\IPsec Scripts folder.
Installing the Group Policy Management Console
The GPMC is used to install and configure the GPOs that are used by the solution. The GPMC only needs to be installed on IPS-CH-DC-01; its installation on subsequent servers is optional.
Note Installation of the GPMC slightly changes the user interface of the Active Directory Users and Computers MMC for the computer on which it is installed. For more information about using the GPMC, and to download the installation file, see the Group Policy Management Console with Service Pack 1 page on the Microsoft Download Center.
To install the Group Policy Management Console
1. Download the Gpmc.msi installation file from the Microsoft Download Center.
2. Ensure that you are logged on as a member of the domain Administrators group on IPS-CH-DC-01.
3. From Windows Explorer, double-click the Gpmc.msi installation file.
4. Follow the setup wizard prompts to install the GPMC; accept all defaults.
Important: You should install GPMC in the Program Files folder; it does not matter which drive the folder is on. You should also use the default installation folder (GPMC) within the Program Files folder. If you change the folder name, you must update its name in the Constants.txt file. Later procedures use some of the tools installed by GPMC, and if you install it elsewhere they will be unable to locate the GPMC tools unless this file is updated.
Implementing IPsec Filter Lists and Filter Actions
Creation of the IPsec filter lists and filter actions is accomplished by using either the Netsh tool or the IP Security Policy Management MMC snap-in.
Although the IP Security Policy Management MMC snap-in provides a graphical interface for IPsec, many administrators find it easier to maintain and update scripts that use the Netsh command-line tool. In addition, the scripts can be easily ported across domains or forests. In this solution, Netsh scripts were used to implement the IPsec filter lists and filter actions.
Note Test any scripts against the local policy stores on a computer that runs Windows Server 2003 by setting the store focus on local. After the scripts are debugged, modify the store configuration to focus on the domain for final import.
To create the IPsec filter lists and filter actions
1. Log on to the IPS-CH-DC-01 domain as a domain administrator of the Americas domain.
2. Open a command prompt, type the following, and then press ENTER:
netsh –f "c:\IPsec Scripts\PacketFilters.txt"
Note If any empty filter lists are created through the script, the following error message will display at the command line: ERR IPsec [05022]: No filters in FilterList with name "<Filter List Name>. This message can be ignored safely.
3. Launch the IP Security Policy Management MMC snap-in and confirm that the filter lists and filter actions have been created in Active Directory.
Note To test against local policy, ensure that the script being run in step 2 is configured with set store location=local. In step 3, ensure that the MMC snap-in is focused on the local computer rather than the domain.
Implementing IPsec Policies
After the filter lists and filter actions have been created, the scripts that create the IPsec policies can be run.
Note The policies created by the scripts are configured with a polling interval of five minutes for testing purposes.
The following table lists the policy name and the script file that creates the policy. This script file name will be used in step 2 of the following procedure.
Table C.1 IPsec Policy to Script File Mapping
| IPsec policy name | Script file name |
| IPSEC – Boundary Isolation Group IPsec Policy (1.0.041001.1600) | BoundaryIGPolicy.txt |
| IPSEC – No Fallback Isolation Group IPsec Policy (1.0.041001.1600) | NoFallbackIGPolicy.txt |
| IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600) | IsolationDomainPolicy.txt |
| IPSEC – Encryption Isolation Group IPsec Policy (1.0.041001.1600) | EncryptionIGPolicy.txt |
To create the IPsec policies
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Open a command prompt. For each policy, type the following, and then press ENTER:
netsh –f "c:\IPsec Scripts\<Script Filename>"
Note If a filter list is empty, Netsh will display an error beginning with "ERR IPsec [05022]…" This message can be ignored safely.
3. Launch the IP Security Policy Management MMC snap-in and confirm that the IPsec policies have been created in Active Directory.
Note To test against local policy, ensure that the script being run in step 2 is configured with set store location=local. In step 3, ensure that the MMC snap-in is focused on the local computer rather than the domain.
Creating GPOs for IPsec Policies
Woodgrove Bank created four GPOs to deliver IPsec policies. Each of these GPOs was named after the IPsec policy to which it is assigned within the GPO. Until the policies are linked within Active Directory, these GPOs will not deliver any IPsec policies to the environment.
The following table lists each GPO name and the IPsec policy name being delivered by that GPO.
Table C.2 Woodgrove Bank GPO to IPsec Mapping
| GPO name | IPsec policy name |
| IPSEC – Boundary Isolation Group Policy | IPSEC – Boundary Isolation Group IPsec Policy (1.0.041001.1600) |
| IPSEC – No Fallback Isolation Group Policy | IPSEC – No Fallback Isolation Group IPsec Policy (1.0.041001.1600) |
| IPSEC – Isolation Domain Policy | IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600) |
| IPSEC – Encryption Isolation Group Policy | IPSEC – Encryption Isolation Group IPsec Policy (1.0.041001.1600) |
To create the GPOs for IPsec policies
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Launch the GPMC.
3. Expand Forest: corp.woodgrovebank.com, expand the domain, and then expand americas.corp.woodgrovebank.com.
4. Right-click Group Policy Objects, and then click New.
5. In the Name text box, type <GPO name> and then click OK.
6. Right-click <GPO name>, and then click Edit.
7. Expand Computer Configuration, expand Windows Settings, expand Security Settings, and then click IP Security Policies on Active Directory (corp.woodgrovebank.com).
8. In the right pane, right-click <IPsec policy name>, and then click Assign.
9. Ensure that <IPsec policy name> is assigned, and then close the GPO editor.
10. Repeat steps 4-9 for each <GPO name> and <IPsec policy name> combination from the previous table.
Setting the Security on the IPsec Group Policies
Woodgrove Bank used security ACLs on the GPO that contains the IPsec policies to control the application of the policies. The primary benefit was that the policies could be linked at the domain level rather than through multiple organizational units (OUs), which simplified the management of policy application. Furthermore, a staged roll out was implemented without moving any computer accounts to special OUs. Instead, the computer accounts that participated in the pilot were added to the appropriate groups. The drawback is that the organization must have good group management tools.
Creating Groups
A set of groups was created to control how policy was applied throughout the Woodgrove Bank organization. Because the Woodgrove Bank forest was in Native mode, universal groups were used to control policy across all domains.
Table C.3 Woodgrove Bank Universal Groups
| GPO name | IPsec policy name |
| CG_NoIPsec_computers | A universal group that consists of computer accounts that do not participate in the IPsec environment—typically infrastructure computer accounts. |
| CG_BoundaryIG_computers | A universal group that consists of computer accounts that are allowed to communicate with untrusted computers. |
| CG_ EncryptionIG_computers | A universal group that consists of computer accounts that are in the Encryption isolation group. |
| CG_ IsolationDomain_computers | A universal group that consists of computer accounts that are part of the Isolation Domain. |
| CG_NoFallbackIG_computers | A universal group that consists of computer accounts that are part of the No Fallback isolation group. |
To create the Woodgrove Bank universal groups
1. Launch Active Directory Users and Computers on IPS-CH-DC-01.
2. Right-click the Users container, click New, and then click Group.
3. In the Group Name text box, type the first <Group name> from the previous table.
4. Select Universal security group, and then click OK.
5. Repeat steps 2-4 for each group.
6. Right-click the first <Group name>, and then click Properties.
7. In the Description text box, type the first <Description> from the previous table.
8. Click OK.
9. Repeat steps 6-8 for each of the groups listed in the previous table.
Configuring GPO Security
Groups are used to control which computers get what policies for IPsec participation. The security ACLs need to be configured on each of the newly-created IPsec policies so that the appropriate groups are configured. The following table shows the ACLs to be added to each GPO.
Note If an organization is going to delegate administrative rights to someone other than the Domain Admins group to manage IPsec policies, the delegated administrative group will need to be granted Full Control on the IP Security container in Active Directory.
Table C.4 Woodgrove Bank Policy Group Permissions
| GPO name | Group or account name | Rights assigned |
| IPSEC - Boundary Isolation Group Policy | CG_NoIPsec_computers | Deny Apply Group Policy |
| CG_BoundaryIG_computers | Allow Read and Apply Group Policy | |
| IPSEC – No Fallback Isolation Group Policy | CG_NoIPsec_computers | Deny Apply Group Policy |
| CG_NoFallbackIG_computers | Allow Read and Apply Group Policy | |
| IPSEC – Isolation Domain Policy | CG_NoIPsec_computers | Deny Apply Group Policy |
| CG_ IsolationDomain_computers | Allow Read and Apply Group Policy | |
| IPSEC – Encryption Isolation Group Policy | CG_NoIPsec_computers | Deny Apply Group Policy |
| CG_ EncryptionIG_computers | Allow Read and Apply Group Policy |
Note The Boundary Isolation Group Policy is configured to allow the Domain Computers group to apply the policy for the initial build-up process by placing the Domain Computers group in the CG_BoundaryIG_computers group. After all computers are moved to their respective groups, domain computers will be removed from the CG_BoundaryIG_computers group.
To set the group permissions on the GPO
1. Launch the GPMC on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand Forest: corp.woodgrovebank.com, expand the domain, expand americas.corp.woodgrovebank.com, and then expand Group Policy Objects.
3. Click the first <GPO name> from the previous table, and then click the Delegation tab.
4. Click the Advanced button.
5. In the Group or user name scroll box, click Authenticated Users, and clear the Allow right Apply Group Policy check box.
6. Click the Add button.
7. In the Enter the object names to select text box, enter each <Group or account name> from the previous table, separated by semicolons, and then click OK.
8. In the Group or user names text box, select <Group or account name>, and then set the <Rights assigned> in the Permissions check boxes.
9. Repeat step 8 for each <Group or account name> associated with the <Policy name>.
10. Click OK.
11. If the right being assigned is a Deny right, click Yes when the message box is shown; otherwise, proceed to step 12.
12. Repeat step 3-11 for each <Policy name>.
Note Ensure that the entry for Authenticated Users was granted only Read permissions in the security ACL for each policy. If Apply permissions are also granted, the policy will be deployed to all computers.
Blocking Boundary Isolation Group Computers from Initiating Connections to Encryption Isolation Group Computers
Woodgrove Bank required that computers in the Boundary isolation group be prevented from initiating communications with computers in the Encryption isolation group. To implement this restriction, a group called DNAG_EncryptionIG_computers is created to deny its members access to computers in the Encryption isolation group. The Encryption Isolation Group Policy was configured so that DNAG_EncryptionIG_computers was granted the "Deny access to this computer from the network" right, and the CG_BoundaryIG_computers group was placed in the DNAG_EncryptionIG_computers group. This configuration was accomplished by modifying the IPSEC – Encryption Isolation Group Policy GPO.
To create the DNAG_EncryptionIG_computers group
1. Launch Active Directory Users and Computers on IPS-CH-DC-01.
2. Right-click the Users container, click New, and then click Group.
3. In the Group name text box, type DNAG_EncryptionIG_computers
4. Select the Domain local security group, and then click OK.
5. Right-click DNAG_EncryptionIG_computers, and then click Properties.
6. In the Description text box, type Used to Deny Access to Encryption Isolation Group
7. Click OK.
To configure IPSEC – Encryption Isolation Group Policy to block members of DNAG_EncryptionIG_computers
1. Launch the GPMC on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand Forest: corp.woodgrovebank.com, expand the domain, expand americas.corp.woodgrovebank.com, and then expand Group Policy Objects.
3. Right-click IPSEC – Encryption Isolation Group Policy and then click Edit.
4. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then expand User Rights Assignment.
5. Right-click Deny access to this computer from the network, and then click Properties.
6. Select the Define these policy settings check box.
7. Click the Add User or Group button.
8. Click the Browse button.
9. In the text field, type DNAG_EncryptionIG_computers and then click OK.
10. Click OK again.
11. Click OK to close the Properties page.
12. Close the Group Policy Editor.
13. Close the GPMC.
To populate the DNAG_EncryptionIG_computers group with the CG_BoundaryIG_computers group
1. Launch Active Directory Users and Computers on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the DNAG_EncryptionIG_computers security 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 CG_BoundaryIG_computers and then click OK.
6. Click OK.
Adding Domain Computers to the Boundary Group
For the initial deployment, the Boundary isolation group is used as the default isolation group for the IPsec-aware clients in the enterprise. The Domain Computers group is added to the CG_BoundaryIG_computers group to implement this plan.
To add domain computers to the CG_BoundaryIG_computers Group
1. Launch Active Directory Users and Computers on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the CG_BoundaryIG_computers security 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 Domain Computers and then click OK.
6. Click OK again.
Note Because of replication delays and polling frequency of the IPsec policies, there will be a delay between the time the Domain Computers group is added to the CG_BoundaryIG_computers group and when the Boundary Isolation Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information.
Adding Infrastructure Servers to the CG_NoIPSec_Computers Group
To ensure that the infrastructure servers do not receive a policy that could interrupt communication (for example, if a server's IP address changes), the following infrastructure server computer accounts were added to the CG_NoIPsec_computers security group.
· IPS-RT-DC-01
· IPS-CH-DC-01
To add infrastructure servers to the CG_NoIPsec_computers group
1. Launch Active Directory Users and Computers on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the CG_NoIPsec_computers security 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 name of each computer in the preceding list, separated with semicolons, and then click OK.
7. Click OK again.
Linking IPsec Policies and GPOs in a Domain Environment
Before IPsec policies can be distributed, they need to be linked to locations within the domain environment. Because Woodgrove Bank chose to administer the GPOs through the use of security groups, the OU structure is not overly important to policy distribution. However, if there are OUs that block policy application, the IPsec GPOs would have to be linked directly to the OUs for the policy application to work. Another alternative might be to enable policy enforcement on the domain IPsec policy GPOs.
To link the IPsec policies to the existing GPOs
1. Launch the GPMC as a domain administrator.
2. Expand the domain.
3. Right-click the domain name, and then click Link an Existing GPO.
4. In the Group Policy objects list, select all the IPSEC-named policies, and then click OK.
5. In the right pane, use the arrow keys to order the policies as shown in the following table.
Table C.5 Link Order of Group Policy Objects at the Domain Level
| Link order | Group Policy object name |
| 1 | IPSEC – Encryption Isolation Group Policy |
| 2 | IPSEC – No Fallback Isolation Group Policy |
| 3 | IPSEC – Isolation Domain Policy |
| 4 | IPSEC – Boundary isolation Group Policy |
| 5 | Default Domain Policy |
Using the Policy Build-up Method to Enable the Baseline IPsec Policy
The first task in the rollout of the IPsec infrastructure is the deployment of the Boundary Isolation Group Policy by using the policy build-up deployment method. Although the Boundary isolation group is not intended to be the Isolation Domain for all computers in the Woodgrove Bank environment, it is configured to apply to all computers for the first stage of the deployment.
Because the Boundary Isolation Group Policy allows and accepts non-IPsec communication, it was deemed the safest policy to deploy gradually into the environment. The policy was initially deployed with no secure subnets defined. This allowed the Woodgrove Bank administrators to fix any existing local IPsec policies. Next, subnets are added one by one and tested to ensure that IPsec negotiation occurred correctly.
Adding Subnets to the Secure Subnets Filter List
After the empty Boundary Isolation Group Policy was applied to the computers in the organization and any conflicts with existing local IPsec policies were resolved, Woodgrove Bank administrators began the build-up of the policy.
The build-up of the policy consisted of identifying the organizational subnets to be secured. The identified subnets were added to the policy one by one. After adding the first entry to the filter list, the filter list is added to the policy.
After each subnet was added, the policy was given time to apply to the computers in the organization and any conflicts were resolved. This process was repeated until the entire secure subnets filter list was deployed.
The following table lists the identified secure subnets used in the lab at Woodgrove Bank to closely mirror their production network:
Table C.6 Secure Subnets List for Woodgrove Bank Test Lab
| Subnet | Netmask | Description |
| 192.168.1.0 | 255.255.255.0 | Organizational LAN subnet 192.168.1.0/24 |
| 172.10.1.0 | 255.255.255.0 | Organizational LAN subnet 172.10.1.0/24 |
To create the first entry in the secure subnets filter list
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Launch the IP Security Policy Management MMC snap-in.
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 IPSEC – Organization Secure Subnets, and then click Edit.
5. Ensure that the Use Add Wizard check box is cleared.
6. Click Add.
7. On the Addresses tab, in the Source Address drop-down list, click Any IP Address.
8. In the Destination Address drop-down list, click A Specific IP Subnet, and then fill out the IP address and subnet mask boxes using the information in the previous table.
9. Ensure that the Mirrored option is selected.
10. On the Description tab, type the corresponding description from the previous table.
11. Click OK to close the IP Filters Properties dialog box.
12. Click OK to close the IP Filter List dialog box.
13. Click Close to close the Manage IP filter lists and filter actions dialog box.
To add the secure subnet filter list to the Boundary Isolation Group Policy
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Launch the IP Security Policy Management MMC snap-in.
3. Right-click IPSEC – Boundary Isolation Group IPsec Policy (1.0.041001.1600), and then click Properties.
4. On the Rules tab, ensure that the Use Add Wizard check box is not selected, and click Add.
5. On the IP Filter List tab, click IPSEC – Organization Secure Subnets.
6. On the Filter Action tab, click IPSEC – Request Mode (Accept Inbound, Allow Outbound).
7. On the Connection Type tab, ensure that the All network connections check box is selected.
8. On the Tunnel Settings tab, ensure that the This rule does not specify an IPsec tunnel check box is selected.
9. On the Authentication Methods tab, ensure that the Kerberos method is the only method that is listed.
10. Click OK to close the Edit Rule Properties dialog box.
11. Click OK to close the IPSEC – Boundary isolation group IPsec Policy (1.0.041001.1600) Properties dialog box.
12. Allow the policy to apply and then run the verification steps listed in the "Verifying the Baseline Deployment" section later in this appendix.
To add the remaining subnets to the secure subnets filter list
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Launch the IP Security Policy Management MMC snap-in.
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 IPSEC – Organization Secure Networks, and then click Edit.
5. Ensure that the Use Add Wizard check box is cleared.
6. Click Add.
7. On the Addresses tab, in the Source Address drop-down list, click Any IP Address.
8. In the Destination Address drop-down list, click A Specific IP Subnet, and then fill out the IP address and subnet mask using the information in the previous table.
9. Ensure that the Mirrored option is selected.
10. On the Description tab, type the corresponding description from the previous table.
11. Click OK to close the IP Filters Properties dialog box.
12. Click OK to close the IP Filter List dialog box.
13. Click Close to close the Manage IP filter lists and filter actions dialog box.
14. Allow the policy to apply and then run verification steps listed in the "Verifying the Baseline Deployment" section later in this appendix.
15. Repeat steps 2-14 for each subnet.
Verifying the Baseline Deployment
After the policy objects are created and deployed into Active Directory in an inactive state, a process of verification should be undertaken before configuring the baseline policy to enforce the Baseline isolation group for all computers in the organization. Verification can help minimize any potential disruption to the participating hosts if there is an error in the baseline configuration.
Functional Implementation Tests
The simplest test that can be performed to confirm IPsec functionality is to attempt to execute net view commands against computers that are in the secure organization network and against computers that are not in subnets listed in the secure organization network.
Computers that are in a secure subnet should negotiate a hard SA that will be visible within the IP Security Monitor MMC snap-in. A soft SA should be created between an IPsec participant and a computer that is not in a subnet listed in the secure organization network.
To test functionality of the IPsec policies that are applied
1. From a secured subnet computer, open a command prompt, type
net view \\<computer name>, and press ENTER. For <computer name>, use the names of both other secured subnet computers and computers that are not in secure subnets.
2. Launch the IP Security Monitor MMC snap-in on the computer that initiated the net view commands.
3. Expand IP Security Monitor, expand <computer name>, expand Quick Mode, and then click Security Associations.
4. For each computer that a net view command was initiated against, confirm the following:
· Secure organization network participants negotiated a hard SA. The ESP-Integrity column should not be set to <None>.
· Non-participants negotiated a soft SA. The ESP-Integrity column should be set to <None>.
Test Tools and Scripts for the Functionality Tests
A number of configuration settings must be monitored during the functionality tests. Although most of these settings can be monitored using standard tools, two tasks require tools with which a standard administrator might not be familiar. These tasks involve identifying the IPsec policy that is currently active on the computer and determining what type of SA was negotiated.
Verifying IPsec Policy Application
Determining which IPsec policy is active on a computer is a challenge because there is no consistent method that works across platforms. In some cases you can identify the IPsec policy through the graphical user interface (GUI), whereas other situations require a command-line tool that may or may not be installed with the operating system.
Windows 2000
For computers running Windows 2000 Server, the administrator can identify the currently applied IPsec policy by using the Netdiag command. To retrieve the policy name and information, the administrator logs on to the computer, launches a command prompt and types the following:
Netdiag /test:IPsec
The following is example output from this command:
IP Security test . . . . . . . . . : Passed
Directory IPsec Policy Active: ' IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600)'
Windows XP
For computers running Windows XP, the administrator can identify the currently applied IPsec policy by using the IPseccmd.exe command-line tool. To retrieve the policy name and information, the administrator logs on to the computer, launches a command prompt and types the following:
IPseccmd show gpo
The following is example output from this command:
Active Directory Policy
-----------------------
Directory Policy Name: IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600)
Description: Isolation Domain Policy (Allow Outbound)
Last Change: Fri Sep 03 15:20:29 2004
Group Policy Object: IPSEC – Isolation Domain Policy
Organizational Unit: LDAP://DC=americas,DC=woodgrovebank,DC=com
Policy Path: LDAP://CN=IPsecPolicy{efa2185d-1a1d-40f6-b977-314f152643ca},CN=IP Security,CN=System,DC=americas,DC=woodgrovebank,DC=com
Windows Server 2003
For computers that run Windows Server 2003, the administrator can identify the currently applied IPsec policy by using the Netsh command-line tool. To retrieve the policy name and information, the administrator logs on to the computer, launches a command prompt and types the following:
netsh IPsec static show gpoassignedpolicy
The following is example output from this command:
Source Machine : Local Computer GPO for <IPS-TZ-W2K-02>
GPO Name : IPSEC – Isolation Domain Policy
Local IPsec Policy Name : NONE
AD IPsec Policy Name : IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600)
AD Policy DN : LDAP://CN=IPsecPolicy{efa2185d-1a1d-40f6-b977-314f152643ca},CN=IP Security,CN=System,DC=americas,DC=woodgrovebank,DC=com
Local IPsec Policy Assigned: Yes, but AD Policy is Overriding
Using IP Security Monitor to Determine SA Type
The IP Security Monitor MMC snap-in is used to examine the main mode and quick mode SAs, the associated filters, Internet Key Exchange (IKE) policies, and negotiation policies. During troubleshooting, the IP Security Monitor MMC snap-in can be used to determine what type of SA has been negotiated between peers. By examining the SAs under the Quick Mode tree, a system administrator can identify IPsec peers to the computer on which the tool is running.
When a computer negotiates an IPsec connection, a hard SA is created. This SA will have some value other than <None> in one or more of the Authentication, ESP Confidential, or ESP Integrity fields. For example, ESP with SHA1 and no authentication would have HMAC-SHA1 under the ESP Integrity field, and <None> for the other two fields. If the hard SA also has negotiated encryption, the ESP Confidential field would contain either DES or 3DES.
A soft SA will have <None> under all three fields, indicating that the responder fell back to clear.
Enabling Organization Secure Subnets Filter List on Remaining Policies
Before you enable the IPsec policies that remain, the Secure Organization Network filter list needs to be added to each policy. This task is required because at the time of the policy creation, the Secure Organization Network filter list was empty and could not be added to the policy.
Earlier in this appendix, the Secure Organization Network filter list was implemented and can now be added to the remaining policies. The following table shows the policy names and the associated filter action assigned to the Secure Organization Network filter list.
Table C.7 Policy and Filter Actions Mapping
| Policy name | Filter action |
| IPSEC – No Fallback Isolation Group IPsec Policy (1.0.041001.1600) | IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) |
| IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600) | IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) |
| IPSEC – Encryption Isolation Group IPsec Policy (1.0.041001.1600) | IPSEC – Require Encryption Mode (Ignore Inbound, Disallow Outbound) |
To add the Secure Organization Network filter list to IPsec policies
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Launch the IP Security Policy Management MMC snap-in.
3. Right-click <Policy Name>, and then click Properties.
4. On the Rules tab, click Add.
5. On the IP Filter List tab, click IPSEC –Organization Secure Subnets.
6. On the Filter Action tab, click the corresponding <Filter Action> from table C.7.
7. On the Connection Type tab, ensure that the All network connections check box is selected.
8. On the Tunnel Settings tab, ensure that the This rule does not specify an IPsec tunnel check box is selected.
9. On the Authentication Methods tab, ensure that the Kerberos method is the only method that is listed.
10. Click OK to close the Edit Rule Properties dialog box.
11. Click OK to close the <Policy Name> Properties dialog box.
12. Repeat steps 3-11 for each policy listed in the previous table.
Enabling Network Access Group Configuration
Network access groups are used to further restrict the IPsec responder to only accept connections from a select group of initiator computers and identified users. For example, by using network access groups, administrators can configure the executive client computers so that they only accept incoming traffic initiated from executive computers but still maintain their ability to initiate traffic to other resources.
Note Care must be taken when you define this option because computers that need to initiate communication with computers in the network access group (for example, monitor systems that use polling) will fail if they are not included in the network access group.
Implementing Network Access Groups
The designers at Woodgrove Bank chose to implement network access groups through the use of domain local groups. These groups were then used to define the initiators. They granted the initiators group the "Access this computer from the network" right on the responders, and removed the Authenticated Users group from the right. Woodgrove Bank implemented the network access group by using domain local groups because these groups are stored in the session ticket, which refreshes every 60 minutes. If global or universal groups had been used, the network access group would have been stored in the ticket granting ticket (TGT), which has a lifetime of 8 hours. By using domain local groups, group changes take effect on a much timelier basis.
Note Although this solution uses domain local groups with the "Access this computer from the network" right to implement the network access group, preshared keys or certificates could be used to implement individual network access groups.
The designers at Woodgrove Bank identified one network group, which is used to control access in the Encryption isolation group.
Creating Security Groups to Control Access
Table C.8 Woodgrove Bank Network Access Group Security Groups
| Group name | Description |
| ANAG _EncryptedResourceAccess_computers | A domain local group that is used to limit which computers can access encrypted resources |
| ANAG _EncryptedResourceAccess_users | A domain local group that is used to limit which users can initiate communication with the restricted encrypted resource |
To create the groups listed in the previous table
1. Launch Active Directory Users and Computers on IPS-CH-DC-01.
2. Right-click the Users container, click New, and then click Group.
3. In the Group name text box, type the <Group Name> from the previous table.
4. In Group Scope select Domain local and then click OK.
5. Repeat steps 2-4 for each group listed.
6. Right-click the <Group Name>, and then click Properties.
7. In the Description text box, type the <Description> from the previous table.
8. Click OK.
9. Repeat steps 6-8 for each group listed in the previous table.
Adding Accounts to Network Access Group Security Groups
Woodgrove Bank added the identified computers that act as initiators of traffic within the network access group to the appropriate domain local groups that are used to implement the network access group.
The following table lists the membership of the network access group that was identified by Woodgrove Bank.
Table C.9 Woodgrove Bank Isolation Group Membership
| Group name | Members |
| ANAG _EncryptedResourceAccess_computers | IPS-SQL-DFS-01 IPS-SQL-DFS-02 IPS-ST-XP-05 |
To populate the group listed in the previous table
1. Launch Active Directory Users and Computers on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the <Group Name> security 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 name of each computer in the Members column of the previous table and separate each member with a semicolon. Click OK.
7. Click OK.
Adding User Accounts to Network Access Group Security Groups
Woodgrove Bank identified the user accounts that are authorized to initiate traffic within the network access group and added them to the appropriate domain local groups used to implement the network access group.
The following table lists the membership of the network access group that was identified by Woodgrove Bank.
Table C.10 Woodgrove Bank Network Access Group Membership
| Group name | Members |
| ANAG _EncryptedResourceAccess_users | User7 |
To populate the groups listed in the previous table
1. Launch Active Directory Users and Computers on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the <Group Name> security 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 the name of each user in the Members column of the previous table. If there are multiple users, separate each with a semicolon. Then click OK.
6. Click OK.
Creating a Group Policy Object to Grant the "Access This Computer from the Network" Right
Woodgrove Bank created a GPO to enforce the defined network access group. Specifically, the GPO assigned the appropriate network access group security groups the "Access this computer from the network" right on the appropriate computers acting as responders.
The administrators created the following table, which lists the GPO name and the associated group names used to implement the network access group.
Table C.11 Woodgrove Bank Isolation Group Policy Definition
| GPO name | Group name |
| Encrypted Resource Access Isolation Group Policy | ANAG_EncryptedResourceAccess_computers ANAG_EncryptedResourceAccess_users Administrators Backup Operators |
Note The listed groups are the minimum that should be added. The administrator will need to determine if any additional groups should be granted this right.
To assign "Access this computer from the network" right
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Launch the GPMC.
3. Expand Forest:corp.woodgrovebank.com, expand the domain, and then expand americas.corp.woodgrovebank.com.
4. Right-click Group Policy Objects, and then click New.
5. In the Name text box, type <GPO name> and then click OK.
6. Right-click <GPO name> 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 <Group name> for each group listed in the previous table, and separate each with a semicolon. Click OK.
13. Click OK again.
14. Close the GPMC.
Linking Network Access Group Policy Objects
Before you distribute network access group policies, the GPOs need to be linked to a location within the domain environment. Woodgrove Bank chose to distribute the GPO by linking it to the appropriate OU in Active Directory, as shown in the following table.
Table C.12 Network Access Group GPO Name and Target OU
| Network access group GPO name | Target OU |
| Encrypted Network Access Group Policy | Database Servers |
To link a GPO policy to target OU
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Launch the GPMC.
3. Expand Forest: corp.woodgrovebank.com, expand the domain, expand americas.corp.woodgrovebank.com, and then locate the <Target OU>.
4. Right-click <Target OU>, and then click Link an Existing GPO.
5. In the Group Policy objects list, click <Network Access Group GPO Name>, and then click OK.
Verifying Deployment of Network Access Groups
After creating and deploying the network access groups and policy objects, administrators tested the functionality of the computers in the network access groups.
Prerequisite Implementation Tests
Before it tested the functionality of the computers in the network access group, Woodgrove Bank confirmed that the user rights assignments were being updated appropriately. After sufficient time had passed for replication and policy update to occur, Woodgrove Bank performed the following steps on the computers listed in the following table.
Table C.13 Network Access Group Membership
| Computer name | Group listed in user right |
| IPS-SQL-DFS-01 | ANAG_EncryptedResourceAccess_computers ANAG_EncryptedResourceAccess_users |
| IPS-SQL-DFS-02 | ANAG_EncryptedResourceAccess_computers ANAG_EncryptedResourceAccess_users |
To confirm the correct group membership in the network access group
1. Log on to <Computer Name> as a domain administrator of the Americas domain.
2. Launch the Local Security Policy tool.
3. Expand Local Policies, expand User Rights Assignment, and then, in the right pane, double-click Access this computer from the network.
4. Confirm that the Authenticated Users group is not present.
5. Confirm that <Group Listed in User Right> group is present.
6. Close the Local Security Policy tool.
7. Repeat steps 1-6 for each <Computer Name> listed in the previous table.
Functional Implementation Tests
After Woodgrove Bank confirmed that the security groups were granted the appropriate user right, the computers that belonged to the network access groups were tested against each other. Woodgrove Bank used this information to confirm that the access right restrictions were in place and functioning. Woodgrove attempted to perform net view commands against various initiator and responder combinations. In addition to this test, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following table lists the initiator and responder for each execution of net view, indicates whether it should succeed or fail, and lists the type of SA negotiated.
Table C.14 Network Access Group Functional Test Expected Results
| Initiator | Responder | Result | SA negotiated |
| IPS-TZ-XP-06 | IPS-SQL-DFS-01 | Fail | None |
| IPS-TZ-XP-06 | IPS-SQL-DFS-02 | Fail | None |
| IPS-TZ-XP-06 | IPS-ST-XP-05 | Succeed | Hard SA |
| IPS-SQL-DFS-01 | IPS-SQL-DFS-02 | Succeed | Hard SA |
| IPS-SQL-DFS-01 | IPS-ST-XP-05 | Succeed | Hard SA |
| IPS-SQL-DFS-02 | IPS-SQL-DFS-01 | Succeed | Hard SA |
| IPS-ST-XP-05 | IPS-SQL-DFS-01 | Succeed | Hard SA |
| IPS-ST-XP-05 | IPS-SQL-DFS-02 | Succeed | Hard SA |
To complete the functional test
1. Log on to <Initiator> as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in.
3. Expand IP Security Monitor, expand <Initiator>, expand Quick Mode, and then click Security Associations.
4. Launch a command prompt and then run the following command:
net view \\<Responder>
5. Use the IP Security Monitor MMC snap-in to confirm that the appropriate SA was negotiated for each successful connection
6. Repeat steps 1-5 for each unique <Initiator> listed in the previous table.
Enabling the Isolation Domain
Before the Isolation Domain policies are rolled out, the administrator must identify a group of computers that will be used for the pilot test. Ideally, this group of computers should represent a cross-section of the organization's IT infrastructure and include both clients and servers.
The identified computer accounts are added to the CG_IsolationDomain_computers group. After sufficient time has elapsed for replication, the Isolation Domain policy should apply to the pilot computers and take effect.
Implementing the Isolation Domain
Woodgrove Bank identified the following computers to be used in the pilot:
· IPS-TZ-XP-01
· IPS-TZ-W2K-02
· IPS-TZ-XP-06
· IPS-WEB-DFS-01
To add pilot computers to the CG_IsolationDomain_computers group
1. Launch Active Directory Users and Computers on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the CG_IsolationDomain_computers security 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 name of each computer in the preceding list, separate them with semicolons, and then click OK.
7. Click OK again.
Note After the computers are added to the CG_IsolationDomain_computers universal group, sufficient time should be allowed for replication of the group membership changes throughout the forest and for the policy to apply to the hosts.
Verifying Deployment of the Isolation Domain
After the policy objects have been created and deployed into Active Directory in the active state, a process of verification should be undertaken to confirm that the computer functions properly within the isolation group.
Prerequisite Implementation Tests
Before it ran any functional tests on the computer in the Isolation Domain, Woodgrove Bank confirmed sufficient time had passed for replication and policy update to occur and then that the correct IPsec policy was applied to it.
To confirm that the correct IPsec policy was applied on IPS-TZ-XP-06
1. Log on to IPS-TZ-XP-06 as a domain administrator of the Americas domain.
2. Launch a command prompt and then run the following command:
IPseccmd show gpo
3. Confirm that the output shows that the directory policy name is IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600).
Functional Implementation Tests
After Woodgrove Bank confirmed that the policy was applied to IPS-TZ-XP-06, the next step was to perform the some basic functional tests to ensure that the policy was operating as expected. Woodgrove Bank attempted to perform net view commands from IPS TZ-XP-06 to various computers in other isolation groups. In addition, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following table lists the target computers for each execution of net view, indicates whether it should succeed or fail, and lists the type of SA negotiated.
Note When you attempt a net view command against an untrusted computer, you must pass credentials for the local administrator of the target computer.
Table C.15 Isolation Domain Expected Functional Test Results
| Target computer | Result | SA negotiated |
| IPS-TZ-W2K-02 | Succeed | Hard SA |
| IPS-WEB-DFS-01 | Succeed | Hard SA |
| IPS-UT-XP-03 | Succeed | Soft SA |
| IPS-PRINTS-01 | Succeed | Hard SA |
To perform the functional test on each target computer
1. Log on to IPS-TZ-XP-06 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS TX XP 06, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
Enabling the No Fallback Isolation Group
Computers placed in the No Fallback isolation group cannot initiate unauthenticated traffic to untrusted computers.
Implementing the No Fallback Isolation Group
Woodgrove Bank placed those computers that cannot initiate unauthenticated communication to untrusted computers in the CG_NoFallbackIG_computers universal group.
To populate the CG_NoFallbackIG_computers group
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain, and then launch Active Directory Users and Computers.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the CG_NoFallbackIG_computers security 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 IPS-LT-XP-01 and then click OK.
7. Click OK again, and then once more.
Note Because of replication delays and polling frequency of the IPsec policies, there will be a delay between the time the computer is added to the CG_NoFallbackIG_computers group and when the No Fallback Isolation Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information.
Verifying Deployment of the No Fallback Isolation Group
After the policy objects have been created and deployed into Active Directory in the active state, a process of verification should be undertaken to confirm that the computer functions properly within the isolation group.
Prerequisite Implementation Tests
Before it ran any functional tests on the computers in the No Fallback isolation group, and after sufficient time had passed for replication and policy update to occur, Woodgrove Bank confirmed that the correct IPsec policy was applied.
To confirm that the correct IPsec policy was applied on IPS-LT-XP-01
1. Log on to IPS-LT-XP-01 as a domain administrator of the Americas domain.
2. Launch a command prompt and then run the following command:
IPseccmd show gpo
3. Confirm that the output shows that the directory policy name is Outbound Clear Allowed.
Functional Implementation Tests
After Woodgrove Bank confirmed that the policy was applying to IPS-LT-XP-01, the next step was to perform the some basic functional tests to ensure that the policy was operating as expected. Woodgrove Bank attempted to perform net view commands from IPS LT-XP-01 to various computers in other isolation groups. In addition to this, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following table lists the target computers for each execution of net view, indicates whether it should succeed or fail, and lists the type of SA negotiated.
Note When you attempt a net view command against an untrusted computer, you must pass credentials for the local administrator of the target computer.
Table C.16 Outbound Clear Allowed Expected Functional Test Results
| Target computer | Result | SA negotiated |
| IPS-PRINTS-01 | Succeed | Hard SA |
| IPS-TZ-XP-01 | Succeed | Hard SA |
| IPS-UT-XP-03 | Fail | None |
To perform the functional test on each target computer
1. Log on to IPS-LT-XP-01 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS LT XP 01, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
Enabling the Encryption Isolation Group
Computers that are placed in the Encryption isolation group require their traffic to be encrypted. In addition, servers that host data are configured to restrict who can access them through the network by implementation of an isolation group for the selected servers.
By using an additional group policy and a security group, access to the server can be controlled by modifying the "Access this computer from the network" right. Care should be taken when changing rights on a server to ensure that legitimate users are not blocked from accessing it.
Note The isolation group used in this section was implemented earlier in the "Enabling Isolation Group Configuration" section of this document.
Implementing the Encryption Isolation Group
The implementation team at Woodgrove Bank identified those computers that required IPsec encryption and placed them in the Require Encryption universal group.
To populate the Require Encryption group
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain, and then launch Active Directory Users and Computers.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the CG_EncryptionIG_computers security 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 IPS-SQL-DFS-01; IPS-SQL-DFS-02 and then click OK.
7. Click OK.
Note Because of replication delays and polling frequency of the IPsec policies, there will be delay between the time the computer is added to the CG_EncryptionIG_computers group and when the Encryption Isolation Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information.
Verifying the Encryption Isolation Group Deployment
After the policy objects have been created and deployed into Active Directory in the active state, a process of verification should be undertaken to confirm that the computer functions properly within the isolation group.
Prerequisite Implementation Tests
Before it ran any functional tests on the computer in the Encryption isolation group, and after sufficient time had passed for replication and policy update to occur, Woodgrove Bank confirmed that the correct IPsec policy was applied to the IPS SQL-DFS-01 and IPS-SQL-DFS-02 computers.
To confirm that the correct IPsec policy was applied
1. Log on to IPS-SQL-DFS-01 as a domain administrator of the Americas domain.
2. Launch a command prompt, and then run the following command:
netsh IPsec static show gpoassignedpolicy
3. Confirm that the output shows that the Directory Policy name is "IPSEC - Encryption Isolation Group IPsec Policy (1.0.041001.1600)."
4. Launch the Local Security Policy tool.
5. Expand Local Policies, expand User Rights Assignment, and then, in the right pane, double-click Access this computer from the network.
6. Confirm that the Authenticated Users group is not present.
7. Confirm that the ANAG_EncryptedResourceAccess_computers and ANAG_EncryptedResourceAccess_users groups are present.
8. Exit the Local Security Policy tool.
9. Repeat steps 1-8 on IPS-SQL-DFS-02.
Functional Implementation Tests
After Woodgrove Bank confirmed that the policy was applied to IPS-SQL-DFS-01 and IPS-SQL-DFS-02, the next step was to perform some basic functional tests to ensure that the policy was operating as expected. Woodgrove attempted to perform net view commands against IPS-SQL-DFS-01 and IPS-SQL-DFS-02. In addition, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following tables list the target computers for execution of net view, whether it should succeed or fail, and lists the type of SA negotiated.
Note When you attempt a net view command against an untrusted computer, you must pass credentials for the local administrator to the computer.
Table C.17 IPS-SQL-DFS-01 Expected Functional Test Results
| Target computer | Result | SA negotiated |
| IPS-SQL-DFS-02 | Succeed | Hard SA |
| IPS-TZ-XP-01 | Succeed | Hard SA |
| IPS-PRINTS-01 | Succeed | Hard SA |
| IPS-UT-XP-03 | Fail | None |
To test the functionality of the implementation on target computers
1. Log on to IPS-SQL-DFS-01 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS SQL-DFS-01, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
Enabling the Boundary Isolation Group
Woodgrove Bank placed the computers that must initiate or receive unauthenticated communication from untrusted computers in the CG_BoundaryIG_computers universal group.
Implementing the Boundary Isolation Group
The implementation team at Woodgrove Bank identified those computers that belonged to the Boundary isolation group and placed them in the CG_BoundaryIG_computers universal group.
To populate the CG_BoundaryIG_computers group
1. Log on to IPS-CH-DC-01 as a domain administrator of the Americas domain, and then launch Active Directory Users and Computers.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the CG_BoundaryIG_computers security 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 IPS-PRINTS-01 and then click OK.
7. Click OK.
Note Because of replication delays and polling frequency of the IPsec policies, there will be delay between the time the group is added to the CG_BoundaryIG_computers group and when the Boundary Isolation Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information.
Verifying the Boundary Isolation Group Deployment
After the policy objects are created and deployed into Active Directory in the active state, a process of verification should be undertaken to confirm that the computer functions properly within the isolation group.
Prerequisite Implementation Tests
Before it ran any functional tests on the computer in the Boundary isolation group, and after sufficient time had passed for replication and policy update to occur, Woodgrove Bank confirmed that the correct IPsec policy was applied to the computer.
To confirm that the correct IPsec policy was applied to IPS PRINTS-01
1. Log on to IPS-PRINTS-01 as a domain administrator of the Americas domain.
2. Launch a command prompt and then run the following command:
netsh IPsec static show gpoassignedpolicy
3. Confirm that the output shows that the Directory Policy name is "IPSEC – Boundary Isolation Group IPsec Policy (1.0.041001.1600)."
Functional Implementation Tests
After Woodgrove Bank confirmed that the policy was applied to IPS-PRINTS-01, the next step was to perform some basic functional tests to ensure that the policy was operating as expected. Woodgrove attempted to perform net view commands against the computers listed in the following table. In addition, they used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created. The following table lists the target computers for each execution of net view, indicates whether it should succeed or fail, and lists the type of SA negotiated for each computer participating in the Encrypted Resource Access group.
Note When you attempt a net view command against an untrusted computer you must pass credentials for the local administrator to the computer.
Table C.18 IPS-PRINTS-01 Expected Functional Test Results
| Target computer | Result | SA negotiated |
| IPS-UT-XP-03 | Succeed | Soft SA |
| IPS-TZ-XP-01 | Succeed | Hard SA |
| IPS-SQL-DFS-01 | Fail | None |
To test the functionality of the implementation on target computers
1. Log on to IPS-PRINTS-01 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS PRINTS-01, expand Quick Mode, and then click Security Associations.
3. Open a command prompt and run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
Configuring the Isolation Domain as the Default Isolation Group
Before the final functional tests were performed, the Woodgrove Bank administrators configured the security on the Isolation Domain so that it applies to all domain computers. This approach ensures that any new computers added to the domain are automatically added to the Isolation Domain unless they have requirements that place them into another isolation group.
In addition, the Domain Computers group was removed from the CG_BoundaryIG_computers group.
To remove Domain Computers from the CG_BoundaryIG_computers group
1. Launch Active Directory Users and Computers on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the CG_BoundaryIG_computers security group, and then click Properties.
4. Click the Members tab, click the Domain Computers group, and then click Remove.
5. Click Yes to remove the group.
6. Click OK.
Note Because of replication delays and polling frequency of the IPsec policies, there will be delay between the time the group is removed from the CG_BoundaryIG_computers group and when the Boundary Isolation Group Policy is removed. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information.
To add Domain Computers to the CG_IsolationDomain_computers Group
1. Launch Active Directory Users and Computers on IPS-CH-DC-01 as a domain administrator of the Americas domain.
2. Expand the domain, and then click Users.
3. In the right pane, right-click the CG_IsolationDomain_computers security 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 Domain Computers and then click OK.
6. Click OK again.
Note Because of replication delays and polling frequency of the IPsec policies, there will be delay between the time the Domain Computers group is added to the CG_IsolationDomain_computers group and when the Isolation Domain Group Policy is applied. The computer can be restarted at this point if there is a need to have the IPsec policy applied to it immediately. Otherwise, the policy will apply after the session ticket times out and is refreshed with the new local group membership information.
Reordering the IPsec Policy Link Order
To ensure that the correct policies are applied to the hosts, the link order of the IPsec policies needs to be updated. This task has to do with the fact that the Standard Isolation Group Policy was denoted as the default policy rather than the Boundary Isolation Group Policy, which was used as the default policy during initial deployment.
To link the IPsec policies to the existing GPOs
1. Launch the GPMC as a domain administrator.
2. Expand the domain.
3. Click the domain name.
4. In the Linked Group Policy objects list, use the arrow keys to order the policies as shown in the following table.
Table C.19 Link Order of Group Policy Objects at the Domain Level
| Link order | Group Policy Object name |
| 1 | IPSEC – Encryption Isolation Group Policy |
| 2 | IPSEC – No Fallback Isolation Group Policy |
| 3 | IPSEC – Boundary Isolation Group Policy |
| 4 | IPSEC – Isolation Domain Policy |
| 5 | Default Domain Policy |
Final Functional Tests—All Isolation Groups Enabled
After Woodgrove Bank enabled all of the isolation groups, the next step was to perform some basic functional tests to ensure that the policies were operating as expected. Although some basic functional tests were done as each policy was implemented, Woodgrove Bank administrators were unable to perform a complete functional test because the isolation groups were enabled one at a time. The administrators attempted to perform net view commands with one or more computers in each isolation group against computers in other isolation groups to verify that the appropriate connectivity was established. Multiple computers were selected in some isolation groups because they have different traffic patterns, depending on whether they are the responder or initiator. Additionally, the administrators used the IP Security Monitor MMC snap-in to confirm that the appropriate SAs were created.
The following tables list the target computers for each execution of net view, indicate whether it should succeed or fail, and list the type of SA negotiated for each computer that was selected for test purposes.
Note When you attempt a net view command against untrusted computers, you must pass credentials for the local administrator to the computer.
The following procedure tests connectivity from IPS-SQL-DFS-01 (acting as an initiator) to various computers in the other isolation and network access groups.
Table C.20 IPS-SQL-DFS-01 Expected Functional Test Results
| Target computer | Result | Reason | SA negotiated |
| IPS-ST-XP-05 | Succeed | Computers can successfully negotiate IPsec. | Hard SA with Encryption |
| IPS-TZ-XP-01 | Succeed | Computers can successfully negotiate IPsec. | Hard SA with Encryption |
| IPS-PRINTS-01 | Succeed | Computer can successfully negotiate IPsec. | Hard SA with Encryption |
| IPS-UT-XP-03 | Fail | Initiator does not support Fall back to clear. | None |
To test connectivity from target computers
1. Log on to IPS-SQL-DFS-01 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS SQL-DFS-01, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
The following procedure tests connectivity from IPS-TX-XP-06 (which acts as an initiator) to various computers in the other isolation and network access groups.
Table C.21 IPS-TZ-XP-06 Expected Functional Test Results
| Target computer | Result | Reason | SA negotiated |
| IPS-SQL-DFS-01 | Fail | Responder is part of the Encrypted Resource Access. | None |
| IPS-ST-XP-05 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-TZ-XP-01 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-PRINTS-01 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-UT-XP-03 | Succeed | Computers can successfully negotiate IPsec. | Soft SA |
To test connectivity from target computers
1. Log on to IPS-TZ-XP-06 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS TZ XP-06, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
The following procedure tests connectivity from IPS-ST-XP-06 (which acts as an initiator) to various computers in the other isolation groups.
Table C.22 IPS-ST-XP-05 Expected Functional Test Results
| Target computer | Result | Reason | SA negotiated |
| IPS-SQL-DFS-01 | Succeed | Initiator is part of the Encrypted Resource Access group. | Hard SA with Encryption |
| IPS-TZ-XP-01 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-PRINTS-01 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-UT-XP-03 | Succeed | Computers can successfully negotiate IPsec. | Soft SA |
To test the connectivity from target computers
1. Log on to IPS-ST-XP-05 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS ST XP-05, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
The following procedure tests connectivity from IPS-TZ-XP-01 (which acts as an initiator) to various computers in the other isolation and network access groups.
Table C.23 IPS-TZ-XP-01 Expected Functional Test Results
| Target computer | Result | Reason | SA negotiated |
| IPS-SQL-DFS-01 | Fail | Responder part of the Encrypted Resource Access group. | None |
| IPS-ST-XP-05 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-PRINTS-01 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-UT-XP-03 | Succeed | Initiator supports Fall back to clear. | Soft SA |
To test connectivity from target computers
1. Log on to IPS-TZ-XP-01 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor tool, expand IP Security Monitor, expand IPS TZ XP-01, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
The following procedure tests connectivity from IPS-LT_XP-01 (which acts as an initiator) to various computers in the other isolation and network access groups.
Table C.24 IPS-LT-XP-01 Expected Functional Test Results
| Target computer | Result | Reason | SA negotiated |
| IPS-SQL-DFS-01 | Fail | Responder is part of the Encrypted Resource Access group. | None |
| IPS-ST-XP-05 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-TZ-XP-01 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-UT-XP-03 | Fail | Initiator does not support Fall back to clear. | None |
To test connectivity from target computers
1. Log on to IPS-LT-XP-01 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS LT-XP 01, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
The following procedure tests connectivity from IPS-PRINTS-01 (which acts as an initiator) to various computers in the other isolation groups.
Table C.25 IPS-PRINTS-01 Expected Functional Test Results
| Target computer | Result | Reason | SA negotiated |
| IPS-SQL-DFS-01 | Fail | Responder explicitly denies access to Boundary hosts. Responder is part of the Encrypted Resource Access group. | None |
| IPS-ST-XP-05 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-TZ-XP-01 | Succeed | Computers can successfully negotiate IPsec. | Hard SA |
| IPS-UT-XP-03 | Succeed | Initiator supports Fall back to clear. | Soft SA |
To test connectivity from target computers
1. Log on to IPS-PRINTS-01 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS PRINTS 01, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For IPS-UT-XP-03, be sure to pass local administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
The following procedure tests connectivity from IPS-UT-XP-03 (which acts as an initiator) to various computers in the other isolation and network access groups.
Table C.26 IPS-UT-XP-03 Expected Functional Test Results
| Target computer | Result | Reason | SA negotiated |
| IPS-SQL-DFS-01 | Fail | Responder does not support Fall back to clear and Inbound passthrough. Responder is part of the Encrypted Resource Access group. | None |
| IPS-ST-XP-05 | Fail | Responder does not support Fall back to clear and Inbound passthrough. | None |
| IPS-TZ-XP-01 | Fail | Responder does not support Fall back to clear and Inbound passthrough. | None |
| IPS-PRINTS-01 | Succeed | Responder supports Fall back to clear and Inbound passthrough. | Soft SA |
To test connectivity from target computers
1. Log on to IPS-UT-XP-03 as a domain administrator in the Americas domain.
2. Launch the IP Security Monitor MMC snap-in, expand IP Security Monitor, expand IPS UT XP-03, expand Quick Mode, and then click Security Associations.
3. Launch a command prompt, and then run the following command:
net view \\<Target Computer>
Note For all domain-based computers, be sure to pass domain administrator credentials with the net view command.
4. Use the IP Security Monitor MMC snap-in to check the Security Associations field for each successful connection to confirm that the appropriate SA was negotiated.
5. Repeat steps 3-4 for each <Target Computer> listed in the previous table.
Summary
When you complete the tasks in this appendix you have accomplished the following:
· Created the filter lists, filter actions, rules, and IPsec policies in Active Directory.
· Configured the GPOs in Active Directory to correctly apply the IPsec policies.
· Performed a staged rollout of the Boundary isolation group and Isolation Domain to the entire enterprise.
· Configured several isolation groups to control Responder access.
· Enabled and tested the Isolation Domain.
· Enabled and tested the No Fallback isolation group.
· Enabled and tested the Encryption isolation Group.
· Enabled and tested the Boundary isolation group.
Appendix D: IT Threat Categories
This appendix provides a list of potential threats and attacks that can affect an organization and explains how a server and domain isolation solution can help mitigate them.
Threats Identified by STRIDE
This section describes a number of network security threats identified by the STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) model and how the security measures implemented as part of this solution can be used to help mitigate them.
Spoofing Identify Threats
Spoofing identity threats include anything done to illegally obtain or access and use another person's authentication information, such as a user name or password. This category of threat includes man-in-the-middle attacks and trusted host communications with untrusted hosts.
Man-in-the-Middle Attacks
One common technique used by hackers is the man-in-the-middle attack. This technique places a computer between two communicating computers in a network connection, and the in-between computer then impersonates one or both of the original computers. This technique provides the "man in the middle" with a live connection to the original computers and the ability to read and/or modify messages as they pass between them while the two computers' users think they are communicating only with each other.
Some Internet service providers (ISPs) have developed filtering practices that attempt to combat both man-in-the-middle attacks and spoofing of e-mail. For example, many ISPs only authorize users to send e mail through the ISP's servers, and they justify this restriction by the need to fight junk e-mail. However, the restriction also prevents authorized users from using a legitimate e-mail service provided by a third party, which many advanced users resent. Some cable ISPs try to block audio or video traffic in an attempt to force users to use their own voice-over-IP or video-streaming services. Other examples include attempts to ban some forms of virtual private networking (VPN) traffic, reasoning that VPN is a business service that requires a higher fee subscription, and attempts to prevent users from running servers in their homes.
ISP filters are typically implemented by using hardware functions of routers that operate on specific protocol types (User Datagram Protocol [UDP] or Transmission Control Protocol [TCP]), port numbers, or TCP flags (initial connection packet, and not data or acknowledgement). The use of IPsec effectively disables this kind of filtering, leaving the ISP with only two very extreme options: ban all IPsec traffic, or ban traffic with certain identified peers. If IPsec is widely used, both of these options could generate serious consumer backlash.
Trusted Hosts Communicating with Untrusted Hosts
This threat is actually a superset of several smaller threats and includes the issues of general spoofing of identity, modification of data between endpoints in a transmission, and eavesdropping. However, the greatest threat is spoofing, because the intent is to deceive a trusted host into thinking it is communicating with a trusted host. Not every host that will be isolated requires communication with untrusted hosts. Because IPsec uses a policy-based mechanism to determine the level of security required between two hosts when negotiations begin, most of these issues are addressed by careful consideration of the tradeoffs between security and communication and then thoughtful design and implementation of an IPsec policy that reflects the preferred outcome. Chapter 5, "Creating IPsec Policies for Isolation Groups," depicts the communication requirements for the Woodgrove Bank scenario and also the methodology that was used to create IPsec policies that govern how communications occur.
Tampering with Data
Tampering with data threats involve the malicious modification of data. Examples include unauthorized changes made to persistent data (such as defacement of a Web site), information held in a database, or data as it flows between two computers on an open network. One specific threat in this category is session hijacking.
Session Hijacking
Properly designed authentication mechanisms and long random passwords will resist network sniffing and dictionary attacks, respectively. However, attackers may use session hijacking to capture a session after the regular user has been authenticated and authorized. Session hijacking could enable an attacker to use a regular user’s privileges to access or modify a database, or possibly to install software for further penetration, even without obtaining the regular user’s credentials. The simplest way to perform session hijacking is to first attempt to place the attacker’s computer somewhere in the connection path by using a specialized hacking tool. The attacker will observe the exchange and at some point take over. Because the attacker is in the middle of the exchange, they can terminate one side of the TCP connection and maintain the other side by using the correct TCP/IP parameters and sequence numbers. The use of IPsec for either encryption or authentication protects endpoints from session hijacking.
Repudiation
Repudiation threats involve users who deny that they performed an action, and other parties have no way to prove otherwise. An example of this type of threat would be a user performing a prohibited operation in a system that lacks the ability to trace the prohibited operation. Nonrepudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item from a Web-based vendor might have to sign for the item when they receive it. The vendor can then use the signed receipt as evidence that the user received the package.
Information Disclosure
Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it. Examples include the ability of users to read files to which they were not granted access and the ability of an intruder to read data that is in transit between two computers. Threats in this category include unauthorized connections and network sniffing.
Unauthorized Connections
Many network configurations have a very trusting security posture and grant access to vast amounts of information from computers inside the perimeter. This access is sometimes explicit (as in the case of intranet Web servers) and sometimes implicit because of the poor security protection of some applications. Some policies rely on simple address tests, but attackers can bypass these tests by forging addresses.
IPsec can be used to implement an additional connection check. It is possible to set up policy rules that require a set of applications to be accessible only after a successful IPsec negotiation.
Network Sniffing
Attackers attempt to capture network traffic for two reasons: to obtain copies of important files during their transmission, and to obtain passwords so that the attackers can extend their penetration. On a broadcast network, hackers use network sniffing tools to log TCP connections and obtain a copy of the communicated information. Although these tools do not work very well on switched networks, it is possible even on switched networks to attack the Address Resolution Protocol (ARP) by using other specialized tools, which redirect IP traffic through the attacker’s computer and make it easy to log all connections.
A few protocols (Post Office Protocol 3 [POP3] and File Transfer Protocol [FTP], for example) still send plaintext passwords over the network, and an attacker who sniffs the network will find this information easy to obtain. Many applications use a challenge-response mechanism, which avoids the problem of sending a plaintext password but is only slightly more challenging. The attacker will not be able to read the password directly, but dictionary attacks can often deduce it from a copy of the challenge and response. Using IPsec to encrypt such exchanges effectively protects against network sniffing.
Denial of Service
Denial of service attacks are directed attacks against a specific host or network. These attacks usually send more traffic to a host or router than it can handle within a given time, which results in an inability of the network to handle the traffic and thereby disrupts the legitimate flow of traffic. Denial of service attacks can be distributed across many attackers to focus the effort on a particular target. Target computers are usually compromised somehow, and a malware script or program is installed on them that allows the attacker to use the computers to direct a coordinated flood of network traffic to another computer or group of computers. The compromised computers are referred to as zombies, and such attacks are called distributed denial of service attacks.
IPsec requires authentication before establishing communications, and therefore helps mitigate most distributed denial of service attacks (except those that use a trusted attacker scenario). In other words, Internet-based distributed denial of service attacks will be rendered harmless, but a denial of service attack launched from within an organization's network would still succeed if the attacking host or hosts can authenticate and communicate using IPsec.
Discriminating Between Standard and Attack Traffic
Shortly after the Slammer worm struck in January 2003, it was observed that networks would not have been flooded with the worm's traffic if they would have had simple rules in place that limited UDP traffic to up to 50 percent of available bandwidth. The infected hosts would have quickly filled up 50 percent of the bandwidth with UDP traffic, but the rest of the bandwidth would have remained available for operational traffic. Automatic teller machines (ATM) would have continued working, and administrators would have been able to use TCP to apply patches and propagate policies. Although the policy of limiting UDP traffic is simplistic, such simple policies that can be left in place can provide a reliable safety net.
By using IPsec for important traffic, administrators can apply a slightly more sophisticated version of the UDP policy. In typical conditions, network administrators can monitor the mix of traffic on the network and determine how much of it is UDP traffic, TCP traffic, Internet Control Message Protocol (ICMP) traffic, and so on. Under stress, a weighted fair queuing algorithm can engage to ensure that the resource is shared according to a standard pattern. In fact, it is usually possible to program such a policy by default in routers, collect long term trends and statistics during periods of standard network activity, and apply these collected statistics as fair queuing weights during periods of heavy congestion.
Worms and Denial of Service Attacks
The recent past has shown that networks are vulnerable to denial of service attacks, which operate by sending excess traffic to saturate either a specific server or a specific portion of a network. One form of denial of service attack operates in a distributed fashion that directs a number of computers to simultaneously attack traffic to a selected target; these can be especially difficult to defend against. The CodeRed worm first tried to penetrate a number of Web servers, which were all supposed to send crippling traffic to whitehouse.gov (the domain of the White House in Washington, DC, USA). In fact, the propagation mechanisms of the CodeRed, Nimda, and Slammer worms were denial of service attacks against the Internet. Each infected computer performed hundreds of thousands of infection attempts on indiscriminate targets, and the resulting traffic crippled many local and regional networks.
IPsec protects against denial of service attacks in several ways, and provides an added level of protection to potential victims of the attack. It slows down attackers by forcing expensive computations, and it allows network operators to distinguish between different types of traffic.
Elevation of Privilege
This type of threat allows an unprivileged user to gain privileged access that enables them to compromise or possibly destroy an entire system environment. Elevation of privilege threats include situations in which an attacker has effectively penetrated all system defenses to exploit and damage the system.
Other Threats
Not all threats fit cleanly into the STRIDE model. The following items depict other threats and describe their potential impact on a server and domain isolation solution.
Physical Security
Physical security involves providing physical access to a system or resource to only the minimum number of users who need it. Physical security is the lowest layer of defense for most IT security threats. However, in most network-level attacks, physical security is completely bypassed. Physical security still provides significant value as part of a defense-in-depth approach. For example, physical security in the form of security guards, cameras in data centers, access controls to sensitive locations, and keycards or keys on doors all help prevent a trusted device from becoming compromised. Using multiple methods of physical security is important and can help prevent some of the more serious data center security breaches.
It should be very clear that compromised physical security always means that all security layers have been compromised. All security discussed in this solution is based on the assumption that physical security has been addressed. Without physical security, no other security measures can be considered effective.
Network Security
A network is a system of interconnected computers. Most of the protocols and services designed for networks were not created with the potential for malicious intent in mind. The advent of high-speed computing, easy network access, and the wide availability of the Internet caused many malicious users to focus their efforts on systems and services for exploitative purposes or to cause disruption. A number of network threats were described in some detail earlier in this appendix. Additional information about how IPsec protects against some of these network attacks can be found in the “Configuring TCP/IP Name Resolution” section of the “Configuring IP Addressing and Name Resolution” chapter within the Windows® XP Professional Resource Kit.
Application Security
Most attacks that are directed at applications attempt to exploit vulnerabilities that exist in those applications or the operating system. Because IPsec is implemented at the network layer of the Open System Interconnection (OSI) model, it determines whether a packet is permitted or discarded before that packet ever reaches the application. This behavior means that IPsec cannot make application-level determinations but can be used provide security for application traffic at a lower level.
Social Engineering
Social engineering is the act of exploiting weaknesses in human behavior to gain access to or learn more about a system. For example, a would-be attacker could use the telephone to call the target company and then ask for the name of the supervisor in charge of a particular project. This project is one in which the company is developing a new product or service, which is what the attacker wants to know more about. If the operator provides the attacker with the name of the supervisor and perhaps even the location or contact information for that person, the attacker has more information that they can use to focus their efforts.
Because this type of attack targets the user of the computer, IPsec cannot protect against it. Similarly, a malicious user who has access to isolated systems and abuses that access (often referred to as a trusted attacker) will need to be prevented using other security technologies.
Summary
Clearly, using server and domain isolation will not resolve all of the threats that organizations face. Only a thorough understanding of available options and a detailed knowledge of the technical challenges will allow organizations adequately to protect their IT environments.
The following section summarizes the links to external resources that this document references. The aim of this section is to make it easier for you to add links to your own documentation.
The Antivirus Defense-in-Depth Guide
http://go.microsoft.com/fwlink/?LinkId=28732
Network Access Protection
http://go.microsoft.com/fwlink/?LinkId=69752
Microsoft Solutions Framework
http://go.microsoft.com/fwlink/?LinkId=69753
Microsoft Operations Framework
http://go.microsoft.com/fwlink/?LinkId=69755
Healthcare Without Boundaries: Integration Technology for the New Healthcare Economy
http://go.microsoft.com/fwlink/?LinkId=69757
"E-Authentication Guidance for Federal Agencies" memorandum in PDF format
http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf
National Information Assurance Partnership
http://www.nsa.gov/ia/industry/niap.cfm
Overview: Windows 2000 Common Criteria Certification
http://go.microsoft.com/fwlink/?LinkId=69759
FIPS 140 Evaluation
http://go.microsoft.com/fwlink/?LinkId=69761
Virtual Private Networks
http://go.microsoft.com/fwlink/?LinkId=69762
Introduction to Network Access Protection
http://go.microsoft.com/fwlink/?LinkId=69763
TechNet Security Center
http://go.microsoft.com/fwlink/?LinkId=69764
"Defense in Depth" white paper in PDF format
http://www.nsa.gov/snac/support/defenseindepth.pdf
Enterprise Design chapter of the Security Architecture Blueprint within the Windows Server System Reference Architecture
http://go.microsoft.com/fwlink/?LinkId=69765
How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll
http://go.microsoft.com/fwlink/?LinkId=69766
NIST Computer Security Division Web site
http://csrc.nist.gov/publications/index.html
NSA Security Recommendation Guides
http://nsa2.www.conxion.com/win2k/download.htm
Wireless Networking
http://go.microsoft.com/fwlink/?LinkId=69774
Determining Your IPSec Needs
http://go.microsoft.com/fwlink/?LinkId=69775
Securing Windows 2000 Server: Chapter 2, "Defining the Security Landscape"
http://go.microsoft.com/fwlink/?LinkId=69776
New features for IPSec
http://go.microsoft.com/fwlink/?LinkId=69777
Microsoft Systems Management Server
http://go.microsoft.com/fwlink/?LinkId=69778
L2TP/IPSec NAT-T update for Windows XP and Windows 2000
http://go.microsoft.com/fwlink/?LinkId=69779
SMS 2003 Asset Management
http://go.microsoft.com/fwlink/?LinkId=69780
Microsoft Windows Script Downloads
http://go.microsoft.com/fwlink/?LinkId=69781
Configuring Firewalls
http://go.microsoft.com/fwlink/?LinkId=69783
Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0) installation package
http://go.microsoft.com/fwlink/?LinkId=69782
Windows Management Instrumentation
http://go.microsoft.com/fwlink/?LinkId=69784
Microsoft Windows Script 5.6 for Windows 2000 and XP http://go.microsoft.com/fwlink/?LinkId=69786
Microsoft Windows Script 5.6 for Windows 98, Windows Millennium Edition, and Windows NT 4.0
http://go.microsoft.com/fwlink/?LinkId=69787
Windows Script 5.6 Documentation
http://go.microsoft.com/fwlink/?LinkId=69788
Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2
http://go.microsoft.com/fwlink/?LinkId=23277
Improving Security with Domain Isolation
http://go.microsoft.com/fwlink/?LinkId=69789
New Resolution for Problems That Occur When Users Belong to Many Groups
http://go.microsoft.com/fwlink/?LinkId=69839
Members of an Extremely Large Number of Groups Cannot Log On to the Domain
http://go.microsoft.com/fwlink/?LinkId=69840
Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server
http://go.microsoft.com/fwlink/?LinkId=69841
Internet Protocol Security for Windows 2000 Server
http://go.microsoft.com/fwlink/?LinkId=69842
IPsec
http://go.microsoft.com/fwlink/?LinkId=69843
Information Security at Microsoft Overview
http://go.microsoft.com/fwlink/?LinkId=69844
Windows Server 2003 Active Directory
http://go.microsoft.com/fwlink/?LinkId=69845
IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios
http://go.microsoft.com/fwlink/?LinkId=69846
IPSec default exemptions are removed in Windows Server 2003
http://go.microsoft.com/fwlink/?LinkId=69847
Windows XP Service Pack 2 Support Tools
http://go.microsoft.com/fwlink/?LinkId=69849
Windows 2000 Server Resource Kit
http://go.microsoft.com/fwlink/?LinkId=69965
Administering Group Policy with the GPMC
http://go.microsoft.com/fwlink/?LinkId=69850
Group Policy Management Console with Service Pack 1
http://go.microsoft.com/fwlink/?LinkId=69851
Windows Server 2003 Service Pack 1
http://go.microsoft.com/fwlink/?LinkId=41652
IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators
http://go.microsoft.com/fwlink/?LinkId=69852
The default behavior of IPsec NAT traversal (NAT-T) is changed in Windows XP Service Pack 2
http://go.microsoft.com/fwlink/?LinkId=69853
Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2 document download
http://go.microsoft.com/fwlink/?LinkId=69966
Deploying IPsec chapter from the Windows Server 2003 Deployment Kit
http://go.microsoft.com/fwlink/?LinkId=69854
Windows Server 2003 Group Policy
http://go.microsoft.com/fwlink/?LinkId=69855
The Cable Guy—October 2004: Problems with Using Network Address Translators
http://go.microsoft.com/fwlink/?LinkId=69888
Back up System State data
http://go.microsoft.com/fwlink/?LinkId=69856
IPSec Troubleshooting Tools
http://go.microsoft.com/fwlink/?LinkId=69857
IPsec troubleshooting in Microsoft Windows 2000 Server
http://go.microsoft.com/fwlink/?LinkId=69858
Windows XP Service Pack 2 Support Tools download
http://go.microsoft.com/fwlink/?LinkId=69890
Understanding IPSec Protection During Computer Startup
http://go.microsoft.com/fwlink/?LinkId=69859
Active Directory Operations Overview: Troubleshooting Active Directory-Related DNS Problems
http://go.microsoft.com/fwlink/?LinkId=69860
HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues
http://go.microsoft.com/fwlink/?LinkId=69861
Troubleshooting Kerberos Errors document download
http://go.microsoft.com/fwlink/?LinkId=69862
Troubleshooting Kerberos Delegation document download
http://go.microsoft.com/fwlink?LinkID=69863
How IPsec Works
http://go.microsoft.com/fwlink/?LinkId=69864
IPSec Policy Permissions in Windows 2000 and Windows Server 2003
http://go.microsoft.com/fwlink/?LinkId=69865
Troubleshooting Translational Bridging
http://go.microsoft.com/fwlink/?LinkId=69866
How to Enable IPSec Traffic Through a Firewall
http://go.microsoft.com/fwlink/?LinkId=69867
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
http://go.microsoft.com/fwlink/?LinkId=69868
White Paper: Troubleshooting Group Policy in Windows 2000 http://go.microsoft.com/fwlink/?LinkId=69869
Troubleshooting Group Policy in Microsoft Windows Server document download
http://go.microsoft.com/fwlink/?LinkId=69870
Changes to Functionality in Microsoft Windows XP Service Pack 2 - Part 2: Network Protection Technologies
http://go.microsoft.com/fwlink/?LinkId=69871
Description of the IPSec policy created for L2TP/IPSec
http://go.microsoft.com/fwlink/?LinkId=69872
How to configure an L2TP/IPSec connection by using Preshared Key Authentication
http://go.microsoft.com/fwlink/?LinkId=69873
Default MTU Size for Different Network Topology
http://go.microsoft.com/fwlink/?LinkId=69874
System Code Errors (12000-15999)
http://go.microsoft.com/fwlink/?LinkId=69875
TCP/IP in Windows 2000 Professional
http://go.microsoft.com/fwlink/?LinkId=69876
The “Troubleshooting Name Resolution and Addressing” section in the “Configuring IP Addressing and Name Resolution” chapter in the Windows XP Professional Resource Kit
http://go.microsoft.com/fwlink/?LinkId=69886
How to troubleshoot TCP/IP connectivity with Windows XP
http://go.microsoft.com/fwlink/?LinkId=69877
Windows Server 2003 TCP/IP Troubleshooting
http://go.microsoft.com/fwlink/?LinkId=69878
IPsec troubleshooting in Microsoft Windows 2000 Server
http://go.microsoft.com/fwlink/?LinkId=69879
Microsoft Windows 2000 Advanced Documentation
http://go.microsoft.com/fwlink/?LinkId=69880
Basic L2TP/IPSec Troubleshooting in Windows XP
http://go.microsoft.com/fwlink/?LinkId=69881
Microsoft Windows 2000 TCP/IP Implementation Details
http://go.microsoft.com/fwlink/?LinkId=69882
Overview of Windows 2000 Network Architecture
http://go.microsoft.com/fwlink/?LinkId=69883
How TCP/IP Works
http://go.microsoft.com/fwlink/?LinkId=69884
Special IPsec considerations
http://go.microsoft.com/fwlink/?LinkId=69885
Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets
http://www.ima.umn.edu/~pliam/xauth
The “Configuring TCP/IP Name Resolution” section of the “Configuring IP Addressing and Name Resolution” chapter in the Windows XP Professional Resource Kit
http://go.microsoft.com/fwlink/?LinkId=69887
Microsoft Solutions for Security and Compliance (MSSC) would like to acknowledge and thank the people who were directly responsible or made a substantial contribution to writing and reviewing Server and Domain Isolation using IPSec and Group Policy.
Authors and Experts
Steve Clark
David Coombes, Content Master
Charles Denny
William Dixon, V6 Security, Inc.
Richard Harrison, Content Master
Steve Ryan, Content Master
Program Managers
Jeff Coon, Volt Information Sciences
Bomani Siwatu
Alison Woolford, Content Master
Editors
John Cobb, Volt Information Sciences
Lea Galanter, Content Master
Jennifer Kerns, Wadeware
Wendy Prowell, Content Master
Steve Wacker, Volt Information Sciences
Testers
Mehul Mediwala, Infosys Technologies
Balambikai P., Infosys Technologies
Jay Zhang
Release Manager
Karl Seng, Siemens Agency Services
Contributors
Tony Bailey
Kimmo Bergius
Chase Carpenter
Barbara Chung
David Cross
Michael Glass, Volt Information Sciences
Karl Grunwald
Dan Hitchcock
Masoud Hoghooghi
Joanne Kennedy
Mohan Kotha
Karina Larson, Volt Information Sciences
Chrissy Lewis, Siemens Agency Services
David Mowers
Jeff Newfeld
Rob Oikawa
Tessa Porterfield
Bill Reid
Reviewers
Chris Black
Geoff Brock
Charisa Martin Cairn
Mathieu Groleau
Jeff Hamblin
Patrick Hanrion
Nate Harris
Craig Nelson, Avanade
Sinead O’Donovan
Greg Petersen, Avanade
Jason Popp
Steve Riley
Henry Sanders
Lee Walker
Shain Wray
Liqiang (Larry) Zhu
Comments