Technical White Paper

Published: May 2008

Executive Summary

As part of its Secure Anywhere Access Initiative, Microsoft IT has undertaken a multi-year effort to improve the security of the Microsoft network. The improvements have come by using a combination of technologies. Leveraging Internet Protocol Security (IPsec) and Windows® Firewall along with improved management tools, Microsoft IT has created a more secure network. The security improvements create advantages for the business by reducing downtime resulting from malware, improving compliance, and reducing time spent on management of information technology (IT) security.

This white paper examines the evolution of security within Microsoft's corporate network. Included are Microsoft IT's experience in planning its initial rollout of IPsec, the use of Windows Firewall, and Network Access Protection (NAP).

The technologies involved feature improvements made with Windows Server 2008 and Windows Vista. Techniques using IPsec detailed in this paper can also be implemented with Windows Server 2003 and Windows XP, and you can gain additional benefits with the inclusion of Windows Firewall in Windows XP Service Pack 2 (SP2) and Windows Server 2003 SP1. However, the improvements made with Windows Server 2008 and Windows Vista are compelling and present opportunities for significant additions to the security environment.

This paper illustrates the use of these technologies by covering several elements of the Microsoft IT implementation:

• Business benefits. An overview of the benefits to the business that Microsoft realizes because of the additional security measures.
• An overview of the Microsoft security environment. A look at the existing network and security implementation at Microsoft, including some of the challenges that Microsoft IT faced when attempting to secure the environment. The role of IPsec is illustrated to show its role within the environment, as is the concept of domain and server isolation, the use of Windows Firewall, and Network Access Protection.
• Planning. Extended detail on some of the areas in which Microsoft IT concentrated its efforts to ensure a smooth experience during each phase of the security rollout.
• Deployment. A description of the filters, filter lists, rules, and policies that Microsoft IT used as well as the settings used for default Windows Firewall rules.
• Lessons learned and best practices. Details on some of the issues found while deploying the solutions and resulting best practices, with the intention to help others benefit from Microsoft IT's experience.

This paper is written for enterprise technical decision-makers, IT implementers, and IT architects who want to gain a better understanding of the decisions and processes that Microsoft IT used to secure the Microsoft corporate network. This paper does not include a discussion of all aspects of a secure network, such as patch management, security health management, or perimeter defenses. These initiatives are covered in other white papers published at http://www.microsoft.com/technet/showcase.

This paper is based on Microsoft IT's experience and recommendations as an early adopter. It is not intended to serve as a procedural guide. Each enterprise environment is different and presents unique circumstances and challenges. Therefore, each organization should adapt the plans and lessons learned from this paper for its specific needs.

Introduction

The Secure Anywhere Access Initiative set forth by Bill Gates in 2007 incorporates and carries forward the earlier Trustworthy Computing Initiative that drove the Microsoft design in years past. To meet the goals in both initiatives, Microsoft IT has undertaken a long-term effort to improve the security of the managed assets and data.

Microsoft IT determined that a Defense-in-Depth strategy would be necessary to ensure that resources could be secured adequately from external and internal threats. Defense-in-Depth refers to a security strategy that uses several layers with the goal to provide end to end security rather than deploying a single type or line of defense.

Microsoft IT chose IPsec, a standards-based protocol upon which Microsoft IT could create a trusted computing environment, known as Domain Isolation. Domain isolation creates a logical network of authenticated computers, which helps to prevent untrusted computers from accessing trusted resources. This concept also encompasses server isolation so that servers and critical data could be further secured. Like domain isolation, server isolation also uses IPsec, optionally with encryption enabled, to ensure that only trusted computers can communicate with the servers participating in the isolation.

Prior to creation of the domain isolation environment, Microsoft operated a largely open network. The assumption was made that domain computers behind the perimeter firewall could be trusted, whereas those that were not joined to the domain could not be trusted. However, all computers could still access domain resources.

Windows Firewall provided the next addition to the security environment at Microsoft. Computers running Windows Server 2003 SP1 and Windows XP SP2 used these host-based firewalls to provide a level of protection right at the computer itself.

With the release of Windows Vista and Windows Server 2008, Windows Firewall has been further enhanced to include both inbound (which was previously available in Windows XP SP2 and Windows Server 2003 SP1) and outbound protection. Additionally, management of IPsec has been simplified and improved. Both IPsec and Windows Firewall are now managed through one interface, and creation of domain and server isolation environments is now wizard driven. Windows Server 2008 also introduced Network Access Protection (NAP). NAP enables granular control over access to resources using identity, group membership, and policy compliance. For instance, NAP can be used to ensure compliance with corporate network policies, preventing computers from connecting to resources if they don't meet the security criteria.

Business Benefits

Microsoft has gained several key business benefits through its security efforts. A more secure environment means less downtime due to unexpected security events. This benefits Microsoft IT and end users alike, which in turn means more productivity for the business.

Improvement of Overall Computer Security

By undertaking its security efforts and processes, Microsoft IT has helped foster confidentiality, integrity, and availability across the entire Microsoft environment. Confidentiality refers to maintaining appropriate controls and, when necessary, encryption on sensitive data to prevent unauthorized access. Integrity refers to ensuring that data remains unchanged–whether in storage or in transit–because of or by unauthorized means. Finally, availability includes the steps taken to make sure that systems and data are available and ready for use when needed.

Protection of Intellectual Property

Because of the nature of certain data, some areas of the Microsoft network need a higher level of security than others. These areas protect important business assets to Microsoft such as source code, marketing materials, product specifications, planning information, and Human Resources (HR) and Accounting data. The loss of any of these materials would be significant.

The use of IPsec with optional encryption for systems requiring more stringent security along with host-based firewalls and application segregation allows Microsoft IT to protect these systems while still using Group Policy for central management. Additionally the use of NAP allows the IT Administrators to make decisions about the health state of systems before they are allowed to access Corporate assets.

Increased Policy Compliance

Computers that are not part of the domain cannot take part in IPsec communication and are therefore isolated. When Microsoft IT originally deployed IPsec, this factor resulted in a 30 percent increase in the number of computers that joined the domain.

Computers on the domain are subject to Group Policy and management with Microsoft® Systems Management Server 2003 and other domain-management tools, creating a more secure and controlled environment.

Full Integration with IPv6 and NAP

The need for always-on, always-connected infrastructure together with an increasing number of connected devices means that support for IPv6 is more important than ever. IPv6 enables a much larger network address space so that more devices can be connected. Windows Vista and Windows Server 2008 fully support IPv6.

This always-connected network also means that applications such as NAP are also more important than ever. Windows Server 2008 and Windows Vista fully support NAP.

Application-agnostic Network Security

By choosing standard protocols and industry best practices, Microsoft IT is able to provide network security that isn't dependent on the application and doesn't need to be customized for an individual application–that is, application agnostic. The business directly benefits from this approach because Microsoft IT isn't required to manage application security or custom security details for a given application.

Existing Network and Security Overview

Microsoft IT's role is like that of other organizations, with several areas of responsibility vital to performance of the business. The primary role is to provide IT services, such as user support, management of computers, and management of network operations. Microsoft IT ensures 24x7 availability of computing resources to more than 500 locations around the globe.

Microsoft IT is responsible for managing a large, dynamic environment of more than 140,000 users and more than 260,000 client computers. Desktop environments are controlled by end users but Microsoft IT must maintain overall management of the security of those computers. In addition, Microsoft IT must manage the company's server infrastructure. This computing environment is managed to ensure maximum availability while maintaining data integrity and confidentiality of proprietary and sensitive data.

Challenges of the Security Environment

The security environment at Microsoft is extremely challenging. Some of the challenges that Microsoft IT faces include:

• Approximately 100,000 intrusion attempts each month.
• Approximately 1 million infected or malicious e-mail messages received each month.
• Special environments for product development and testing have specific security requirements.

Microsoft IT shares the same challenges faced by IT departments in any company: maintaining security while enabling users to do their jobs, preventing unauthorized devices from entering the network, protecting against viruses and malware, and supporting day-to-day activity on a busy network. The computing environment at Microsoft also presents unique challenges compared to other large-scale IT environments. Microsoft IT manages the entire network with security in mind, but the highly dynamic environment at Microsoft that encourages innovation and development presents additional challenges, including:

• Local administration. Microsoft fosters a development environment which enables administrator-level access for users' own desktop environment. Further, a literate user base tends to test the limits of the computing tools available. Therefore, it is common for these computers to have different configuration settings, which creates a challenge to effectively manage the computers without enforcing unnecessary policy changes.
• Multiple computers per user. It is common for Microsoft employees have two or more computers for development. Using multiple computers enables the developers to develop and test with specific configurations–for example, a specific version of the Windows operating system or a specific patch applied–while another computer is reserved for day-to-day tasks such as e-mail access. Developers also frequently reimage their computers for testing purposes, and over 5,000 PCs are rebuilt every day.
• Several approved applications and versions. Microsoft developers maintain several legacy versions of software on client computers to facilitate the testing of patches and to provide ongoing support for those applications. In addition, as new software is developed, users frequently run it in parallel with older versions for testing purposes.

Security Evolution

As computers and networks have evolved so too have the threats against them. Merely protecting assets at the perimeter is no longer sufficient to ensure data security within the corporate network. Microsoft IT approaches security as a process, with several key elements:

• Strong passwords.
• Perimeter firewalls.
• Smart card authentication.
• Policy enforcement.
• IPsec.
• Host-based firewalls.
• Application segregation.
• Vulnerability scanning.
• NAP

In early phases of the security evolution, IPsec was used to create domain isolation and server isolation. Following on the implementation of IPsec and domain and server isolation, Microsoft IT implemented host-based firewalls. The Windows Firewall version released with Windows XP SP2 and Windows Server 2003 SP1 enabled this additional but important layer in the security evolution. By using the Authenticated Bypass feature of Windows Firewall, the firewalled systems could still be scanned for security and compliance by trusted computers.

The next method for achieving additional security is application segregation. Using this feature, Microsoft IT uses the concept of least privilege to create an environment in which systems can only communicate with each other if there is a valid business reason to do so. The communication is allowed only on the application ports specifically allowed. Because the application segregation environment is built using the IPsec and Windows Firewall implementations that already exist within the Microsoft environment, no additional software is necessary to add this feature. Application segregation is managed through Group Policy.

Role of IPsec at Microsoft

The Internet Engineering Task Force (IETF) designed a security architecture for the Internet Protocol. IPsec provides authentication, packet integrity, and encryption for IP packets. Part of the IPsec protocol, Internet Key Exchange (IKE) provides key management and security negotiation.

IPsec is traditionally thought of as a tunneling protocol, typically used in virtual private network (VPN) remote access scenarios. IPsec operates in two modes: Tunnel mode and Transport mode. In Tunnel mode, the entire IP packet, including header information, is optionally both encrypted and authenticated. In Transport mode, only the packet's payload is optionally encrypted and authenticated.

Trusted Environment Through SecureNet

Microsoft IT uses IPsec in Transport mode to create an authenticated network of computers called SecureNet, in which each computer operating in the SecureNet is assured that it is communicating with a known counterpart. This configuration mitigates damage from rogue devices on the network. The Encapsulating Security Payload (ESP) portion of the IPsec protocol suite, operating in a configuration called ESP-Null, along with IKE creates the framework for SecureNet.

Certain servers and areas of the network are maintained with more stringent security requirements. In these areas, Microsoft IT uses IPsec with encryption. IPsec policies and filters are distributed through Group Policy, and the Access This Computer from the Network user right is used on sensitive resources.

Computers and devices connected with IPsec operate alongside untrusted computers and devices on the same physical network and address space while maintaining logical separation. Untrusted devices are not allowed to access resources unless granted explicit permission to do so. Further, untrusted devices cannot access trusted devices in the SecureNet but rather must access boundary resources. A boundary resource is a specific host set up by Microsoft IT with limited access permissions for untrusted devices.

Improvements with Windows Vista and Windows Server 2008

Windows Vista and Windows Server 2008 made several key improvements surrounding both the implementation and the management of IPsec in the corporate environment. Microsoft IT uses these improvements to decrease deployment and administration while still maintaining security. Among the improvements are:

Simplified IPsec policy.A simple policy for IPsec is now available that reduces the number of exceptions necessary. It also eliminates the delay involved in negotiating IPsec between hosts by sending both clear-text and IKE at the same time. If the responding host is IPsec-capable, IPsec will be used. If not, the communication will remain in clear text.

Simplified IPsec configuration. IPsec is now configured within Windows Firewall with the Advanced Security Microsoft Management Console (MMC) snap-in. This application provides a central location for management both of Windows Firewall rules and of IPsec filters and rules (now known as Connection Security). Figure 1 shows the Windows Firewall with Advanced Security application.

Figure 1. The Windows Firewall with Advanced Security MMC snap-in
in Windows Server 2008

Improved support for load balancing and clustering. Previous versions of the Windows operating system required up to two minutes to reestablish a connection when a load-balanced or clustered node failed. With Windows Vista and Windows Server 2008, this delay is significantly reduced. When TCP retransmissions are detected, IPsec begins renegotiating with another node. This means that a failover typically will not affect application stability.

New wizard for server and domain isolation. Creating server and domain isolation configurations is now done through the Windows Firewall with Advanced Security MMC snap-in and is wizard driven. Rules are created based on responses provided in the wizard, including the mode to be used from among these choices:

• Request authentication for inbound and outbound connections.
• Require authentication for inbound connections and request authentication for outbound connections.
• Require authentication for inbound and outbound connections.

Network Access Protection. Network Access Protection (NAP) is a new addition to Windows Server 2008 that is used to validate client configurations prior to allowing those clients access to domain resources. NAP can not only validate a client's health status but also provide automatic updating to the client in order to bring it into compliance. NAP will be discussed in detail later in this paper.

Improved authentication and cryptographic capabilities. In addition to the existing IKE, Kerberos, and machine certificates, Windows Vista and Windows Server 2008 add support for Network Access Protection (NAP) health certificates, NTLM version 2 (NTLMv2), and Anonymous authentication as well as Authenticated IP (AuthIP). AuthIP is an enhanced version of IKE that offers additional flexibility with support for user-based authentication, authentication with multiple credentials, improved authentication method negotiation, and asymmetric authentication. Like IKE, AuthIP supports main-mode and quick-mode negotiation. AuthIP also supports extended mode, a part of IPsec peer negotiation during which a second round of authentication can be performed. Extended mode, which is optional, can be used for multiple authentications. For example, with extended mode you can perform separate computer-based and user-based authentications. Multiple authentication support is part of IPsec enforcement for the Network Access Protection (NAP) platform, in which IPsec peers authenticate with computer credentials and also use a health certificate to prove that they are compliant with system health requirements. Additional cryptographic capabilities have been added, including support for Advanced Encryption Standard (AES)-128, AES-256, and AES-384 for encryption and Elliptic Curve Cryptography (ECC)–based key exchange using P-256 and P-384.

Server and Domain Isolation

IPsec is used as the foundation upon which server and domain isolation is implemented at Microsoft. A visual depiction of the environment is shown in Figure 2.

Figure 2. The Microsoft IT environment with server and domain isolation

Windows Firewall

Windows Firewall enables host-based security on client computers, providing protection by blocking access to inbound TCP and UDP ports. The client-based protection complements Microsoft's perimeter firewall.

The first version of Windows Firewall filtered only inbound traffic. Microsoft IT also took advantage of the Authenticated Bypass feature, which enables authenticated hosts to bypass firewall protections to perform duties such as vulnerability scanning.

With the release of Windows Vista and Windows Server 2008, several improvements have been made to Windows Firewall:

• Support for both incoming and outgoing filtering. One of the most important improvements in Windows Firewall is the ability to filter both incoming and outgoing traffic, unlike the previous version which filtered only inbound traffic. Microsoft IT enabled this functionality as default policy for all Windows Vista client computers.
• Additional exception capabilities. Exceptions can be configured based on Active Directory® directory service groups, IP protocol number, source and destination IP addresses and ports, and the interface in which the packet arrives or to which it is destined. Both IP version 4 (IPv4) and IP version 6 (IPv6) are fully supported in Windows Firewall. Dynamic exception capabilities can be used whereby the host's currently configured Dynamic Host Configuration Protocol (DHCP), Windows Internet Naming Service (WINS), Domain Name System (DNS), and default gateway are used and updated within the firewall when they change. Microsoft IT enables local administrators to configure exceptions to the firewall policy based on their own needs. For example, if a developer is working with applications that require specific TCP ports to be allowed, the developer can configure an exception for that application.
• Improved management interface. The Windows Firewall with Advanced Security MMC snap-in provides an integrated application within which all aspects of firewall rules can be configured. Additionally, IPsec rules are now configured through this same application. Microsoft IT uses the Windows Firewall with Advanced Security snap-in to manage both Windows Firewall and IPsec.

Working with Mixed Client Devices

One of the challenges in implementing server and domain isolation and host-based firewalls is the number of non-Windows devices on the Microsoft network. Computers running Mac OS X, Linux, UNIX, and other operating systems are found on the network for compatibility and other testing along with devices such as Microsoft Xbox®–all of which need access to network resources.

The need to maintain these client devices on the network created the need for boundary resources that would be allowed to talk to both trusted and untrusted computers and devices. Servers providing basic network services such as DNS and DHCP must be available to all client devices, regardless of whether they are part of the domain-isolated environment. Both clear-text and IPsec communication are available depending on the capabilities of the client device.

Application Segregation

The next phase in the evolution of Microsoft IT's security strategy is application segregation. Microsoft maintains an extranet on which individuals located internally or externally access resources. The extranet is logically separated from the internal network. Application segregation describes the environment in which server resources located in the extranet are accessed by individuals external or internal to Microsoft as well as communication within the extranet itself.

Application segregation dictates the concept of least privilege at a network level, meaning that only those communications that have a valid business reason are allowed to continue, and then only at the minimum level necessary to accomplish the task. For example, even if an IP address is allowed to connect to a given resource, the application segregation framework further limits what that connection can do solely to what is necessary or allowed from that IP address.

Application segregation is implemented atop the IPsec and Windows Firewall foundations that Microsoft IT already created. The existing use of IPsec within Microsoft's network makes application segregation easier to implement and requires fewer resources. Further, management of application segregation was done using the same tools as Windows Firewall and IPsec policies today. No dependencies on specific network devices or layouts were necessary for application segregation.

Application segregation requires mapping of applications to determine the current patterns of communication between and among the servers. This information is used to create groups containing consumers of applications. Microsoft IT's application segregation uses logical groups of consumers and data providers to delineate how communication will take place. These groups are then mapped to security groups to indicate their role. The security groups have IPsec and firewall policies applied to them, which in turn are applied to the resources. This all takes place through Group Policy.

Application segregation servers operate in Request Mode and therefore do not require IPsec as part of client communication. However, if IPsec is available it will be used. Otherwise, the communication falls back to clear text, which is what it would have been without IPsec.

Figure 3 shows the Microsoft IT environment, including the extranet.

Figure 3. The extranet environment in context as part of application segregation

Network Access Protection (NAP)

Network Access Protection is a new addition to Windows Server 2008 that enables enforcement of a minimum set of client health requirements prior to be allowed access to resources.

NAP provides the following functions:

Health Policy Validation NAP enables validation of the system health policy for clients on the network. A client joining the network first obtains an IP address and then begins communication with the NAP servers in order to have its health checked. The NAP servers determine the level of compliancy with the health policy on the network and if the client is in compliance, a health certificate is issued.

Network Access Limitation In the event that a client is non-compliant, it will not be allowed to communicate on the secure network.

Remediation The NAP infrastructure attempts to bring the client into compliance. If the client can be brought into compliance it is given a health certificate and allowed to communicate on the secure network.

Compliance The NAP infrastructure continues to communicate with clients to ensure that they maintain compliance with the health policy requirements for the network.

Systems Capable of Using NAP

Windows Server 2008, Windows Vista, and Windows XP SP3 are all capable of working with NAP.

Systems Not Capable of Using NAP

Systems not capable of NAP need to have health certificates created which can then be used to access NAP-based secure resources. These systems, including computers running older versions of Microsoft Windows, will not have their health examined by the NAP infrastructure.

Planning

The planning phases related to each step of securing the Microsoft environment largely depend on the phase and technology used.. For example, deploying IPsec requires different steps than the Windows Firewall deployment. However, large scale deployments across the Microsoft corporate network also required some similar steps during each deployment.

Planning the IPsec Rollout

During the implementation of domain isolation with IPsec, Microsoft IT took the steps described in the following sections.

Determine Segmentation Requirements

Microsoft IT started by evaluating the security measures already in place and identified several attacks that could be launched from unmanaged computers. The goal of the project was to deploy a mechanism to protect individual host computers that Microsoft IT managed on the corporate network from attacks launched by unmanaged host computers. The result of this evaluation was to create segregation within the network.

Choose Technology

Microsoft IT considered 802.1x, virtual LANs (VLANs), and VPNs as solutions for domain isolation before settling on IPsec. IPsec provided a scalable solution that did not require additional hardware or software investment. IPsec also did not require changing IP addressing on internal networks, as might have been the case with VLANs or VPNs. IPsec provided additional abilities to further isolate host computers into security groups and encrypt traffic, if desired.

Design IPsec and Group Policy Objects

Microsoft IT first created the security groups and GPOs for IPsec policy assignment and management. Microsoft IT used two group and IPsec policies: one for the default "Secure Request" behavior and the other for the boundary server exceptions using the "Request Mode Security" behavior. The team then worked with the network engineering team to identify all the IPv4 subnets assigned to the corporate network. This list of subnets was used to create the default rule and filter set for IPsec use, called the Secure Subnets rule. Microsoft IT also worked with the network engineering team to identify exceptions to the secure subnets filter list and set up rules for each of them as needed.

Test Policies and IPsec Functionality and Behaviors

With the filters designed and GPOs defined, Microsoft IT first enabled policies that had filters with limited subnets listed so that only small numbers of computers used IPsec, a phased subnet approach. This allowed Microsoft IT to deploy IPsec on limited computers to tightly control the initial testing. This testing confirmed the need for boundary machines and helped Microsoft IT refine the filters and filter rules.

Create a Rollout Schedule

With limited testing complete, Microsoft IT examined the network organization to create a rollout schedule across the enterprise. Because of the potentially disruptive nature of a large-scale IPsec deployment, the Microsoft IT team planned the deployment in a way that would allow them to resolve unanticipated problems with minimal impact on most employees. The deployment would start with the smallest individual subnets, then entire buildings, and eventually the entire network.

Deployment was planned in two phases:

• Phase 1: Deploy Request mode IPsec to appropriate computers.
• Phase 2: Deploy Secure Request mode IPsec to appropriate computers.

Develop a Test Process and Strategy

During the rollout, Microsoft IT carefully monitored traffic on deployed subnets as well as the impact on the user community through help desk call volumes and other observations. Based on this monitoring, Microsoft IT then reevaluated the rollout process and strategy. The deployment focused on ensuring minimal impact to users, placing a high priority on allowing employees to work uninterrupted.

Microsoft IT used the phased subnet deployment approach for its global Request mode deployment with a great deal of success. The Secure Subnets filter list was slowly expanded as the rollout progressed until the full set of corporate network subnets were in the list and nearly all network traffic was encapsulated with IPsec. When Request mode deployment was complete, all domain-joined computers in the enterprise had the same Secure Subnets filter list. To support its Secure Request rollout, Microsoft IT created a new, more-specific rule and filter list (with smaller subnet designations) and assigned a Secure Request filter action to it.

Although deploying by subnet provides a more granular level of control for IPsec deployment and allows an IT organization to gauge the impact from the deployment, it does create some challenges when using a more restrictive filter action. Specifically, with Secure Request or Require mode, users with non-domain–joined computers on the deployed subnets will be blocked from initiating sessions with other computers with the policies. While this is the end state of a secure IPsec deployment, the effects can be confusing to users, because the users assume that the changes will not apply to their non-domain–joined computers.

Microsoft IT started its Secure Request deployment with the per-subnet filter list method but found that the changes were too confusing for the user populations and created a broader impact than Microsoft IT felt was acceptable. In response, the rollout process was changed to deploy to individual domains instead of subnets, starting with the smallest domains. The main corporate domain, containing the majority of Microsoft IT–managed computers, was deployed last.

Communicate with Users

The IPsec deployment was completely transparent to the majority of Microsoft employees and required no user interaction. At peak deployment times, the maximum number of help desk calls per month related to IPsec was less than 250. This call volume was extremely low compared to other systems–the Microsoft help desk gets around 7,000 calls each month.

Help desk personnel were trained to help users with network problems when IPsec was deployed. They were equipped with troubleshooting flowcharts, process articles, and training on Windows Management Instrumentation (WMI), IPsec, Kerberos authentication, and DNS to resolve issues that arose. Some employees using computers previously unmanaged by Microsoft IT were prevented from accessing from resources they needed and therefore they were encouraged to put their unmanaged computer on a managed domain.

Developers and other users of servers containing sensitive intellectual property, HR information, or accounting information also needed to be aware of the changes to the security policy that IPsec enforced. Previously, these groups were able to access the sensitive servers from any computer connected to the corporate network, passing their user credentials to the server applications. With the deployment of IPsec, these servers could only be accessed by an authorized user from a computer in the proper domain security group. Microsoft IT used the Access This Computer from the Network logon right to restrict access to these domain security groups, and IPsec would block connections from unauthorized computers. The business decision to allow access to this information only to authorized computers was communicated to users of these servers.

The entire company was notified and kept aware of progress on the IPsec deployment through a variety of methods:

• Security bulletins sent through e-mail to all employees
• Internal training sessions
• Informal lunch-time presentations (brown bag sessions)
• Stories in an internal corporate newsletter
• Self-paced multimedia training
• An internal Web page with technical detail and a Frequently Asked Questions (FAQ) section

For most employees, no training was necessary. Before requiring IPsec for connections to SecureNet servers, an e-mail message was sent to all employees notifying them that their computers must meet two requirements:

• Running a minimum Microsoft IT–specified operating system
• Joined to a Microsoft IT–managed domain

The e-mail message warned that computers not meeting these requirements would not be able to gain access to Microsoft IT–managed servers and internal Web sites after a specified date and provided links to the internal Web page for more information.

Planning the Windows Firewall Rollout

With the Windows Firewall rollout, Microsoft IT took advantage of experiences from the IPsec implementation. Without the need to choose a technology, less planning was necessary for this rollout, and the process followed several of the same general steps as the IPsec rollout. The integration of Windows Firewall with Advanced Security into Windows Vista and Windows Server 2008 enabled advanced features such as Authenticated IP to be used as part of the rollout.

For the Windows Firewall rollout, Microsoft IT followed the steps described in the following sections.

Design Firewall and Authenticated IP GPOs

Microsoft IT built GPOs for the default rule set, which would be deployed to Windows Vista and Windows Server 2008 computers.

Test the Policies

The policies created in the previous step were tested to understand the behavior of Windows Firewall and Authenticated IP between computers running Windows Vista and Windows Server 2008 and those running legacy operating systems such as Windows Server 2003 or Windows XP.

Create a Rollout Schedule

A schedule to roll out the Windows Firewall enhancements was planned. The results of this planning showed that a phased rollout, in which a pilot domain was used first, would be the most effective way to ensure availability of crucial resources. The rollout schedule was:

1. Roll out to the pilot domain.
2. Roll out company-wide.

In this step, a rollback plan was also developed in the event that unforeseen issues required a complete rollback of the Windows Firewall implementation.

Test the Process and Create Documentation

Microsoft IT conducted further testing and created project documentation. The documentation helped train help desk and Tier 2 support staff, which also occurred during this step.

Communicate with Users

To help ensure a smooth rollout, Microsoft IT informed users of the addition of Windows Firewall, which was to be enforced on computers running Windows Vista and Windows Server 2008. Because the default setting was to block incoming connections not explicitly allowed by a rule, Microsoft IT informed users that this might mean that access to resources that had previously been allowed might no longer be available.

It is common for users at Microsoft have local administrative rights, and Microsoft IT allows users to change the firewall rules. This means that users might choose to allow inbound connections when required for their work. This needed to be communicated to users so that they could change firewall rules as necessary to perform their job.

Deploy Windows Firewall to the Pilot Production Domain

Microsoft IT deployed the Group Policy settings to enable Windows Firewall in a limited production environment. This was done to further attempt to identify any issues that would arise in a production environment with Windows Firewall enabled.

Deploy Windows Firewall Worldwide

With no additional issues found, Microsoft IT deployed the Windows Firewall settings to all domain-joined client computers and boundary computers through Group Policy.

Planning the NAP Deployment

The NAP deployment consisted of three phases. Each of the three phases was divided into pilot and general release subphases.

1. Reporting
2. Deferred Enforcement
3. Enforcement

Reporting Mode Deployment

NAP was initially deployed in reporting mode which enabled Microsoft IT to determine the impact on users for later phases of deployment. Some of the goals Microsoft IT met with the reporting mode deployment were:

• Verification of clients participating in NAP.
• Capturing of daily statistics on client status, including health and unhealthy clients.
• Verification that healthy clients receive health certificates.
• Obtaining of a baseline NAP server performance.
• Identification and, where possible, resolution of differences in reporting between other tools such as SMS, SER, and MOM.
• Identification and remediation of failures with the NAP infrastructure or communication between the infrastructure and clients.
• Identification of tools and data that will be needed to troubleshoot NAP issues for later phases of deployment.
• Estimation of impact to end users in deployment of later phases.
• Training of Help Desk and support staff.

Deferred Enforcement

During the Deferred Enforcement phase of NAP deployment, end users began to see notifications from the operating system, though no changes were made to enforce the health policies. The notifications created help desk calls from users unfamiliar with NAP and the messages being received. Microsoft accomplished several goals during the Deferred Enforcement phase, including:

• Requirement of health for IPSec configuration
• Capturing of statistics on healthy and unhealthy clients.
• Monitoring and comparison of server performance versus the baseline obtained in the Reporting Mode phase.
• Comparison of SMS, MOM, SER, and NAP reports.
• Identification and resolution of remediation failures.
• Utilizing tools to assist in troubleshooting NAP issues.

Enforcement

The final phase of NAP deployment is Enforcement. During Enforcement, NAP is deployed. Because this phase has the greatest risk of affecting the business, the Reporting Mode phase must be fully complete and all data analyzed in order to minimize the impact and quickly remediate any issues that arise. During enforcement, Microsoft IT accomplished these goals:

• Capturing of statistics of healthy and unhealthy clients.
• Comparison of SMS, MOM, SER, and NAP reports.
• Identification and resolution of remediation failures.

Deployment

The deployment of both IPsec and Windows Firewall took advantage of tools already built into the Windows Server operating system. Windows Server 2003 was used for the IPsec rollout, while Windows Server 2008 was used for the implementation of Windows Firewall.

Both IPsec and Windows Firewall settings can be configured through Group Policy and pushed to domain computers on a corporate network. This makes large-scale deployments much easier and much less prone to error than manual deployments through other means.

Microsoft IT used Group Policy to deploy IPsec and Windows Firewall settings. The Domain Computers group uses the default Group Policy settings, which include IPsec policies and filters. Certain computers are denied access to the default policy and instead use a different policy applied through their security groups.

IPsec Policy Settings

Before deploying IPsec, Microsoft IT completed the steps described in the following sections.

Create Dedicated GPOs for IPsec

Microsoft IT created three GPOs for each domain for IPsec while other GPOs were used for encryption testing.. Two of these GPOs are the primary IPsec policies, accounting for more than 99 percent of the computers in each domain:

• Request mode GPO
• Secure Request mode GPO

Client computers apply GPOs in a specific, inherited order. The first listed GPO has precedence over any that follow. This ordering ensures that the least-restrictive IPsec policy is applied if there is an error. Figure 4 illustrates how the GPOs are applied for domains within Microsoft.

Figure 4. GPO application process for Microsoft domains

The third GPO, Require Encryption, is used for additional security on certain resources.

Create Security Groups

Several computers within the Microsoft network need special IPsec policies that are not applied with the default policy. Because of this, Microsoft IT created a set of security groups for these computers. Each security group can allow or deny the application of a GPO. For example, devices that are secured with IPsec and those are not must be able to contact servers such as DNS servers and domain controllers. These servers are added to a No IPsec security group. The computer's security group and the GPO associated with the domain are used to determine which IPsec policy that computer receives.

Microsoft IT created the following security groups:

• Universal security groups to control the application of GPOs. Several universal security groups were created at the forest level, which helped to simplify administration.
• Universal security group for Group Policy/IPsec policy administration. A specific security group consisting of designated user accounts was created. This enables Microsoft IT to control who can administer IPsec across the entire forest.

Administer Group Policy

Microsoft IT uses Windows Server 2008 to administer Group Policy for IPsec. However, Microsoft IT still maintains computers that run the Microsoft Windows 2000 operating system. Because Windows 2000 had a more limited set of capabilities for IPsec, Microsoft IT defined IPsec rules and filters to work with Windows 2000 and later computers.

Microsoft IT administrators built local IPsec policies, the result of which is a file with an .ipsec extension containing the exported policies. The file is then imported into a test environment, where it is evaluated with the goal of validating the policies. After the policies are validated, they are imported into each domain for a standardized deployment. The .ipsec files also serve as a disaster recovery backup for IPsec policy settings. The previously discussed default policy and filter rules are used for the majority of computers on the network.

An IPsec policy consists of a set of rules. Each rule consists of a filter list and an action and can specify an authentication method, a tunnel, and a connection point. A filter list contains a set of filters. Each filter specifies a source network, a destination address or network, and optionally a port and protocol. Filter actions can be Permit, Block, or a customizable Negotiate Security action.

Figure 5 illustrates the relationship of these building blocks of an IPsec policy.

Figure 5: Structure of an IPsec Policy.

Each host computer may only have a single active IPsec policy. Microsoft IT defined different IPsec policies that apply to computers through different GPOs during different phases of the deployment process. There are cases in which IPsec may already be in use for other things. Some businesses use IPsec block and permit filters to secure individual servers. These existing IPsec deployments may directly conflict with a deployment like the one Microsoft IT uses: A single computer cannot have separate policies for being part of a SecureNet-like environment and still use a separate IPsec policy to locally secure a server. To address these issues, specific "secure server"–type policies can be implemented within the larger context of the domain policies with either more restrictive settings (require encryption, for example) or less restrictive settings (permit all Simple Mail Transfer Protocol [SMTP] traffic for monitoring, for example). These individual server policies can be implemented by linking specific GPOs to organizational units (OUs) or by using security group filtering to apply the secure server settings to a subset of servers.

Policy Settings

To create the IPsec policy imported into the domain, Microsoft IT uses an MMC snap-in to define a local IPsec policy on a computer running Windows Server 2008. Individual rules are managed from the IPsec policy properties sheet. Filter lists and filter actions can be defined directly from the MMC snap-in or in individual rule definitions. Policy settings are associated with particular elements: the policy itself, individual rules, filters, and filter actions.

Table 1 describes the standard IPsec policy deployed to most computers that Microsoft IT manages.

Table 1. IPsec Policy Settings in Use in the Microsoft IPsec Deployment

IPsec Filter Design

Microsoft IT takes advantage of the Hotfix released with Knowledge Base (KB) article 914841 to simplify the rules for IPsec filters for Windows XP SP2 and Windows Server 2003 SP1. Doing so reduces the number of rules required for exceptions. With the release of Windows Vista and Windows Server 2008 creation of IPsec rules for Domain and Server Isolation scenarios is wizard-driven which in turn further reduces the need for complex filter lists and exceptions.

Windows Firewall Settings

The default settings for Windows Firewall at Microsoft is to block all inbound connections except those for which a rule has been explicitly defined. Outbound connections are allowed by default unless they match a rule to affect them otherwise. Windows Firewall is required on all computers running Windows Vista and Windows Server 2008 on the corporate network. Computers in boundary networks–even those running Windows XP and Windows Server 2003–are required to have Windows Firewall, as well.

Supporting Non-IPsec Platforms

On the Microsoft corporate networks, certain computers and devices are not capable of using IPsec as deployed by Microsoft IT. These machines primarily include:

• Non-Windows computers and devices. Apple Macintosh computers, UNIX computers, Xbox consoles, and Pocket PCs do not have Windows IPsec installed or easily deployed.
• Legacy Windows operating systems. Some groups in Microsoft have test computers running Windows NT® 4.0 or Windows 9x, which are incapable of using Group Policy–based IPsec.
• Windows computers not joined to a managed domain. Some development groups run private domains for testing. Individuals in development and testing roles have test and development computers not connected to a managed domain.
• Remote Access Service (RAS) and VPN clients not owned by Microsoft. Partner and vendor companies need to connect to certain Microsoft resources. All employees can connect to the corporate network using home computers. These computers may not have a machine account in a managed domain.

Historically, all these computers have had access to domain resources. With IPsec deployed, these computers cannot access computers inside the SecureNet. Windows IPsec is compatible with IPsec implementations available on these other platforms, but Microsoft IT chose to design the IPsec policies to exclude them, because they are not managed to the security standards required for SecureNet.

Microsoft has a business need to allow some non-domain–joined computers access to business resources that would otherwise be in SecureNet. In addition to the types of client computers already listed, there are specific infrastructure-type services that cannot be secured by IPsec.

To establish IPsec in the first place, a computer must have network connectivity and be able to get the IPsec policy from a domain controller. This means that domain controllers must communicate with unauthenticated hosts, and DHCP relay agents must be able to forward responses from DHCP servers so client computers can gain access to the network. In addition, WINS and DNS are needed so that client computers can locate the domain controllers and allow access to boundary machines and the Internet by guest and test computers that do not require access to SecureNet.

Certain other services do not support IPsec, such as network thin clients or other bootstrap clients that need to download an image from a computer running Remote Installation Service (RIS) and Windows Server 2003, Automated Deployment Services (ADS).

Boundary Machines

Developing effective ways to connect specific non-Windows devices with a business need to access domain resources is a high priority for Microsoft IT, driven by the Secure Anywhere Access initiative. Currently, these devices must access resources through boundary machines, which have special IPsec rules.

To manage exceptions from the general SecureNet deployment of IPsec, Microsoft IT defined different types of boundary machines. Although a boundary machine is an IPsec-enabled computer, it accepts non-IPsec inbound connections, straddling the border between SecureNet and the untrusted corporate network. Boundary machines do not "proxy" communication between SecureNet and the untrusted corporate network; they are simply SecureNet computers that allow access from the untrusted corporate network. Note that boundary machines:

• Use Request security behavior, not Secure Request mode.
• Give Microsoft great flexibility in defining exceptions to the default IPsec policy using security groups instead of IP addresses.

Boundary machines require extra management and security, because they provide a way for untrusted computers to gain access to SecureNet resources. Microsoft IT has identified specific acceptable reasons for having a boundary machine. All the computers that share a particular reason for allowing untrusted access are put into a defined security group. In this way, threats to particular services can be quickly blocked, and additional group policies such as firewall rules may be deployed to particular security groups.

For example, all RIS servers are placed in a special security group. As boundary machines, they permit incoming non-IPsec from any computer, which allows the RIS servers to support computers that download operating system images before loading Windows or having any IPsec capabilities. By being part of a RIS server security group, Group Policy denies access to the default corporate IPsec policy, and the RIS server security group allows the Request mode policy to be applied.

Another common type of boundary machine is a file and print server used by Macintosh computers in a particular group or building. File servers are granted boundary status on a case-by-case basis. Several Mac business units require access to particular domain resources for developing their software. Requests from these groups are typically granted, but efforts are underway to consolidate Mac resources to particular computers.

Any employee may request that a particular computer be made a boundary machine, based on a strong business need to access corporate resources. The employee must provide the reason for asking for the exemption along with supporting details. Microsoft IT can then evaluate the need, then grant or deny the request.

Deploying IPsec has allowed Microsoft IT to identify where security risks exist on the network and gain a better understanding of the computer population within the corporate network. Microsoft IT can now deny insecure network traffic by default and grant it on a case-by-case basis, after gaining an understanding of the ramifications and the ability to further restrict the insecure traffic, quickly, if necessary. In other words, developing a detailed understanding of the exception scenarios provides IT administrators with the required knowledge for taking additional security steps to strengthen the overall security of the environment.

After deploying Secure Request mode to the entire corporate network, fewer than 2 percent of all domain-joined computers were boundary machines. Now that the deployment is complete, Microsoft IT can continue to isolate, consolidate, and take additional security steps to mitigate the risks that boundary machines pose.

Lessons Learned

Several issues were discovered while deploying IPsec and over the years since the technology has been in place. Additionally, other lessons have been learned during the phases of creating a more secure environment.

Bandwidth Consumption

ESP adds a brief header and trailer to every packet crossing the network. In deployment, this additional packet information adds an overhead of 3–9 percent to bandwidth consumption, depending on the application. Across all applications for the Microsoft enterprise environment, the mean increase was approximately 3 percent.

Different enterprise environments might experience a different amount of increase, depending on the mix of applications present. The increase in bandwidth is likely to have a more significant effect in a wide access network (WAN) scenario in which the traffic is already near capacity than in a LAN or over Fast Ethernet connections.

Microsoft has noted this effect in its enterprise environment. It was not judged to be enough of an impact to compare the actual cost for the increase of bandwidth against the potential security value. This could be a concern for other enterprises.

CPU Performance

The additional overhead of adding ESP to every packet is negligible on most client computers. For servers with a large number of concurrent network connections, this additional overhead adds up, typically because of the demands of the increased numbers of Diffie-Hellman exchanges, a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.

Full ESP encryption demands more CPU time. For servers containing extremely sensitive data requiring fully encrypted connections, special 10/100 Mbps network adapters are available that can offload this work from the CPU. These cards are not yet available for Gigabit Ethernet.

VPN Servers

For IPsec deployments using Kerberos, VPN servers must have special IPsec policies to allow traffic to remote client computers and support unauthenticated traffic for the tunnel itself. The IPsec policy used in the Microsoft deployment is incompatible with default Layer 2 Tunneling Protocol (L2TP) filters.

For deployments that rely upon certificates with a single trusted root for the entire enterprise, a separate IPsec policy for VPN servers may not be necessary. Microsoft IT decided to use Kerberos for the majority of SecureNet and only uses certificates for VPN machines that are not joined to the domain.

WAN Optimization

The Wide Area Network (WAN) environment is important to Microsoft with a widely dispersed workforce and multiple data centers. WAN connections typically have a high cost per megabit, so there is a continued effort to monitor and reduce overhead on the connections. Microsoft uses commercial WAN optimization products to improve performance on the WAN links but many commercial WAN optimizers either don't work with or don't fully support protocols such as IPsec and IPv6. Microsoft continues to examine methods for WAN optimization while continuing with the security efforts described in this paper.

Network-Related Issues

Deployment of IPsec caused some network-related issues, including overlapping IP ranges, device issues with some network equipment, and challenges with both Network Load Balancing and Network Address Translation.

RFC 1918 Private IP ranges

RFC 1918 specifies private IP ranges that anybody may use for computers on a private network. These ranges are used by Microsoft as well as its employees and vendors connecting to the corporate network through a VPN.

Because Microsoft has designated most of this private network address space as a secure subnet, any hosts using an IP address in a secure subnet must be joined to the domain and recognized by Kerberos and IPsec to be able to connect to SecureNet. This condition causes problems for home network users and vendors using private addresses who connect to SecureNet.

This issue is most noticed by mobile users between different networks. For example, a corporate user with a domain-joined portable computer on a business trip may try to use a hotel network. If the network space that the hotel uses overlaps one of the secured subnets defined in the IPsec policy, the mobile user may experience problems if IPsec policies are in use in that subnet. This is because the portable computer has the IPsec policy cached on it and will now attempt to negotiate IPsec with IP addresses on the hotel's network because there is a matching filter. Depending on the IPsec policy, this may cause a 3-second delay in initiating network connections while the portable computer attempts to initiate IPsec communications before falling back to unauthenticated connections or a completely failed connections when the other computer is using an incompatible IPsec policy. To date, Microsoft IT has not received reports of failed communications from its mobile users, so this remains a theoretical problem.

Microsoft has designated two specific private subnets to be excluded from the list of secure subnets:

• 192.168.0.0/24
• 192.168.1.0/24

Any vendors or employees using computers on their own networks and wishing to connect to SecureNet resources over the VPN can use one of these approved private address subnets to avoid these types of issues.

To resolve this issue, Microsoft IT limits the number of private subnets used in secure subnets and exempts other private subnets from this list.

Network Devices

Within a TCP/IP packet, IPsec changes the offsets for the destination ports and protocols. These changes disable applications running on network devices such as routers, especially those that monitor and manage traffic through the network.

Over time, these network applications will be updated to support IPsec, but several of these applications are not yet compatible. For example:

• Router access control lists (ACLs) cannot examine protocol and port fields in ESP-protected packets. ACLs based only on IP address are unaffected.
• Cisco NetFlow on routers cannot analyze packets between IPsec members based on protocol or port. Analysis based only on IP address is unaffected.
• Router-based Quality of Service (QoS) cannot use ports to classify packets. Host-based classification of packets supported by Windows is unaffected, as is router-based QoS using only IP addresses.
• Weighted Fair Queuing (WFQ) and other flow-based router traffic prioritization methods may not queue packets as intended, resulting in suboptimal network utilization.
• Network monitors may be unable to parse ESP packets.

In general, IPsec defeats network-based prioritization and port or protocol-based traffic management. For encrypted packets, there is no workaround–the host computer itself must handle any traffic-management functions. For unencrypted, authenticated-only packets, the devices and applications must be aware of how IPsec changes packets to be able to do anything with them other than route them to the correct host.

The Microsoft Network Monitor added an ESP parser in version 2.1 to aid troubleshooting of unencrypted IPsec packets. Network Monitor is available in a light version in Windows Server 2003 and a full version for Systems Management Server 2003. The Systems Management Server 2003 version adds formatting of data, advanced diagnostic capabilities, and other features for capture management. To resolve these issues, upgrade to the latest versions of these types of tools that have support for IPsec where available.

Network Load Balancing Clusters

There are challenges implementing IPsec on Network Load Balancing (NLB) clusters. IPsec authenticates individual hosts to each other, so if one server in the cluster goes offline, client computers currently connected to that server renegotiate the connection. NLB under Windows Server 2003 resolves specific IPsec problems that were present in Windows 2000 when used in a cluster that shares a virtual IP address.

NLB enables multiples servers to service requests in a distributed fashion to provide high availability for a service. IPsec directly opposes NLB in that it prevents different computers from handling the same client connection. Because IPsec is negotiated between individual hosts before any data is transmitted, the same node in the cluster must respond to established IPsec connections or the traffic will be dropped.

If the particular node in the cluster fails, existing IPsec connections to that server cannot detect the failover and rebuild the security association until the preset time-out period. In Windows 2000 and Windows XP, IPsec must be idle for 5 minutes before the client computer attempts to re-authenticate. This results in a 2–6-minute interruption in service for that client computer.

Windows XP SP1 (with the network Address Translation Traversal, or NAT-T, update), Windows XP SP2, and Windows Server 2003 reduce the idle timer to 1 minute. There will always be a delay if a client computer happens to be connected to a cluster node that fails.

With Windows XP and earlier Windows versions, NLB only worked with IPsec in clusters that use complete subnets–using DNS to distribute the load among several individual IP addresses in a class C subnet. Windows Server 2003 adds support for IPsec with NLB using a single virtual IP address for the entire cluster. Each node in the cluster negotiates a list of source IP ranges that it handles, dynamically adjusting the list based on traffic and the failover state of other nodes in the cluster.

NAT-T

Because NAT alters the IP header, using NAT an IPsec has historically been problematic. If a NAT device changes the port or source address of a packet, the checksum no longer verifies the packet and is rejected. Test labs and other test environments at Microsoft sometimes use NAT within the corporate network.

The IETF has created a NAT-T specification to address this issue, and a supported fix is available for Windows 2000 SP3 and SP4 as well as Windows XP SP1 and later. NAT-T is built into Windows XP SP2 and Windows Server 2003 and later Windows versions.

Troubleshooting

Microsoft allowed incoming Internet Control Message Protocol (ICMP) Echo Requests (ping) through the Windows Firewall, because it aids in troubleshooting. However, because IPsec encapsulates regular IP traffic inside ESP, troubleshooting network issues becomes challenging. Usually, IPsec itself does not have issues, but it depends upon the correct configuration of all of the supporting technologies. If there are any misconfigurations in a supporting technology, it can be difficult to find the source of the problem.

Troubleshooting IPsec involves checking for connectivity at several different layers. The basic process is:

1. Check for basic network connectivity using utilities such as Ping, NetDiag, portqry, and net view against the Domain Controller and other domain joined servers.
2. Make sure the client has correct TCP/IP configuration including valid DNS servers and that the client is able to resolve names. The ipconfig and nslookup command line tools can be used for this.
3. Verify IPsec Connectivity-related services are running and set to automatically start. These services include TCP/IP NetBIOS Helper, WMI, and RPC services.
4. Verify Windows Firewall inbound rules allow File/Print service resource access.
5. Use sc query to query the following:
   1. lanmanworkstation
   2. ikeext
   3. BFE
   4. policyagent (for Windows XP and Windows Server 2003)
   5. winmgmt
   6. Lmhosts
6. Verify IPsec Group Policy has been successfully applied. This is accomplished using the GPResult.exe tool to pull Group Policy settings and the Resultant Set of Policy (RSOP) for a user or a computer. Also verify that a consec rule/policy has been applied and look at the Group Policy logs using event viewer. The following commands can be helpful:
   1. GPRESULT /S <machine name> /V.
   2. netsh advfirewall consec show rule name=all type=dynamic
   3. Netsh IPsec static show gpo
   4. Gupupdate /force
7. Verify the current state of the Windows Firewall and its profile (Domain/Public/Private. Helpful commands include netsh firewall show state or netsh firewall show opmode.
8. In certain scenarios including VPN, verify the ACL:
   1. ISAKMP, protocol # 500 (UDP)
   2. Authentication Header (AH), protocol # 51
   3. Encapsulating Security Payload (ESP), protocol # 50
9. Download Microsoft IPsec Diagnostic Tool to diagnose network related failures, focusing primarily on IPsec. The IPsec Diagnostic Tool collects IPsec policy information on the system and parses the IPsec logs. It offers trace collection for VPN, NAP client, Windows Firewall, Group policy updates, Wireless and System events.
10. Review logs generated from Microsoft IPsec Diagnostic Tool. Verify machine certificate, machine account, local logon rights, policy filter mismatch, blocked ports, Kerberos events, security events, and IKE MM/QM SA.
11. Capture windows firewall real-time diagnostic information using wfputil.exe or wfpdiag.exe. For example, using an elevated privilege command prompt:
    Wfpdiag.exe - run cmd /c rundll32 fwpuclnt,wfpdiag
    Then reproduce the issue.
    Press Ctrl+Z on the command window running wfpdiag.
    
    Wfputil.exe
    wfputil
    wfputil -capture [-nocab] [-traceonly] [-keywords none|bcast|mcast|bcast+mcast] [<fileName>]
    wfputil –capturestop
12. Install Microsoft Network Monitor, view and analyze AuthIP and IKE network traffic.

Best Practices

Microsoft IT developed the following best practices from its deployment and management of the technologies presented in this paper.

Group Policy Design

When designing a GPO for domain isolation using IPsec on a corporate network, Microsoft IT offers these recommendations:

• Set up group policies for all behavior types to support IT and business unit IPsec testing. On a large network, exception policies take additional management time. Wherever possible, group exceptions together to simplify management. Identify as few different types of security groups and corresponding policies as necessary for business and IT needs.
• Filter the Apply Group Policy Access Control Entry (ACE) for each policy to only the limited security user groups. Because people who can change IPsec policy can drastically affect the deployment of IPsec across the entire enterprise, it is critical to limit group/IPsec administration to a small number of administrators.
• Use a naming convention that covers the policy and group function for easier management and troubleshooting. With different policies and security groups, it is easy to get confused about which policy was created for which security group. For example, create a Secure Request GPO that corresponds to a Secure Request security group.

IPsec Design

Filter weighting is the most sensitive part of filter design. The filters cannot overlap so plan subnets accordingly. It is best to make the secure subnets list use the largest subnets possible and the permitted subnets use the smallest subnets possible to minimize the overall number of filters.

Ideally, there should be a subnet gap between two filter lists–for example, make the smallest secure subnet filters a /18 network (a subnet mask of 255.255.192.0) and the largest permitted subnet filters a /23 network (a subnet mask of 255.255.254.0). Then, experiment with deploying Request mode and piloting Secure Request mode to specific subnets. This can be done by adding a Secure Request Subnets Pilot filter in which the subnets used are between /19 and /22 (subnet masks of 255.255.224.0 and 255.255.252.0). That way, all the filters will work together and not cancel each other out.

Windows Firewall Design

Windows Firewall is enabled using Group Policy and enforced for Windows Vista and Windows Server 2008. By default all incoming requests to a given computer are blocked unless matched by a specific rule. All outbound requests are allowed unless denied by a specific rule.

Local administrators can create their own rules and exceptions within the Windows Firewall configuration. Allowing local administrators to alter their own firewall rules is necessary to enable the ongoing development and testing of new software and supporting legacy applications, both of which are at the core of Microsoft's business.

IPsec Deployment

When deploying IPsec on a corporate network, an organization should:

• Pilot Request mode IPsec. In this phase, Microsoft IT deployed an IPsec policy to all domain computers with exceptions and no secure rules.. Doing so ensures that any previously existing and potentially incompatible local IPsec policies are removed. Then, add a secure rule on a single subnet in the corporate network. For example, make a rule that specifies Any <-> Subnet #1, All IP, Request Security.
• Deploy Request mode IPsec. After resolving any issues discovered in the Request mode pilot, continue to add additional subnets used on the corporate network to the policy until the deployment is complete.
• Pilot Secure Request IPsec policy. Create a security group for a few computers to use in the pilot. Apply the Secure Request IPsec policy to the GPO for the security group, allow Read and Apply permissions of the GPO to the security group, and test. Microsoft IT recommends using security groups for this step, because subnets are harder to troubleshoot.
• Deploy Secure Request IPsec policy. Apply the Secure Request policy to more and more computers by adding them to a security group GPO that allows the application of the secure request policy. When most of the deployment and legacy issues have been resolved, the policy can be applied to all computers in a domain.

Microsoft IT recommends staging deployments gradually across an enterprise network. Start with a few subnets or security groups, and identify the technical issues. Take time to correct or consider the issues before deploying to the entire network. Do not attempt to deploy to entire domains until most issues have been resolved.

Non-domain–Joined Client Computers

Use Kerberos exclusively for an IPsec deployment, if possible. Kerberos simplifies the administrative work involved in isolating a corporate domain. If a network is already managed by Active Directory, Kerberos, and Group Policy, adding a Public Key Infrastructure (PKI) to manage non-domain–joined computers adds administrative overhead.

As described earlier, Microsoft supports several different groups of non-domain–joined client computers. Microsoft IT created specific security groups to provide access to necessary resources by making them boundary machines. Microsoft IT recommends carefully evaluating the need to create exceptions to global IPsec policies. Most corporate networks have some devices that cannot be joined to a domain. For these computers, creating special boundary machines may be the best way to manage access to resources from untrusted computers.

Microsoft chose to use Kerberos as the main IPsec authentication process. This allows the entire network to be managed using domain-management tools such as Active Directory and Group Policy, providing granularity for defining security groups within individual domains for more restrictive security.

Even so, Microsoft decided to support Windows-based computers not joined to a corporate domain connecting over VPN and provide access to SecureNet. These non-domain–joined computers are used primarily by employees, partners, and vendors connecting to the corporate network with computers not owned by Microsoft. To support these computers, the IPsec deployment has to support certificates for authentication in addition to Kerberos.

IPsec and NLB

If high availability for a cluster is more important than securing it with IPsec, consider exempting the cluster's virtual IP address in the IPsec policy, making client computers connect to the cluster without IPsec. As described earlier, IPsec in Windows Server 2003 does work with NLB, but only to the extent that new connections can always be made to a cluster. Existing connections can experience dropped connections if one of the servers in a cluster goes down.

Conclusion

Microsoft IT has undertaken a multi-year effort to improve the security of its corporate network. This effort has resulted in the use of several key foundational technologies such as IPsec to create domain and server isolation and the use of Windows Firewall. Further improvements have been made as the tools and software have evolved, including improvements to Windows Firewall to filter both inbound and outbound traffic and the use of application segregation.

Microsoft IT has created a secure environment using widely available, standards-based technologies together with enhancements made in Windows Vista and Windows Server 2008.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2008 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Windows, Windows NT, Windows Server, Windows Vista, aare either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.