Server and Domain Isolation Using IPsec and Group Policy

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.

On This Page

	Executive Summary
	Who Should Read This Guide
	The Business Challenge
	Creating a Project Team
	Guide Overview
	Scenario Outline
	Summary

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:

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.

Top of page

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.

Top of page

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:

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
See full-sized image

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:

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.

Top of page

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.

Top of page

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.

Top of page

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:

Not only do these initiatives affect IT, there are additional specific challenges that IT decision makers face, including the following:

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:

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
See full-sized image

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
See full-sized image

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
See full-sized image

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.

Top of page

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.

Top of page

2 of 14