Windows Firewall with Advanced Security. Design Guide and Deployment Guide. Abstract

Transcription

1 Windows Firewall with Advanced Security Design Guide and Deployment Guide Microsoft Corporation Published: October 2008 Author: Dave Bishop Editor: Allyson Adley Reviewers: Bilal Aijazi, Boyd Benson, Shalaka Bhuskute, Louise Bowman, Jorge Coronel Mendoza, Sharad Kylasam, Greg Page, Sushant Patil, Jason Popp, Mohan Prabhala, Andy Tang, Devang Thakkar, Nick Wood Abstract This document contains both the Design Guide and the Deployment Guide for Windows Firewall with Advanced Security. These guides help you to design and deploy Windows Firewall with Advanced Security settings and rules in your organization's network to help you to meet your goals for network security. It includes procedures for configuring Windows Firewall and Internet Protocol security (IPsec) settings commonly used in server and domain isolation scenarios. The Design Guide answers "what", "why", and "when" questions. The Deployment Guide answers the "how" questions.

2 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. The Windows Firewall with Advanced Security Design Guide and Deployment Guide are 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. Unless otherwise noted, the companies, organizations, products, domain names, addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, address, logo, person, place, or event is intended or should be inferred Microsoft Corporation. All rights reserved. Microsoft Windows Server and Windows Vista are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

3 Contents Windows Firewall with Advanced Security Design Guide... 7 Understanding the Windows Firewall with Advanced Security Design Process Identifying Your Windows Firewall with Advanced Security Deployment Goals Protect Computers from Unwanted Network Traffic Restrict Access to Only Trusted Computers Require Encryption When Accessing Sensitive Network Resources Restrict Access to Only Specified Users or Computers Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design Basic Firewall Policy Design Domain Isolation Policy Design Server Isolation Policy Design Certificate-based Isolation Policy Design Evaluating Windows Firewall with Advanced Security Design Examples Firewall Policy Design Example Domain Isolation Policy Design Example Server Isolation Policy Design Example Certificate-based Isolation Policy Design Example Designing a Windows Firewall with Advanced Security Strategy Gathering the Information You Need Gathering Information about Your Current Network Infrastructure Gathering Information about Your Active Directory Deployment Gathering Information about Your Computers Gathering Other Relevant Information Determining the Trusted State of Your Computers Planning Your Windows Firewall with Advanced Security Design Planning Settings for a Basic Firewall Policy Planning Domain Isolation Zones Exemption List Isolated Domain Boundary Zone Encryption Zone Planning Server Isolation Zones Planning Certificate-based Authentication Documenting the Zones Planning Group Policy Deployment for Your Isolation Zones Planning Isolation Groups for the Zones Planning Network Access Groups Planning the GPOs Firewall GPOs... 88

4 GPO_DOMISO_Firewall_2008_Vista GPO_DOMISO_Firewall_2003_XP Isolated Domain GPOs GPO_DOMISO_IsolatedDomain_Clients_WinVista GPO_DOMISO_IsolatedDomain_Servers_WS GPO_DOMISO_IsolatedDomain_Clients_WinXP GPO_DOMISO_IsolatedDomain_Servers_WS GPO_DOMISO_IsolatedDomain_Servers_Win Boundary Zone GPOs GPO_DOMISO_Boundary_WS GPO_DOMISO_Boundary_WS Encryption Zone GPOs GPO_DOMISO_Encryption_WS GPO_DOMISO_Encryption_WS Server Isolation GPOs Planning GPO Deployment Appendix A: Sample GPO Template Files for Settings Used in this Guide Additional Resources Windows Firewall with Advanced Security Deployment Guide Planning to Deploy Windows Firewall with Advanced Security Implementing Your Windows Firewall with Advanced Security Design Plan Checklist: Creating Group Policy Objects Checklist: Implementing a Basic Firewall Policy Design Checklist: Configuring Basic Firewall Settings Checklist: Creating Inbound Firewall Rules Checklist: Creating Outbound Firewall Rules Checklist: Implementing a Domain Isolation Policy Design Checklist: Configuring Rules for the Isolated Domain Checklist: Configuring Rules for the Boundary Zone Checklist: Configuring Rules for the Encryption Zone Checklist: Configuring Rules for an Isolated Server Zone Checklist: Implementing a Standalone Server Isolation Policy Design Checklist: Configuring Rules for Servers in a Standalone Isolated Server Zone Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone Checklist: Implementing a Certificate-based Isolation Policy Design Procedures Used in This Guide Add Authentication Methods to an IPsec Rule on Earlier Versions of Windows Add Production Computers to the Membership Group for a Zone Add Test Computers to the Membership Group for a Zone Assign an IPsec Policy to a GPO for Earlier Versions of Windows Assign Security Group Filters to the GPO Change Rules from Request to Require Mode

5 Configure Authentication Methods on Windows Vista and Windows Server Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server Configure Group Policy to Autoenroll and Deploy Certificates Configure Key Exchange (Main Mode) Settings on Earlier Versions of Windows Configure Key Exchange (Main Mode) Settings on Windows Vista and Windows Server Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows Configure the Rules to Require Encryption on Windows Vista and Windows Server Configure the Windows Firewall Log Configure the Workstation Authentication Certificate Template Configure Windows Firewall to Suppress Notifications When a Program Is Blocked Confirm That Certificates Are Deployed Correctly Copy a GPO to Create a New GPO Create a Group Account in Active Directory Create a Group Policy Object Create a New IP Security Policy in a GPO for Earlier Versions of Windows Create an Authentication Exemption List Rule on Windows Vista and Windows Server Create an Authentication Request Rule on Windows Vista and Windows Server Create an Inbound ICMP Rule on Windows Vista or Windows Server Create an Inbound Port Rule on Windows Vista or Windows Server Create an Inbound Port Rule on Windows XP or Windows Server Create an Inbound Program or Service Rule on Windows Vista or Windows Server Create an Inbound Program Rule on Windows XP or Windows Server Create an Outbound Port Rule on Windows Vista or Windows Server Create an Outbound Program or Service Rule on Windows Vista or Windows Server Create Filter Actions on Earlier Versions of Windows Create Filter Lists for Clients of Isolated Server Running Earlier Versions of Windows Create Filter Lists for Isolated Domain Computers and Isolated Servers Running Earlier Versions of Windows Create Inbound Rules to Support RPC on Windows Vista or Windows Server Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows Create IPsec Rules for an Isolated Server Zone on Earlier Versions of Windows Create IPsec Rules for Clients of an Isolated Server Zone on Earlier Versions of Windows229 Create WMI Filters for the GPO Enable Predefined Inbound Rules on Windows Vista or Windows Server Enable Predefined Inbound Rules on Windows XP or Windows Server Enable Predefined Outbound Rules on Windows Vista or Windows Server Exempt ICMP from Authentication on Windows Vista and Windows Server Install Active Directory Certificate Services Link the GPO to the Domain

6 Modify GPO Filters to Apply to a Different Zone or Version of Windows Open the Group Policy Management Console to IP Security Policies Open the Group Policy Management Console to Windows Firewall Open the Group Policy Management Console to Windows Firewall with Advanced Security Open Windows Firewall with Advanced Security Restrict Server Access to Members of a Group Only Start a Command Line as an Administrator Turn on Windows Firewall and Configure Default Behavior Use Netsh to Configure GPOs Verify That Network Traffic Is Authenticated Additional Resources

7 Windows Firewall with Advanced Security Design Guide Windows Firewall with Advanced Security in Windows Vista and Windows Server 2008 is a host firewall that helps secure the computer in two ways. First, it can filter the network traffic permitted to enter the computer from the network, and also control what network traffic the computer is allowed to send to the network. Second, Windows Firewall with Advanced Security supports IPsec, which enables you to require authentication from any computer that is attempting to communicate with your computer. When authentication is required, computers that cannot authenticate cannot communicate with your computer. By using IPsec, you can also require that specific network traffic be encrypted to prevent it from being read or intercepted while in transit between computers. The interface for Windows Firewall with Advanced Security is much more capable and flexible than the consumer-friendly interface found in the Windows Firewall Control Panel. They both interact with the same underlying services, but provide different levels of control over those services. While the Windows Firewall Control Panel meets the needs for protecting a single computer in a home environment, it does not provide enough centralized management or security features to help secure more complex network traffic found in a typical business enterprise environment. Tip If you are reading this guide on the Web in the Windows Server Technical Library, then click the sync toc at the top of the navigation pane, and then expand the node for Windows Firewall with Advanced Security. You can view any topic in the guide by clicking its name in the navigation pane. For more overview information about Windows Firewall with Advanced Security and its common uses, see the following topics on the Microsoft Web site: Getting Started with Windows Firewall with Advanced Security Introduction to Server and Domain Isolation For the complete list of documentation for Windows Firewall with Advanced Security, see the Windows Firewall with Advanced Security Content Roadmap at About this guide This guide provides recommendations to help you to choose or create a design for deploying Windows Firewall with Advanced Security in your enterprise environment. The guide describes 7

8 some of the common goals for using Windows Firewall with Advanced Security, and then helps you map the goals that apply to your scenario to the designs that are presented in this guide. This guide is intended for the IT professional who has been assigned the task of deploying firewall and IPsec technologies on an organization's network to help meet the organization's security goals. Windows Firewall with Advanced Security should be part of a comprehensive security solution that implements a variety of security technologies, such as perimeter firewalls, intrusion detection systems, virtual private networking (VPN), IEEE 802.1X authentication for wireless and wired connections, and IPsec connection security rules. To successfully use this guide, you need a good understanding of both the capabilities provided by Windows Firewall with Advanced Security, and how to deliver configuration settings to your managed computers by using Group Policy in Active Directory. You can use the deployment goals to form one of these Windows Firewall with Advanced Security designs, or a custom design that combines elements from those presented here: Basic firewall policy design. Restricts network traffic in and out of your computers to only that which is needed and authorized. Domain isolation policy design. Prevents computers that are domain members from receiving unsolicited network traffic from computers that are not domain members. Additional "zones" can be established to support the special requirements of some computers, such as: A "boundary zone" for computers that must be able to receive requests from non-isolated computers. An "encryption zone" for computers that store sensitive data that must be protected during network transmission. Server isolation policy design. Restricts access to a server to only a limited group of authorized users and computers. Commonly configured as a zone in a domain isolation design, but can also be configured as a stand-alone design, providing many of the benefits of domain isolation to a small set of computers. Certificate-based isolation policy design. This design is a complement to either of the previous two designs, and supports any of their capabilities. It uses cryptographic certificates that are deployed to clients and servers for authentication, instead of the Kerberos V5 authentication used by default in Active Directory. This enables computers that are not part of an Active Directory domain, such as computers running operating systems other than Windows, to participate in your isolation solution. In addition to descriptions and example for each design, you will find guidelines for gathering required data about your environment. You can then use these guidelines to plan and design your Windows Firewall with Advanced Security deployment. After you read this guide, and finish gathering, documenting, and mapping your organization's requirements, you have the information that you need to begin deploying Windows Firewall with Advanced Security using the guidance in the Windows Firewall with Advanced Security Deployment Guide. You can find the Windows Firewall with Advanced Security Deployment Guide at these locations: (Web page) 8

9 (Downloadable Word document) Terminology used in this guide The following table identifies and defines terms used throughout this guide. Term Active Directory domain Authentication Boundary zone Connection security rule Certificate-based isolation Definition A group of computers and users managed by an administrator by using Active Directory Domain Services (AD DS). Computers in a domain share a common directory database and security policies. Multiple domains can coexist in a "forest," with trust relationships that establish the forest as the security boundary. A process that enables the sender of a message to prove its identity to the receiver. For connection security in Windows, authentication is implemented by the IPsec protocol suite. A subset of the computers in an isolated domain that must be able to receive unsolicited and non-authenticated network traffic from computers that are not members of the isolated domain. Computers in the boundary zone request but do not require authentication. They use IPsec to communicate with other computers in the isolated domain. A rule in Windows Firewall with Advanced Security that contains a set of conditions and an action to be applied to network packets that match the conditions. The action can allow the packet, block the packet, or require the packet to be protected by IPsec. In previous versions of Windows, this was called an IPsec rule. A way to add computers that cannot use Kerberos V5 authentication to an isolated domain, by using an alternate authentication technique. Every computer in the isolated domain and the computers that cannot use Kerberos V5 are provided with a computer certificate that can be used to authenticate with 9

10 Term Domain isolation Encryption zone Firewall rule Internet Protocol security (IPsec) IPsec policy Definition each other. Certificate-based isolation requires a way to create and distribute an appropriate certificate (if you choose not to purchase one from a commercial certificate provider). A technique for helping protect the computers in an organization by requiring that the computers authenticate each other's identity before exchanging information, and refusing connection requests from computers that cannot authenticate. Domain isolation takes advantage of Active Directory domain membership and the Kerberos V5 authentication protocol available to all members of the domain. Also see "Isolated domain" in this table. A subset of the computers in an isolated domain that process sensitive data. Computers that are part of the encryption zone have all network traffic encrypted to prevent viewing by non-authorized users. Computers that are part of the encryption zone also typically are subject to the access control restrictions of server isolation. A rule in Windows Firewall with Advanced Security that contains a set of conditions used to determine whether a network packet is allowed to pass through the firewall. By default, the firewall rules in Windows Vista and Windows Server 2008 block unsolicited inbound network traffic. Likewise, by default, all outbound network traffic is allowed. The firewall included in previous versions of Windows only filtered inbound network traffic. A set of industry-standard, cryptography-based protection services and protocols. IPSec protects all protocols in the TCP/IP protocol suite except Address Resolution Protocol (ARP). A collection of connection security rules that 10

11 Term Isolated domain Server isolation Solicited network traffic Unsolicited network traffic Definition provide the required protection to network traffic entering and leaving the computer. The protection includes authentication of both the sending and receiving computer, integrity protection of the network traffic exchanged between them, and can include encryption. An Active Directory domain (or an Active Directory forest, or set of domains with two-way trust relationships) that has Group Policy settings applied to help protect its member computers by using IPsec connection security rules. Members of the isolated domain require authentication on all unsolicited inbound connections (with exceptions handled by the other zones). In this guide, the term isolated domain refers to the IPsec concept of a group of computers that can share authentication. The term Active Directory domain refers to the group of computers that share a security database by using Active Directory. A technique for using group membership to restrict access to a server that is typically already a member of an isolated domain. The additional protection comes from using the authentication credentials of the requesting computer to determine its group membership, and then only allowing access if the computer account (and optionally the user account) is a member of an authorized group. Network traffic that is sent in response to a request. By default, Windows Firewall with Advanced Security allows all solicited network traffic through. Network traffic that is not a response to an earlier request, and that the receiving computer cannot necessarily anticipate. By default, Windows Firewall with Advanced Security blocks all unsolicited network traffic. 11

12 Term Zone Definition A zone is a logical grouping of computers that share common IPsec policies because of their communications requirements. For example, the boundary zone permits inbound connections from non-trusted computers. The encryption zone requires that all connections be encrypted. This is not related to the term zone as used by Domain Name System (DNS). Next:Understanding the Windows Firewall with Advanced Security Design Process Understanding the Windows Firewall with Advanced Security Design Process Designing any deployment starts by performing several important tasks: Identifying Your Windows Firewall with Advanced Security Deployment Goals Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design Evaluating Windows Firewall with Advanced Security Design Examples After you identify your deployment goals and map them to a Windows Firewall with Advanced Security design, you can begin documenting the design based on the processes that are described in the following topics: Designing a Windows Firewall with Advanced Security Strategy Planning Your Windows Firewall with Advanced Security Design Next:Identifying Your Windows Firewall with Advanced Security Deployment Goals Identifying Your Windows Firewall with Advanced Security Deployment Goals Correctly identifying your Windows Firewall with Advanced Security deployment goals is essential for the success of your Windows Firewall with Advanced Security design project. Form a project team that can clearly articulate deployment issues in a vision statement. When you write your vision statement, identify, clarify, and refine your deployment goals. Prioritize and, if possible, combine your deployment goals so that you can design and deploy Windows Firewall with Advanced Security by using an iterative approach. You can take advantage of the predefined Windows Firewall with Advanced Security deployment goals presented in this guide that are relevant to your scenarios. 12

13 The following table lists the three main tasks for articulating, refining, and subsequently documenting your Windows Firewall with Advanced Security deployment goals. Deployment goal tasks Evaluate predefined Windows Firewall with Advanced Security deployment goals that are provided in this section of the guide, and combine one or more goals to reach your organizational objectives. Map one goal or a combination of the predefined deployment goals to an existing Windows Firewall with Advanced Security design. Based on the status of your current infrastructure, document your deployment goals for your Windows Firewall with Advanced Security design into a deployment plan. Reference links Predefined deployment goals: Protect Computers from Unwanted Network Traffic Restrict Access to Only Trusted Computers Require Encryption When Accessing Sensitive Network Resources Restrict Access to Only Specified Users or Computers Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design Designing a Windows Firewall with Advanced Security Strategy Planning Your Windows Firewall with Advanced Security Design Next:Protect Computers from Unwanted Network Traffic Protect Computers from Unwanted Network Traffic Although network perimeter firewalls provide important protection to network resources from external threats, there are network threats that a perimeter firewall cannot protect against. Some attacks might successfully penetrate the perimeter firewall, and at that point what can stop it? Other attacks might originate from inside the network, such as a computer virus that is brought in on portable media and run on a trusted computer. Portable computers are often taken outside the network and connected directly to the Internet, without adequate protection between the computer and security threats. Running a host-based firewall on every computer that your organization manages is an important layer in a "defense-in-depth" security strategy. A host-based firewall can help protect against attacks that originate from inside the network and also provide additional protection against attacks from outside the network that manage to penetrate the perimeter firewall. It also travels with a portable computer to provide protection when it is away from the organization's network. A host-based firewall helps secure a computer by dropping all network traffic that does not match the administrator-designed rule set for permitted network traffic. This design, which corresponds to Basic Firewall Policy Design, provides the following benefits: 13

14 Network traffic that is a reply to a request from the local computer is permitted into the computer from the network. Network traffic that is unsolicited, but that matches a rule for allowed network traffic, is permitted into the computer from the network. For example, Woodgrove Bank wants a computer that is running SQL Server to be able to receive the SQL queries sent to it by client computers. The firewall policy deployed to the computer that is running SQL Server includes firewall rules that specifically allow inbound network traffic for the SQL Server program. Outbound network traffic that is not specifically blocked is allowed on the network. For example, Woodgrove Bank has a corporate policy that prohibits the use of certain peerto-peer file sharing programs. The firewall policy deployed to the computers on the network includes firewall rules that block both inbound and outbound network traffic for the prohibited programs. All other outbound traffic is permitted. The following component is recommended for this deployment goal: Active Directory: Active Directory supports centralized management of connection security rules by configuring the rules in one or more Group Policy objects (GPOs) that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see Additional Resources. Other means of deploying a firewall policy are available, such as creating scripts that use the netsh command-line tool, and then running those scripts on each computer in the organization. This guide uses Active Directory as a recommended means of deployment because of its ability to scale to very large organizations. Next: Restrict Access to Only Trusted Computers Restrict Access to Only Trusted Computers Your organizational network likely has a connection to the Internet. You also likely have partners, vendors, or contractors who attach computers that are not owned by your organization to your network. Because you do not manage those computers, you cannot trust them to be free of malicious software, maintained with the latest security updates, or in any way in compliance with your organization's security policies. These untrustworthy computers both on and outside of your physical network must not be permitted to access your organization's computers except where it is truly required. To mitigate this risk, you must be able to isolate the computers you trust, and restrict their ability to receive unsolicited network traffic from untrusted computers. By using connection security and firewall rules available in Windows Firewall with Advanced Security, you can logically isolate the computers that you trust by requiring that all unsolicited inbound network traffic be authenticated. Authentication ensures that each computer or user can positively identify itself by using credentials that are trusted by the other computer. Connection security rules can be configured to use IPsec with the Kerberos V5 protocol available in Active Directory, or certificates issued by a trusted certification authority as the authentication method. 14

15 Note Because the primary authentication method recommended for computers that are running Windows is to use the Kerberos V5 protocol with membership in an Active Directory domain, this guide refers to this logical separation of computers as domain isolation, even when certificates are used to extend the protection to computers that are not part of an Active Directory domain. The protection provided by domain isolation can help you comply with regulatory and legislative requirements, such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations. The following illustration shows an isolated domain, with one of the zones that are optionally part of the design. The rules that implement both the isolated domain and the different zones are deployed by using Group Policy and Active Directory. These goals, which correspond to Domain Isolation Policy Design and Certificate-based Isolation Policy Design, provide the following benefits: Computers in the isolated domain accept unsolicited inbound network traffic only when it can be authenticated as coming from another computer in the isolated domain. Exemption rules can be defined to allow inbound traffic from trusted computers that for some reason cannot perform IPsec authentication. For example, Woodgrove Bank wants all of its computers to block all unsolicited inbound network traffic from any computer that it does not manage. The connection security rules deployed to domain member computers require authentication as a domain member or by using a certificate before an unsolicited inbound network packet is accepted. 15

16 Computers in the isolated domain can still send outbound network traffic to untrusted computers and receive the responses to the outbound requests. For example, Woodgrove Bank wants its users at client computers to be able to access Web sites on the Internet. The default Windows Firewall with Advanced Security settings for outbound network traffic allow this. No additional rules are required. These goals also support optional zones that can be created to add customized protection to meet the needs of subsets of an organization's computers: Computers in the "boundary zone" are configured to use connection security rules that request but do not require authentication. This enables them to receive unsolicited inbound network traffic from untrusted computers, and also to receive traffic from the other members of the isolated domain. For example, Woodgrove Bank has a server that must be accessed by its partners' computers through the Internet. The rules applied to computers in the boundary zone use authentication when the client computer can support it, but do not block the connection if the client computer cannot authenticate. Computers in the "encryption zone" require that all network traffic in and out must be encrypted to secure potentially sensitive material when it is sent over the network. For example, Woodgrove Bank wants the computers running SQL Server to only transmit data that is encrypted to help protect the sensitive data stored on those computers. The following components are required for this deployment goal: Active Directory: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see Additional Resources. Next: Require Encryption When Accessing Sensitive Network Resources Require Encryption When Accessing Sensitive Network Resources The use of authentication in the previously described goal (Restrict Access to Only Trusted Computers) enables a computer in the isolated domain to block traffic from untrusted computers. However, it does not prevent an untrusted computer from eavesdropping on the network traffic shared between two trusted computers, because by default network packets are not encrypted. For computers that share sensitive information over the network, Windows Firewall with Advanced Security allows you to require that all such network traffic be encrypted. Using encryption can help you comply with regulatory and legislative requirements such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations. By creating connection security rules that apply to computers that host and exchange sensitive data, you can help protect the confidentiality of that data by encrypting it. 16

17 The following illustration shows an encryption zone in an isolated domain. The rules that implement both the isolated domain and the different zones are deployed by using Group Policy and Active Directory. This goal provides the following benefits: Computers in the encryption zone require authentication to communicate with other computers. This works no differently from the domain isolation goal and design. For more information, see Restrict Access to Only Trusted Computers. Computers in the encryption zone require that all inbound and outbound network traffic be encrypted. For example, Woodgrove Bank processes sensitive customer data on a computer that must be protected from eavesdropping by computers on the network. Connection security rules specify that all traffic must be encrypted by a sufficiently complex encryption algorithm to help protect the data. Computers in the encryption zone are often good candidates for server isolation, where access is limited to only computer accounts and user accounts that are members of an authorized access group. In many organizations, the encryption zone and the server isolation zone are one and the same. For more information, see Restrict Access to Only Specified Users or Computers. The following components are required for this deployment goal: Active Directory: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see Additional Resources. Next: Restrict Access to Only Specified Users or Computers 17

18 Restrict Access to Only Specified Users or Computers Domain isolation (as described in the previous goal Restrict Access to Only Trusted Computers) prevents computers that are members of the isolated domain from accepting network traffic from untrusted computers. However, some computers on the network might host sensitive data that must be additionally restricted to only those users and computers that have a business requirement to access the data. Windows Firewall with Advanced Security enables you to restrict access to computers and users that are members of domain groups authorized to access that computer. These groups are called network access groups (NAGs). When a computer authenticates to a server, the server checks the group membership of the computer account and the user account, and grants access only if membership in the NAG is confirmed. Adding this check creates a virtual "secure zone" within the domain isolation zone. You can have multiple computers in a single secure zone, and it is likely that you will create a separate zone for each set of servers that have specific security access needs. Computers that are part of this server isolation zone are often also part of the encryption zone (see Require Encryption When Accessing Sensitive Network Resources). Restricting access to only users and computers that have a business requirement can help you comply with regulatory and legislative requirements, such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations. Windows Vista and Windows Server 2008 enable you to restrict access by specifying either computer or user credentials. Windows XP and Windows Server 2003 do not support user-based authentication, but a similar behavior can be achieved by denying the "Access this computer from the network" user right to all users except members of the NAG. The following illustration shows an isolated server, and examples of computers that can and cannot communicate with it. Computers that are outside the Woodgrove corporate network, or computers that are in the isolated domain but are not members of the required NAG, cannot communicate with the isolated server. 18

19 This goal, which corresponds to Server Isolation Policy Design, provides the following features: Isolated servers accept unsolicited inbound network traffic only from computers or users that are members of the NAG. Isolated servers can be implemented as part of an isolated domain, and treated as another zone. Members of the zone group receive a GPO with rules that require authentication, and that specify that only network traffic authenticated as coming from a member of the NAG is allowed. Server isolation can also be configured independently of an isolated domain. To do so, configure only the computers that must communicate with the isolated server with connection security rules to implement authentication and check NAG membership. A server isolation zone can be simultaneously configured as an encryption zone. To do this, configure the GPO with rules that force encryption in addition to requiring authentication and restricting access to NAG members. For more information, see Require Encryption When Accessing Sensitive Network Resources. The following components are required for this deployment goal: Active Directory: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see Additional Resources. Next: Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design 19

20 Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design After you finish reviewing the existing Windows Firewall with Advanced Security deployment goals and you determine which goals are important to your specific deployment, you can map those goals to a specific Windows Firewall with Advanced Security design. Important The first three designs presented in this guide build on each other to progress from simpler to more complex. Therefore during deployment, consider implementing them in the order presented. Each deployed design also provides a stable position from which to evaluate your progress, and to make sure that your goals are being met before you continue to the next design. Use the following table to determine which Windows Firewall with Advanced Security design maps to the appropriate combination of Windows Firewall with Advanced Security deployment goals for your organization. This table refers only to the Windows Firewall with Advanced Security designs as described in this guide. However, you can create a hybrid or custom Windows Firewall with Advanced Security design by using any combination of the Windows Firewall with Advanced Security deployment goals to meet the needs of your organization. Deployment Goals Basic Firewall Policy Design Domain Isolation Policy Design Server Isolation Policy Design Certificate-based Isolation Policy Design Protect Computers from Unwanted Network Traffic Restrict Access to Only Trusted Computers Restrict Access to Only Specified Users or Computers Require Encryption When Accessing Sensitive Network Resources Yes Yes Yes Yes - Yes Yes Yes - - Yes Yes - Optional Optional Optional To examine details for a specific design, click the design title at the top of the column in the preceding table. Next: Basic Firewall Policy Design 20

21 Basic Firewall Policy Design Many organizations have a network perimeter firewall that is designed to prevent the entry of malicious traffic in to the organization's network, but do not have a host-based firewall enabled on each computer in the organization. The basic firewall policy design helps you to protect the computers in your organization from unwanted network traffic that gets through the perimeter defenses, or that originates from inside your network. In this design, you deploy firewall rules to each computer in your organization to allow traffic that is required by the programs that are used. Traffic that does not match the rules is dropped. Traffic can be blocked or permitted based on the characteristics of each network packet: its source or destination IP address, its source or destination port numbers, the program on the computer that receives the inbound packet, and so on. This design can also be deployed together with one or more of the other designs that add IPsec protection to the network traffic permitted. Many network administrators do not want to tackle the difficult task of determining all the appropriate rules for every program that is used by the organization, and then maintaining that list over time. In fact, most programs do not require specific firewall rules. The default behavior of Windows and most contemporary applications makes this task easy: On client computers, the default firewall behavior already supports typical client programs. Programs designed for Windows Vista and Windows Server 2008 create any required rules for you as part of the installation process. You only have to create a rule if the client program must be able to receive unsolicited inbound network traffic from another computer. When you install a server program that must accept unsolicited inbound network traffic, the installation program likely creates or enables the appropriate rules on the server for you. For example, when you install a server role by using the Role Management Tool in Windows Server 2008, the appropriate firewall rules are created and enabled automatically. For both Windows Server 2003 and Windows Server 2008, the Security Configuration Wizard configures firewall rules appropriate for the programs and services installed on the server. For other standard network behavior, the predefined rules that are built into Windows Vista and Windows Server 2008 can easily be configured in a GPO and deployed to the computers in your organization. For example, by using the predefined groups for Core Networking and File and Printer Sharing you can easily configure GPOs with rules for those frequently used networking protocols. With few exceptions, the firewall can be enabled on all configurations of Windows Vista or Windows Server Therefore, we recommended that you enable the firewall on every computer in your organization. This includes servers in your perimeter network, on mobile and remote clients that connect to the network, and on all servers and clients in your internal network. Caution Stopping the service associated with Windows Firewall with Advanced Security is not supported by Microsoft. 21

22 By default, in new installations, Windows Firewall is turned on in both Windows Vista and Windows Server If you must disable the firewall, such as when you want to use a third-party firewall program, do not disable Windows Firewall by stopping the service. Instead, use the Windows Firewall with Advanced Security interface (or equivalent Group Policy setting) to turn the firewall off. If you turn off the Windows Firewall with Advanced Security service you lose other benefits provided by the service, such as the ability to use IPsec connection security rules, Windows Service Hardening, and network protection from forms of attacks that use network fingerprinting. For more information about Windows Service Hardening, see Third-party firewall software that is compatible with Windows Vista and Windows Server 2008 can programmatically disable only the parts of Windows Firewall with Advanced Security that might need to be disabled for compatibility. Do not disable the firewall yourself for this purpose. An organization typically uses this design as a first step toward a more comprehensive Windows Firewall with Advanced Security design that adds server isolation and domain isolation. After implementing this design, your administrative team will have centralized management of the firewall rules applied to all computers that are running Windows in your organization. Important If you also intend to deploy the Domain Isolation Policy Design, or the Server Isolation Policy Design, we recommend that you do the design work for all three designs together, and then deploy in layers that correspond with each design. The basic firewall design can be applied to computers that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the firewall settings and rules. For more information about this design: This design coincides with the deployment goal to Protect Computers from Unwanted Network Traffic. To learn more about this design, see Firewall Policy Design Example. Before completing the design, gather the information described in Designing a Windows Firewall with Advanced Security Strategy. To help you make the decisions required in this design, see Planning Settings for a Basic Firewall Policy. For a list of detailed tasks that you can use to deploy your basic firewall policy design, see "Checklist: Implementing a Basic Firewall Policy Design" in the Windows Firewall with Advanced Security Deployment Guide at Next: Domain Isolation Policy Design 22

23 Domain Isolation Policy Design In the domain isolation policy design, you configure the computers on your network to accept only connections coming from computers that are authenticated as members of the same isolated domain. This design typically begins with a network configured as described in the Basic Firewall Policy Design section. For this design, you then add connection security and IPsec rules to configure computers in the isolated domain to accept only network traffic from other computers that can authenticate as a member of the isolated domain. After implementing the new rules, your computers reject unsolicited network traffic from computers that are not members of the isolated domain. The isolated domain might not be a single Active Directory domain. It can consist of all the domains in a forest, or domains in separate forests that have two-way trust relationships configured between them. By using connection security rules based on IPsec, you provide a logical barrier between computers even if they are connected to the same physical network segment. The design is shown in the following illustration, with the arrows that show the permitted communication paths. Characteristics of this design, as shown in the diagram, include the following: Isolated domain (area A) - Computers in the isolated domain receive unsolicited inbound traffic only from other members of the isolated domain or from computers referenced in authentication exemption rules. Computers in the isolated domain can send traffic to any 23

24 computer. This includes unauthenticated traffic to computers that are not in the isolated domain. Computers that cannot join an Active Directory domain, but that can use certificates for authentication, can be part of the isolated domain. For more information, see the Certificate-based Isolation Policy Design. Boundary zone (area B) - Computers in the boundary zone are part of the isolated domain but are allowed to accept inbound connections from untrusted computers, such as clients on the Internet. Computers in the boundary zone request but do not require authentication to communicate. When a member of the isolated domain communicates with a boundary zone member the traffic is authenticated. When a computer that is not part of the isolated domain communicates with a boundary zone member the traffic is not authenticated. Because boundary zone computers are exposed to network traffic from untrusted and potentially hostile computers, they must be carefully managed and secured. Put only the computers that must be accessed by external computers in this zone. Use firewall rules to ensure that network traffic is accepted only for services that you want exposed to non-domain member computers. Trusted non-domain members (area C) - Computers on the network that are not domain members or that cannot use IPsec authentication are allowed to communicate by configuring authentication exemption rules. These rules enable computers in the isolated domain to accept inbound connections from these trusted non-domain member computers. Untrusted non-domain members (area D) - Computers that are not managed by your organization and have an unknown security configuration must have access only to those computers required for your organization to correctly conduct its business. Domain isolation exists to put a logical barrier between these untrusted computers and your organization's computers. After implementing this design, your administrative team will have centralized management of the firewall and connection security rules applied to the computers that are running Windows Vista and Windows Server 2008 in your organization. Important This design builds on the Basic Firewall Policy Design, and in turn serves as the foundation for the Server Isolation Policy Design. If you plan to deploy all three, we recommend that you do the design work for all three together, and then deploy in the sequence presented. This design can be applied to computers that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the connection security rules. In order to expand the isolated domain to include computers that cannot be part of an Active Directory domain, see the Certificate-based Isolation Policy Design. For more information about this design: 24

25 This design coincides with the deployment goals to Protect Computers from Unwanted Network Traffic, Restrict Access to Only Trusted Computers, and optionally Require Encryption When Accessing Sensitive Network Resources. To learn more about this design, see the Domain Isolation Policy Design Example. Before completing the design, gather the information described in Designing a Windows Firewall with Advanced Security Strategy. To help you make the decisions required in this design, see Planning Domain Isolation Zones and Planning Group Policy Deployment for Your Isolation Zones. For a list of tasks that you can use to deploy your domain isolation policy design, see "Checklist: Implementing a Domain Isolation Policy Design" in the Windows Firewall with Advanced Security Deployment Guide at Next: Server Isolation Policy Design Server Isolation Policy Design In the server isolation policy design, you assign servers to a zone that allows access only to users and computers that authenticate as members of an approved network access group (NAG). This design typically begins with a network configured as described in the Domain Isolation Policy Design section. For this design, you then create zones for servers that have additional security requirements. The zones can limit access to the server to only members of authorized groups, and can optionally require the encryption of all traffic in or out of these servers. This can be done on a per server basis, or for a group of servers that share common security requirements. You can implement a server isolation design without using domain isolation. To do this, you use the same principles as domain isolation, but instead of applying them to an Active Directory domain, you apply them only to the computers that must be able to access the isolated servers. The GPO contains connection security and firewall rules that require authentication when communicating with the isolated servers. In this case, the NAGs that determine which users and computers can access the isolated server are also used to determine which computers receive the GPO. The design is shown in the following illustration, with arrows that show the permitted communication paths. 25

26 Characteristics of this design include the following: Isolated domain (area A) - The same isolated domain described in the Domain Isolation Policy Design section. If the isolated domain includes a boundary zone, then computers in the boundary zone behave just like other members of the isolated domain in the way that they interact with computers in server isolation zones. Isolated servers (area B) - Computers in the server isolation zones restrict access to computers, and optionally users, that authenticate as a member of a network access group (NAG) authorized to gain access. Encryption zone (area C) - If the data being exchanged is sufficiently sensitive, the connection security rules for the zone can also require that the network traffic be encrypted. Encryption zones are most often implemented as rules that are part of a server isolation zone, instead of as a separate zone. The diagram illustrates the concept as a subset for conceptual purposes only. To add support for server isolation, you must ensure that the authentication methods are compatible with the requirements of the isolated server. For example, if you want to authorize user accounts that are members of a NAG in addition to authorizing computer accounts, you must enable both user and computer authentication in your connection security rules. Important This design builds on the Domain Isolation Policy Design, which in turn builds on the Basic Firewall Policy Design. If you plan to deploy all three designs, do the design work for all three together, and then deploy in the sequence presented. 26

27 This design can be applied to computers that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the connection security rules. For more information about this design: This design coincides with the deployment goals to Protect Computers from Unwanted Network Traffic, Restrict Access to Only Trusted Computers, Restrict Access to Only Specified Users or Computers, and Require Encryption When Accessing Sensitive Network Resources. To learn more about this design, see Server Isolation Policy Design Example. Before completing the design, gather the information described in Designing a Windows Firewall with Advanced Security Strategy. To help you make the decisions required in this design, see Planning Server Isolation Zones and Planning Group Policy Deployment for Your Isolation Zones. For a list of tasks that you can use to deploy your server isolation policy design, see "Checklist: Implementing a Standalone Server Isolation Policy Design" in the Windows Firewall with Advanced Security Deployment Guide at Next: Certificate-based Isolation Policy Design Certificate-based Isolation Policy Design In the certificate-based isolation policy design, you provide the same types of protections to your network traffic as described in the Domain Isolation Policy Design and Server Isolation Policy Design sections. The only difference is the method used to share identification credentials during the authentication of your network traffic. Domain isolation and server isolation help provide security for the computers on the network that run Windows and that can be joined to an Active Directory domain. However, in most corporate environments there are typically some computers that must run another operating system, such as Linux or UNIX. These computers cannot join an Active Directory domain. Also, some computers that do run Windows cannot join a domain for a variety of reasons. Computers that are not joined to an Active Directory domain cannot use the default Kerberos V5 protocol to authenticate. To authenticate with non-domain member computers, IPsec supports using standards-based cryptographic certificates. Because this authentication method is also supported by many thirdparty operating systems, it can be used as a way to extend your isolated domain to computers that do not run the Windows operating system. The same principles of the domain and server isolation designs apply to this design. Only computers that can authenticate (in this case, by providing a specified certificate) can communicate with the computers in your isolated domain. For computers that run Windows and that are part of an Active Directory domain, you can use Group Policy to deploy the certificates required to communicate with the computers that are 27

28 trusted but are not part of the Active Directory domain. For other computers, you will have to either manually configure them with the required certificates, or use a third-party program to distribute the certificates in a secure manner. For more information about this design: This design coincides with the deployment goals to Protect Computers from Unwanted Network Traffic, Restrict Access to Only Trusted Computers, and optionally Require Encryption When Accessing Sensitive Network Resources. To learn more about this design, see Certificate-based Isolation Policy Design Example. Before completing the design, gather the information described in Designing a Windows Firewall with Advanced Security Strategy. To help you make the decisions required in this design, see Planning Certificate-based Authentication. For a list of tasks that you can use to deploy your certificate-based policy design, see "Checklist: Implementing a Certificate-based Isolation Policy Design" in the Windows Firewall with Advanced Security Deployment Guide at Next: Evaluating Windows Firewall with Advanced Security Design Examples Evaluating Windows Firewall with Advanced Security Design Examples The following Windows Firewall with Advanced Security design examples illustrate how you can use Windows Firewall with Advanced Security to improve the security of the computers connected to the network. You can use these topics to evaluate how the firewall and connection security rules work across all Windows Firewall with Advanced Security designs and to determine which design or combination of designs best suits the goals of your organization. Firewall Policy Design Example Domain Isolation Policy Design Example Server Isolation Policy Design Example Certificate-based Isolation Policy Design Example Firewall Policy Design Example In this example, the fictitious company Woodgrove Bank is a financial services institution. Woodgrove Bank has an Active Directory domain that provides Group Policy-based management for all their Windows-based computers. The Active Directory domain controllers also host Domain Name System (DNS) for host name resolution. Separate computers host Windows Internet Name Service (WINS) for network basic input/output system (NetBIOS) name resolution. A set of computers that are running UNIX provide the Dynamic Host Configuration Protocol (DHCP) services for automatic IP addressing. 28

29 Woodgrove Bank is in the process of migrating their computers from Windows XP with Service Pack 2 (SP2) and Windows Server 2003 with SP1 to Windows Vista and Windows Server A significant number of the computers at Woodgrove Bank continue to run Windows XP with SP2 and Windows Server 2003 with SP1. Interoperability between the previous and newer operating systems must be maintained. Wherever possible, security features applied to the newer operating systems must also be applied to the previous operating systems. A key line-of-business program called WGBank consists of a client program running on most of the desktop computers in the organization. This program accesses several front-end server computers that run the server-side part of WGBank. These front-end servers only do the processing they do not store the data. The data is stored in several back-end database computers that are running Microsoft SQL Server. Design requirements The network administrators want to implement Windows Firewall with Advanced Security throughout their organization to provide an additional security layer to their overall security strategy. They want to create firewall rules that allow their business programs to operate, while blocking network traffic that is not wanted. The following illustration shows the traffic protection needs for this design example. 29

30 1. The network infrastructure servers that are running services, such as Active Directory, DNS, DHCP, or WINS, can receive unsolicited inbound requests from network clients. The network clients can receive the responses from the infrastructure servers. 2. The WGBank front-end servers can receive unsolicited inbound traffic from the client computers and the WGBank partner servers. The WGBank client computers and partner servers can receive the response. 3. The WGBank front-end servers can send updated information to the client computers to support real-time display. The clients do not poll for this unsolicited traffic, but must be able to receive it. 4. The WGBank back-end servers can receive SQL query requests from the WGBank front-end servers. The WGBank front-end servers can receive the corresponding responses. 5. There is no direct communications between the client computers and the WGBank back-end computers. 6. There is no unsolicited traffic from the WGBank back-end computers to the WGBank frontend servers. 7. Company policy prohibits the use of peer-to-peer file transfer software. A recent review by the IT staff found that although the perimeter firewall does prevent most of the programs in this category from working, two programs are being used by staff members that do not require an outside server. Firewall rules must block the network traffic created by these programs. 8. The WGBank partner servers can receive inbound requests from partner computers through the Internet. Other traffic notes: Computers are not to receive any unsolicited traffic from any computer other than specifically allowed above. Other outbound network traffic from the client computers not specifically identified in this example is permitted. Design details Woodgrove Bank uses Active Directory groups and Group Policy objects to deploy the firewall settings and rules to the computers on their network. They know that they must deploy policies to the following collections of computers: Client computers that run Windows XP Client computers that run Windows Vista WGBank front-end servers that run Windows Server 2003 WGBank front-end servers that run Windows Server 2008 (there are none in place yet, but their solution must support adding them) WGBank partner servers that run Windows Server 2008 WGBank back-end SQL Server computers that run Windows Server

31 WGBank back-end SQL Server computers that run Windows Server 2008 (there are none in place yet, but their solution must support adding them) Infrastructure servers that run Windows Server 2008 Active Directory domain controllers that run Windows Server 2008 DHCP servers that run the UNIX operating system After evaluating these sets of computers, and comparing them to the Active Directory organizational unit (OU) structure, Woodgrove Bank network administrators determined that there was not a good one-to-one match between the OUs and the sets. Therefore the firewall GPOs will not be linked directly to OUs that hold the relevant computers. Instead, the GPOs are linked to the domain container in Active Directory, and then WMI and group filters are attached to the GPO to ensure that it is applied to the correct computers. Setting up groups as described here ensures that you do not have to know what operating system a computer is running before assigning it to a group. A combination of WMI filters and security group filters are used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. For some groups, you might have four or even five GPOs. The following groups were created by using the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, and all computers that run Windows were added to the correct groups: CG_FIREWALL_ALLCOMPUTERS. Add the predefined and system managed Domain computers group as a member of this group. All members of the FIREWALL_ALLCOMPUTERS group receive an operating system-specific GPO with the common firewall rules applied to all computers. The two computer types (client and server) are distinguished by using a WMI filters to ensure that only the policy intended for computers that are running a client version of Windows can be applied to that computer. A similar WMI filter on the server GPO ensures that only computers that are running server versions of Windows can apply that GPO. Each of the GPOs also have security group filters to prevent members of the group FIREWALL_NO_DEFAULT from receiving either of these two GPOs. Client computers receive a GPO that configures Windows Firewall with Advanced Security to enforce the default Windows Firewall behavior (allow outbound, block unsolicited inbound). The client default GPO also includes the built-in firewall rule groups Core Networking and File and Printer Sharing. The Core Networking group is enabled for all profiles, whereas the File and Printer Sharing group is enabled for only the Domain and Private profiles. The GPO also includes inbound firewall rules to allow the WGBank front-end server dashboard update traffic, and rules to prevent company-prohibited programs from sending or receiving network traffic, both inbound and outbound. Server computers receive a GPO that includes similar firewall configuration to the client computer GPO. The primary difference is that the rules are enabled for all profiles (not just domain and private). Also, the rules for WGBank dashboard update are not included, because it is not needed on server computers. 31

32 All rules are scoped to allow network traffic only from computers on Woodgrove Bank's corporate network. CG_FIREWALL_NO_DEFAULT. Members of this group do not receive the default firewall GPO. Computers are added to this group if there is a business requirement for it to be exempted from the default firewall behavior. The use of a group to represent the exceptions instead of the group members directly makes it easier to support the dynamic nature of the client computer population. A new computer joined to the domain is automatically given the appropriate default firewall GPO, unless it is a member of this group. CG_FIREWALL_WGB_FE. This group contains the computer accounts for all the WGBank front-end server computers. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow unsolicited WGBank client traffic. Computers in this group also receive the default firewall GPO. CG_FIREWALL_WGB_SQL. This group contains the computer accounts for all the WGBank back-end computers that run SQL Server. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow the SQL Server program to receive unsolicited queries only from the WGBank front-end servers. Computers in this group also receive the default firewall GPO. CG_FIREWALL_BOUNDARY_WGBANKFE. This group contains the computer accounts for the servers that host Web services that can be accessed from the Internet. Members of this group receive a GPO that adds an inbound firewall rule to allow inbound HTTP and HTTPS network traffic from any address, including the Internet. Computers in this group also receive the default firewall GPO. CG_FIREWALL_WINS. This group contains the computer accounts for all the WINS server computers. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with an inbound firewall rule to allow unsolicited inbound requests from WINS clients. Computers in this group also receive the default firewall GPO. CG_FIREWALL_ADDC. This group contains all the computer accounts for the Active Directory domain controller server computers. Members of this group receive a GPO that configures Windows Firewall with Advanced Security with inbound firewall rules to allow unsolicited Active Directory client and server-to-server traffic. Computers in this group also receive the default firewall GPO. In your own design, create a group for each computer role in your organization perform that requires different or additional firewall rules. For example, file servers and print servers require additional rules to allow the incoming network traffic for those functions. If a function is ordinarily performed on most computers on the network, you might consider adding computers performing those roles to the common default firewall GPO set, unless there is a security reason not to include it there. Next: Domain Isolation Policy Design Example 32

33 Domain Isolation Policy Design Example This design example continues to use the fictitious company Woodgrove Bank, and builds on the example described in the Firewall Policy Design Example section. See that example for an explanation of the basic corporate network infrastructure at Woodgrove Bank with diagrams. Design Requirements In addition to the basic protection provided by the firewall rules in the previous design example, the administrators of the network want to implement domain isolation to provide another layer of security to their networked computers. They want to create firewall and connection security rules that use authentication to reduce the risk of communicating with untrusted and potentially hostile computers. The following illustration shows the traffic protection needed for this design example. 1. All computers on the Woodgrove Bank corporate network that are Active Directory domain members must authenticate inbound network traffic as coming from another computer that is a member of the domain. Unless otherwise specified in this section, Woodgrove Bank's computers reject all unsolicited inbound network traffic that is not authenticated. If the basic firewall design is also implemented, even authenticated inbound network traffic is dropped unless it matches an inbound firewall rule. 2. The servers hosting the WGPartner programs must be able to receive unsolicited inbound traffic from computers owned by its partners, which are not members of Woodgrove Bank's domain. 33

34 3. Client computers can initiate non-authenticated outbound communications with computers that are not members of the domain, such as browsing external Web sites. Unsolicited inbound traffic from non-domain members is blocked. 4. Computers in the encryption zone require that all network traffic inbound and outbound must be encrypted, in addition to the authentication already required by the isolated domain. Other traffic notes: All of the design requirements described in the Firewall Policy Design Example section are still enforced. Design Details Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the computers on its network. Setting up groups as described here ensures that you don't have to know what operating system a computer is running before assigning it to a group. As in the firewall policy design, a combination of WMI filters and security group filters are used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. For some groups, you might have four or even five GPOs. The following groups were created by using the Active Directory Users and Computers MMC snap-in, all computers that run Windows were added to the correct groups, and then the appropriate GPO are applied to the group. To include a computer in the isolated domain or any one of its subordinate zones, simply add the computer's account in the appropriate group. CG_DOMISO_ISOLATEDDOMAIN. The members of this group participate in the isolated domain. After an initial pilot period, followed by a slowly increasing group membership, the membership of this group was eventually replaced with the entry Domain Computers to ensure that all computers in the domain participate by default. The WMI filters ensure that the GPO does not apply to domain controllers. GPOs with connection security rules to enforce domain isolation behavior are linked to the domain container and applied to the computers in this group. Filters ensure that each computer receives the correct GPO for its operating system type. The rules in the domain isolation GPO require Kerberos v5 authentication for inbound network connections, and request (but not require) it for all outbound connections. CG_DOMISO_NO_IPSEC. This group is denied read or apply permissions on any of the domain isolation GPOs. Any computer that cannot participate in domain isolation, such as a DHCP server running UNIX, is added to this group. CG_DOMISO_BOUNDARY. This group contains the computer accounts for all the computers that are part of the boundary group able to receive unsolicited inbound traffic from untrusted computers. Members of the group receive a GPO that configures connection security rules to request (but not require) both inbound and outbound authentication. CG_DOMISO_ENCRYPTION. This group contains the computer accounts for all the computers that require all inbound and outbound traffic to be both authenticated and encrypted. Members of the group receive a GPO that configures connection security and 34

35 firewall rules to require both authentication and encryption on all inbound and outbound traffic. Note If you are designing GPOs for only Windows Vista and Windows Server 2008, you can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, computers that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any computers that are incorrectly assigned to more than one group. None of the groups specify which operating system is running on the computers. Because Windows XP and Windows Server 2003 use different services and have different capabilities than Windows Vista and Windows Server 2008, they must use different GPOs. Multiple GPOs must be created for each group, each with settings and rules appropriate for a specific version of Windows. A combination of WMI and security group filtering is used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. For more information, see Planning GPO Deployment later in this guide. Next: Server Isolation Policy Design Example Server Isolation Policy Design Example This design example continues to use the fictitious company Woodgrove Bank, as described in the Firewall Policy Design Example section and the Domain Isolation Policy Design Example section. In addition to the protections provided by the firewall and domain isolation, Woodgrove Bank wants to provide additional protection to the computers that are running Microsoft SQL Server for the WGBank program. They contain personal data, including each customer's financial history. Government and industry rules and regulations specify that access to this information must be restricted to only those users who have a legitimate business need. This includes a requirement to prevent interception of and access to the information when it is in transit over the network. The information presented by the WGBank front-end servers to the client computers, and the information presented by the WGPartner servers to the remote partner computers, are not considered sensitive for the purposes of the government regulations, because they are processed to remove sensitive elements before transmitting the data to the client computers. In this guide, the examples show server isolation layered on top of a domain isolation design. If you have an isolated domain, the client computers are already equipped with GPOs that require authentication. You only have to add settings to the isolated server(s) to require authentication on 35

36 inbound connections, and to check for membership in the NAG. The connection attempt succeeds only if NAG membership is confirmed. Server isolation without domain isolation Server isolation can also be deployed by itself, to only the computers that must participate. The GPO on the server is no different from the one discussed in the previous paragraph for a server in an existing isolated domain. The difference is that you must also deploy a GPO with supporting connection security rules to the clients that must be able to communicate with the isolated server. Because those computers must be members of the NAG, that group can also be used in a security group filter on the client GPO. That GPO must contain rules that support the authentication requirements of the isolated server. In short, instead of applying the client GPO to all clients in the domain, you apply the GPO to only the members of the NAG. If you do not have an Active Directory domain then you can manually apply the connection security rules to the client computers, or you can use a netsh command-line script to help automate the configuration of the rules on larger numbers of computers. If you do not have an Active Directory domain, you cannot use the Kerberos V5 protocol, but instead must provide the clients and the isolated servers with certificates that are referenced in the connection security rules. Design requirements In addition to the protection provided by the firewall rules and domain isolation described in the previous design examples, the network administrators want to implement server isolation to help protect the sensitive data stored on the computers that run SQL Server. The following illustration shows the traffic protection needs for this design example. 36

37 1. Access to the SQL Server computers must be restricted to only those computer or user accounts that have a business requirement to access the data. This includes the service accounts that are used by the WGBank front-end servers, and administrators of the SQL Server computers. In addition, access is only granted when it is sent from an authorized computer. Authorization is determined by membership in a network access group (NAG). 2. All network traffic to and from the SQL Server computers must be encrypted. 3. Client computers or users whose accounts are not members of the NAG cannot access the isolated servers. Other traffic notes: All of the design requirements shown in the Firewall Policy Design Example section are still enforced. All of the design requirements shown in the Domain Isolation Policy Design Example section are still enforced. Design details Woodgrove Bank uses Active Directory groups and GPOs to deploy the server isolation settings and rules to the computers on its network. As in the previously described policy design examples, GPOs to implement the domain isolation environment are linked to the domain container in Active Directory, and then WMI filters and security group filters are attached to GPOs to ensure that the correct GPO is applied to each computer. The following groups were created by using the Active Directory Users and Computers snap-in, and all computers that run Windows were added to the correct groups. 37

38 CG_SRVISO_WGBANK_SQL. This group contains the computer accounts for the computers that run SQL Server. Members of this group receive a GPO with firewall and connections security rules that require that only users who are members of the group CG_NAG_SQL_USERS can access the server, and only when they are using a computer that is a member of the group CG_NAG_SQL_COMPUTERS. The group does not specify which operating system is running on the computer. Because Windows XP and Windows Server 2003 use different services and have different capabilities than Windows Vista and Windows Server 2008, they must use different GPOs. Multiple GPOs must be created, each one with settings and rules appropriate for a specific version of Windows. A combination of WMI and security group filtering is used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. Note If you are designing GPOs for only Windows Vista and Windows Server 2008, you can design your GPOs in nested groups. For example, you can make the isolated server group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the isolated server GPO. However, computers that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any computers that are incorrectly assigned to more than one group. Network access groups (NAGs) are not used to determine which GPOs are applied to a computer. Instead, these groups determine which users and computers can access the services on the isolated server. CG_NAG_SQL_COMPUTERS. This network access group contains the computer accounts that are able to access the computers running SQL Server hosting the WGBank data. Members of this group include the WGBank front-end servers, and some client computers from which SQL Server administrators are permitted to work on the servers. CG_NAG_SQL_USERS. This network access group contains the user accounts of users who are permitted to access the SQL Server computers that host the WGBank data. Members of this group include the service account that the WGBank front-end program uses to run on its computers, and the user accounts for the SQL Server administration team members. Note You can use a single group for both user and computer accounts. Woodgrove Bank chose to keep them separate for clarity. If Woodgrove Bank wants to implement server isolation without domain isolation, the CG_NAG_SQL_COMPUTERS group can also be attached as a security group filter on the GPOs 38

39 that apply connection security rules to the client computers. By doing this, all the computers that are authorized to access the isolated server also have the required connection security rules. You do not have to include the encryption-capable rules on all computers. Instead, you can create GPOs that are applied only to members of the NAG, in addition to the standard domain isolation GPO, that contain connection security rules to support encryption. Next: Certificate-based Isolation Policy Design Example Certificate-based Isolation Policy Design Example This design example continues to use the fictitious company Woodgrove Bank, as described in the sections Firewall Policy Design Example, Domain Isolation Policy Design Example, and Server Isolation Policy Design Example. One of the servers that must be included in the domain isolation environment is a computer running UNIX that supplies other information to the WGBank dashboard program running on the client computers. This computer sends updated information to the WGBank front-end servers as it becomes available, so it is considered unsolicited inbound traffic to the computers that receive this information. Design requirements One possible solution to this is to include an authentication exemption rule in the GPO applied to the WGBank front-end servers. This rule would instruct the front-end servers to accept traffic from the non-windows computer even though it cannot authenticate. A more secure solution, and the one selected by Woodgrove Bank, is to include the non-windows computer in the domain isolation design. Because it cannot join an Active Directory domain, and thus use Kerberos V5 based authentication, Woodgrove Bank chose to use certificate-based authentication. Certificates are cryptographically-protected documents, encrypted in such a way that their origin can be positively confirmed. In this case, Woodgrove Bank used Microsoft Certificate Services, included with Windows Server 2008, to create the appropriate certificate. They might also have acquired and installed a certificate from a third-party commercial certification authority. They then used Group Policy to deploy the certificate to the front-end servers. The GPOs applied to the front-end servers also include updated connection security rules that permit certificate-based authentication in addition to Kerberos V5 authentication. They then manually installed the certificate on the UNIX server. The UNIX server is configured with firewall and IPsec connection security rules using the tools that are provided by the operating system vendor. Those rules specify that authentication is performed by using the certificate. The creation of the IPsec connection security rules for a non-windows computer is beyond the scope of this document, but support for a certificate that can be used to authenticate such a non- Windows computer by using the standard IPsec protocols is the subject of this design. The non-windows computer can be effectively made a member of the boundary zone or the encryption zone based on the IPsec rules applied to the computer. The only constraint is that the 39

40 main mode and quick mode encryption algorithms supported by the UNIX computer must also be supported by the Windows-based computers with which it communicates. Other traffic notes: None of the capabilities of the other designs discussed in this guide are compromised by the use of certificate authentication by a non-windows computer. Design details Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the computers in their organization. The inclusion of one or more non-windows computers to the network requires only a simple addition to the GPOs for computers that must communicate with the non-windows computer. The addition is allowing certificate-based authentication in addition to the Active Directory supported Kerberos V5 authentication. This does not require including new rules, just adding certificatebased authentication as an option to the existing rules. When multiple authentication methods are available, two negotiating computers agree on the first one in their lists that match. Because the majority of the computers in Woodgrove Bank's network run Windows, Kerberos V5 is listed as the first authentication method in the rules. Certificatebased authentication is added as an alternate authentication type. By using the Active Directory Users and Computers snap-in, Woodgrove Bank created a group named NAG_COMPUTER_WGBUNIX. They then added the computer accounts to this group for Windows computers that need to communicate with the non-windows computers. If all the computers in the isolated domain need to be able to access the non-windows computers, then the Domain Computers group can be added to the group as a member. Woodgrove Bank then created a GPO that contains the certificate, and then attached security group filters to the GPO that allow read and apply permissions to only members of the NAG_COMPUTER_WGBUNIX group. The GPO places the certificate in the Local Computer / Personal / Certificates certificate store. The certificate used must chain back to a certificate that is in the Trusted Root Certification Authorities store on the local computer. Next: Designing a Windows Firewall with Advanced Security Strategy Designing a Windows Firewall with Advanced Security Strategy To select the most effective design for helping to protect the network, you must spend time collecting key information about your current computer environment. You must have a good understanding of what tasks the computers on the network perform, and how they use the network to accomplish those tasks. You must understand the network traffic generated by the programs running on the computers. Gathering the Information You Need Determining the Trusted State of Your Computers 40

41 The information that you gather will help you answer the following questions. The answers will help you understand your security requirements and select the design that best matches those requirements. The information will also help you when it comes time to deploy your design, by helping you to build a deployment strategy that is cost effective and resource efficient. It will help you project and justify the expected costs associated with implementing the design. What traffic must always be allowed? What are characteristics of the network traffic generated and consumed by the business programs? What traffic must always be blocked? Does your organization have policies that prohibit the use of specific programs? If so, what are the characteristics of the network traffic generated and consumed by the prohibited programs? What traffic on the network cannot be protected by IPsec because the computers or devices sending or receiving the traffic do not support IPsec? For each type of network traffic, does the default configuration of the firewall (block all unsolicited inbound network traffic, allow all outbound traffic) allow or block the traffic as required? Do you have an Active Directory domain (or forest of trusted domains) to which all your computers are joined? If you do not, then you cannot use Group Policy for easy mass deployment of your firewall and connection security rules. You also cannot easily take advantage of Kerberos V5 authentication that all domain clients can use. Which computers must be able to accept unsolicited inbound connections from computers that are not part of the domain? Which computers contain data that must be encrypted when exchanged with another computer? Which computers contain sensitive data to which access must be restricted to specifically authorized users and computers? Does your organization have specific network troubleshooting devices or computers (such as protocol analyzers) that must be granted unlimited access to the computers on the network, essentially bypassing the firewall? If you already have firewall or IPsec rules deployed Windows Firewall with Advanced Security in Windows Vista and Windows Server 2008 has many new capabilities that are not available in earlier versions of Windows. The IPsec and Windows Firewall policies that you create for computers that are running Windows XP and Windows Server 2003 can still be applied to computers that are running Windows Vista and Windows Server However, doing this prevents you from taking advantage of all the new features performance improvements included in Windows Vista and Windows Server If you already have a domain and/or server isolation deployment in your organization then you must evaluate and choose between two options: Option 1: Use the existing GPOs already in place and apply them to computers that are running Windows Vista and Windows Server If you choose to do this then you must 41

42 use the Windows Firewall and IPsec guidance applicable to Windows XP and Windows Server Design and deployment guidance for those technologies is available on the Web at "Server and Domain Isolation Using IPsec and Group Policy" ( It is also available in downloadable form at Option 2: Create new GPOs for computers that are running Windows Vista and Windows Server 2008, and use WMI and group filters to ensure that the correct GPOs apply to your computers. This is the technique discussed in this guide and its accompanying deployment guide. If you choose this technique, you must ensure that the IPsec policies you apply to your computers that are running different operating systems are compatible with each other. For example, a server that is running Windows Server 2008 can use a broader set of authentication and encryption settings than are available on Windows XP and Windows Server To ensure that client computers that are running both older and newer operating systems can access the resources on a server, the server must include in its IKE negotiation offers at least one algorithm that each client can use. You can choose to use the newer, more advanced settings to help secure traffic to a client that is running Windows Vista, but if the server must also be accessed by computers that are running previous versions of Windows, then the server must also offer authentication methods that those computers can use. This guide describes how to plan your groups and GPOs for an environment with a mix of operating systems. Details can be found in the section Planning Group Policy Deployment for Your Isolation Zones later in this guide. Next: Gathering the Information You Need Gathering the Information You Need Before starting the planning process for a Windows Firewall with Advanced Security deployment, you must collect and analyze up-to-date information about the network, the directory services, and the computers that are already deployed in the organization. This information enables you to create a design that accounts for all possible elements of the existing infrastructure. If the gathered information is not accurate, problems can occur when devices and computers that were not considered during the planning phase are encountered during implementation. Review each of the following topics for guidance about the kinds of information that you must gather: Gathering Information about Your Current Network Infrastructure Gathering Information about Your Active Directory Deployment Gathering Information about Your Computers Gathering Other Relevant Information 42

43 Gathering Information about Your Current Network Infrastructure Perhaps the most important aspect of planning for Windows Firewall with Advanced Security deployment is the network architecture, because IPsec is layered on the Internet Protocol itself. An incomplete or inaccurate understanding of the network can prevent any Windows Firewall with Advanced Security solution from being successful. Understanding subnet layout, IP addressing schemes, and traffic patterns are part of this effort, but accurately documenting the following components are important to completing the planning phase of this project: Network segmentation. This includes IP addressing maps, showing how your routers separate each network segment. It includes information about how the routers are configured, and what security filters they impose on network traffic flowing through them. Network address translation (NAT). NAT is a means of separating network segments by using a device that maps all of the IP addresses on one side of the device to a single IP address accessible on the other side. Network infrastructure devices. This includes the routers, switches, hubs, and other network equipment that makes communications between the computers on the network possible. Current network traffic model. This includes the quantity and the characteristics of the network traffic flowing through your network. The goal is to have enough information to be able to identify an asset by its network location, in addition to its physical location. Do not use a complex and poorly documented network as a starting point for the design, because it can leave too many unidentified areas that are likely to cause problems during implementation. This guidance helps obtain the most relevant information for planning Windows Firewall with Advanced Security implementation, but it does not try to address other issues, such as TCP/IP addressing or virtual local area network (VLAN) segmentation. Network segmentation If your organization does not have its current network architecture documented and available for reference, such documentation should be obtained as soon as possible before you continue with the design and deployment. If the documented information is not current or has not been validated recently, you have two options: Accept that the lack of accurate information can cause risk to the project. Undertake a discovery project, either through manual processes or with network analysis tools that can provide the information you need to document the current network topology. Although the required information can be presented in many different ways, a series of schematic diagrams is often the most effective method of illustrating and understanding the current network configuration. When creating network diagrams, do not include too much information. If necessary, use multiple diagrams that show different layers of detail. Use a top-level diagram that illustrates the major sites that make up your organization's network, and then break out each site into a more detailed diagram that captures a deeper level of detail. Continue until you reach the individual IP subnet level, and so have the means to identify the network location of every computer in your organization. 43

44 During this process, you might discover some network applications and services that are not compatible with IPsec. For example, IPsec breaks network-based prioritization and port/protocolbased traffic management. If traffic management or prioritization must be based on ports or protocol, the host itself must be able to perform any traffic management or prioritization. Other examples of incompatibility include: Cisco NetFlow on routers cannot analyze packets between IPsec members based on protocol or port. Router-based Quality of Service (QoS) cannot use ports or protocols to prioritize traffic. However, using firewall rules that specify IP addresses to prioritize traffic are not affected by this limitation of QoS. For example, a rule that says "From anyone to anyone using port 80 prioritize" does not work, but a rule that says "From anyone to prioritize" works. Weighted Fair Queuing and other flow-based router traffic priority methods might fail. Devices that do not support or allow IP protocol 50, the port that is used by Encapsulating Security Payload (ESP). Router access control lists (ACLs) cannot examine protocol and port fields in ESP-encrypted packets, and therefore the packets are dropped. ACLs based only on IP address are forwarded as usual. If the device cannot parse ESP, any ACLs that specify port or protocol rules will not be processed on the ESP packets. If the device has an ESP parser and uses encryption, ACLs that specify port or protocol rules will not be processed on the ESP packets. Network monitoring tools might be unable to parse ESP packets that are not encrypted (ESP- Null). Note Network Monitor added an ESP parser starting in version 2.1 to aid troubleshooting of unencrypted IPsec packets. The latest version of Network Monitor is available as a free download from Microsoft ( Network address translation (NAT) Special consideration is required if NAT devices are present and separate some of the network segments from others. NAT blocks the use of Authentication Header (AH) between computers that are separated by a NAT device. If NAT devices exist on the internal network then you must specify ESP instead of AH. ESP allows you to encrypt data, but does not require encryption. ESP can be implemented by using null encryption, which provides the strongest IPsec peer-to-peer communication possible without breaking communications through NAT. IPsec NAT traversal (NAT-T) enables IPsec peers that are behind NATs to detect the presence of NATs, negotiate IPsec security associations (SAs), and send ESP-protected data even though the addresses in the IPsec-protected IPv4 packets change. IPsec NAT-T does not support the use of AH across NAT devices. IPsec NAT-T is supported by Windows Vista, Windows Server 2008, Windows Server 2003 with SP1, Windows XP with SP2, and by Windows 2000 Server with SP4 with a free Web download. For more information, see "L2TP/IPsec NAT-T update for Windows XP SP1 and Windows 2000 Server" at This is a client-side update only, and 44

45 does not enable a computer that is running Windows 2000 Server to receive an incoming IPsec protected connection from a client computer that is behind a NAT device. For detailed information about how IPsec NAT-T works, see "IPsec NAT Traversal Overview" in the August 2002 Cable Guy article at Do not put servers behind NAT devices Do not put servers that must be available to public IPsec clients on the private networks behind NAT devices. Windows XP with SP2 and later operating systems by default do not support establishing IPsec connection to servers that are located on the private network behind a NAT device. For more information, see "IPsec NAT-T is Not Recommended for Windows Server Computers that are Behind Network Address Translators" at This only affects servers behind the NAT device. The article does not apply to client computers. For more information about the challenges and risks associated with positioning servers behind NAT devices, see "Problems with Using Network Address Translators" in the Cable Guy article at If you must locate a server on the private network behind a NAT device, then you must do the following: Configure the Windows clients that must access the server to enable IPsec security associations to servers that are located behind a NAT device. For instructions about how to configure the clients for that scenario, see "L2TP/IPsec NAT-T update for Windows XP SP1 and Windows 2000 Server at The instructions apply to all later service packs of Windows XP, although the download itself is only applicable to SP1. This can be especially challenging if the client computers that need access to the server are not managed by your organization. To ensure that a server is reachable from behind a NAT device for IPsec traffic, you must configure the NAT device with static translation entries that map IKE (using UDP port 500) and IPsec NAT-T (using UDP port 4500) traffic to the correct server. Network infrastructure devices The devices that make up the network infrastructure (routers, switches, load balancers, and firewalls) must be able communicate using IPsec after the solution is implemented. For this reason, you have to examine the following characteristics of these network devices to ensure that they can handle the technical and physical requirements of the design: Make/model. You can use this information to determine the features that the device supports. In addition, check the BIOS version or software running on the device to ensure that IPsec is supported. Amount of RAM. This information is useful when you are analyzing capacity or the impact of IPsec on the device. Traffic analysis. Information, such as peak usage and daily orweekly trends, is helpful to have. The information helps provide a baseline snapshot of the device and how it is used 45

46 over time. If problems occur after IPsec is implemented, the information can help determine whether the root cause is related to greater usage of the device. Router ACLs that affect IPsec directly. ACLs directly affect the ability of specific protocols to function. For example, blocking the Kerberos V5 protocol (UDP and TCP port 88) or IP protocol 50 or 51 prevents IPsec from working. Devices must also be configured to allow IKE traffic (UDP port 500) if using NAT-T (UDP port 4500). Networks/subnets connected to device interfaces. This information provides the best picture of what the internal network looks like. Defining the boundary of subnets based on an address range is straightforward and helps identify whether other addresses are either unmanaged or foreign to the internal network (such as IP addresses on the Internet). VLAN segmentation. Determining how VLANs are implemented on the network can help you understand traffic patterns and security requirements, and then help to determine how IPsec might augment or interfere with these requirements. The maximum transmission unit (MTU) size on device interface(s). The MTU defines the largest datagram that can be transmitted on a particular interface without being divided into smaller pieces for transmission (a process also known as fragmentation). In IPsec communications, the MTU is necessary to anticipate when fragmentation occurs. Packet fragmentation must be tracked for Internet Security Association and Key Management Protocol (ISAKMP) by the router. IPsec configures the MTU size on the session to the minimum-discovered MTU size along the communication path being used, and then set the Don't Fragment bit (DF bit) to 1. Note If Path MTU (PMTU) discovery is enabled and functioning correctly, you do not have to gather the MTU size on device interfaces. Although sources, such as the Windows Server 2003 Hardening Guide, recommend disabling PMTU discovery, it must be enabled for IPsec to function correctly. Intrusion detection system (IDS) in use. Your IDS must have an IPsec-compatible parser to interpret data inside secured packets. If the IDS does not have such a parser, it cannot examine data in those packets to determine whether a particular session is a potential threat. After you obtain this information, you can quickly determine whether you must upgrade the devices to support the requirements of the project, change the ACLs, or take other measures to ensure that the devices can handle the loads needed. Current network traffic model After gathering the addressing and network infrastructure information, the next step is to examine the communications flow. For example, if a department such as Human Resources (HR) spans several buildings, and you want to use server isolation with encryption to help protect information in that department, you must know how those buildings are connected to determine the level of "trust" to place in the connection. A highly secured building that is connected by an unprotected cable to another building that is not secured can be compromised by an eavesdropping or information replay attack. If such an attack is considered a threat, IPsec can help by providing 46

47 strong mutual authentication and traffic encryption for trusted hosts. However, the solution cannot account for the fact that a lack of physical security on trusted hosts will remain a threat. When you examine traffic flow, look closely at how all managed and unmanaged devices interact. This includes non-windows-based computers running Linux, UNIX, and Macintosh. Ask yourself such questions as, Do specific communications occur at the port and protocol level, or are there many sessions between the same hosts across many protocols? How do servers and clients communicate with each other? Are there security devices or projects currently implemented or planned that could affect an isolation deployment? For example, if you use Windows Firewall on your computers to "lock down" specific ports, such as UDP 500, IKE negotiations fail. Some of the more common applications and protocols are as follows: NetBIOS over TCP/IP (NetBT) and server message block (SMB). On a LAN, it is common to have ports 137, 138, and 139 enabled for NetBT and port 445 enabled for SMB. These ports provide NetBIOS name resolution services and other features. Unfortunately, they also allow the creation of null sessions. A null session is a session that is established on a host that does not use the security context of a known user or entity. Frequently, these sessions are anonymous. Remote procedure call (RPC). RPC operates by listening on a port known as the endpoint mapper, TCP port 135. The response to a query on this port is an instruction to begin communication on another port in the ephemeral range (ports numbered over 1024). In a network that is segmented by firewalls, RPC communication presents a configuration challenge because it means opening the RPC listener port and all ports greater than Opening so many ports increases the attack surface of the whole network and reduces the effectiveness of the firewalls. Computers running Windows Vista and Windows Server 2008 reduce this risk by introducing stateful inspection of RPC traffic. Because many applications depend on RPC for basic functionality, any firewall and connection security policy must take RPC requirements into account. Other traffic. Windows Firewall with Advanced Security can help secure transmissions between computers by providing authentication of the packets in addition to encrypting the data that they contain. The important thing to do is to identify what must be protected, and the threats that must be mitigated. Examine and model other traffic or traffic types that must be secured. Next: Gathering Information about Your Active Directory Deployment Gathering Information about Your Active Directory Deployment Active Directory is another important item about which you must gather information. You must understand the forest structure. This includes domain layout, organizational unit (OU) architecture, and site topology. This information makes it possible to know where computers are currently placed, their configuration, and the impact of changes to Active Directory that result from implementing Windows Firewall with Advanced Security. Review the following list for information needed: 47

48 Names and number of forests. The forest (not the domain) is the security boundary in an Active Directory implementation. You must understand the current Active Directory architecture to determine the most effective strategy for deploying your firewall and connection security rules using Group Policy. It also enables you to understand which computers can be isolated and how best to accomplish the required degree of isolation. Names and number of domains. Authentication in server and domain isolation uses the IKE negotiation process with the Kerberos V5 protocol. This protocol assumes that computers are domain members. Number and types of trusts. Trusts affect the logical boundaries of domain isolation and define whether IKE negotiation can occur between computers in different Active Directory domains. Names and number of sites. Site architecture is usually aligned with the network topology. Understanding how sites are defined in Active Directory will help provide insight into replication and other details. Site architecture can provide a better understanding of the current Active Directory deployment. OU structure. OUs are logical constructs and can therefore be molded to fit many different requirements and goals. The OU structure is an ideal place to examine how Group Policy is currently used and how the OUs are laid out. You do not have to redesign an already implemented OU structure in order to effectively deploy firewall and connection security policy, but an understanding of the structure helps you know what WMI or group filtering is required to apply each GPO to the correct computers. Existing IPsec policy. Because this project culminates in the implementation of IPsec policy, you must understand how the network currently uses IPsec (if at all). Windows Firewall with Advanced Security connection security rules for Windows Vista and Windows Server 2008 are not compatible with earlier versions of Windows. If you already have IPsec policies deployed to computers running Windows XP and Windows Server 2003 in your organization, you must ensure that the new IPsec policies you deploy enable computers using either the old or new IPsec policies to communicate with each other. Next: Gathering Information about Your Computers Gathering Information about Your Computers One of the most valuable benefits of conducting an asset discovery project is the large amount of data that is obtained about the client and server computers on the network. When you start designing and planning your isolation zones, you must make decisions that require accurate information about the state of all hosts to ensure that they can use IPsec as planned. Capture the following information from each computer: Computer name. This name is the computer's NetBIOS or DNS name that identifies the computer on the network. Because a computer can have more than one media access control (MAC) or IP address, the computer's name is one of the criteria that can be used to determine uniqueness on the network. Because computer names can be duplicated under some circumstances, the uniqueness should not be considered absolute. 48

49 IP address for each network adapter. The IP address is the address that is used with the subnet mask to identify a host on the network. An IP address is not an effective way to identify an asset because it is often subject to change. MAC address for each network adapter. The MAC address is a unique 48-bit address that is used to identify a network adapter. It can be used to help differentiate between different network adapters on the same device. Operating system, service pack, and hotfix versions. The operating system version is a key factor in determining the ability of a host to communicate by using IPsec. It is also important to track the current state of service packs and updates that might be installed, because these are often used to determine that minimum security standards have been met. Domain membership. This information is used to determine whether a computer can obtain IPsec policy from Active Directory or whether it must use a local IPsec policy. Physical location. This information is just the location of the device in your organization. It can be used to determine whether a device can participate in a specific isolation group based on its location or the location of the devices that it communicates with regularly. Hardware type or role. Some tools that perform host discovery can provide this information by querying the hardware information and running applications to determine its type, such as server, workstation, or portable computer. You can use this information to determine the appropriate IPsec policy to assign, whether a specific computer can participate in isolation, and in which isolation group to include the computer. After collecting all this information and consolidating it into a database, perform regular discovery efforts periodically to keep the information current. You need the most complete and up-to-date picture of the managed hosts on their networks to create a design that matches your organization's requirements. You can use various methods to gather data from the hosts on the network. These methods range from high-end, fully automated systems to completely manual data collection. Generally, the use of automated methods to gather data is preferred over manual methods for reasons of speed and accuracy. Automated Discovery Using an automated auditing network management system such as Microsoft System Center Configuration Manager (formerly known as Systems Management Server) provides valuable information about the current state of the IT infrastructure. For more information about how System Center Configuration Manager 2007 can help perform automated information gathering, see Manual Discovery The biggest difference between manual discovery methods and automated methods is time. You can use the Windows Script Host (WSH), VBScript, and Windows Management Instrumentation (WMI) to create a script file that can collect the system configuration information. VBScript and WMI are built-in to Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server In addition, PowerShell is available as a free 49

50 download for computers that run Windows XP, Windows Server 2003, or later versions. Starting with Windows Server 2008, PowerShell is included with the operating system. For more information, see Scripting with Windows Powershell ( Whether you use an automatic, manual, or hybrid option to gather the information, one of the biggest issues that can cause problems to the design is capturing the changes between the original inventory scan and the point at which the implementation is ready to start. After the first scan has been completed, make support staff aware that all additional changes must be recorded and the updates noted in the inventory. This inventory will be critical for planning and implementing your Windows Firewall with Advanced Security design. Next: Gathering Other Relevant Information Gathering Other Relevant Information This topic discusses several other things that you should examine to see whether they will cause any complications in your ability to deploy Windows Firewall with Advanced Security policies in your organization. Capacity considerations Because IPsec uses mathematically intensive cryptographic techniques, it can consume significant overhead on a computer. Areas to watch: Encryption. You might use 256-bit Advanced Encryption Standard (AES-256) and 384-bit Secure Hash Algorithm (SHA-384) to check integrity in situations that require the strongest available encryption and key exchange protection. Security association (SA) negotiation. You can use a shorter lifetime for the main mode SA, such as three hours, but then you might need to make tradeoffs. Because each main mode SA occupies approximately 5 KB of RAM, situations in which a server brokers tens of thousands of concurrent connections can lead to overutilization. NAT devices. As discussed earlier, NAT does not allow Authentication Header (AH) conversations between hosts. If NAT devices exist on the internal network, ESP must be selected instead of AH. ESP provides for the ability to encrypt data, but does not require encryption. ESP null encryption provides the strongest IPsec peer-to-peer communication through NAT. And because it does not use encryption, it has a lower impact than ESP with encryption. Switches and routers. Proper capacity planning for the implementation of IPsec is more about thorough testing and expected traffic loads than exact calculations. You might have to upgrade or reconfigure switches or routers that currently exceed 75 percent usage to allow for increased traffic on the device and still provide some extra usage for bursts of traffic. Other factors. These include CPU usage on network infrastructure servers, increased overhead on servers and workstations running IPsec (especially servers, because they 50

51 usually contain more main mode SAs than clients), and increased network latency because of IPsec negotiation. Note When Microsoft deployed its own domain isolation solution, it found a one to three percent increase in usage on the network as a direct result of IPsec. Group Policy deployment groups and WMI filters You do not have to rearrange the organization unit (OU) hierarchy of your Active Directory domains to effectively deploy Windows Firewall with Advanced Security GPOs. Instead, you can link your GPOs at the domain level (or another high level container), and then use security group filtering or WMI filtering to ensure that only the appropriate computers or users can apply the GPO settings. Because the firewall and connection security rules have evolved significantly from Windows 2000 Server to Windows XP and Windows Server 2003, and now with Windows Vista and Windows Server 2008, we recommend that you use WMI filtering to dynamically ensure that GPOs apply only to computers that are running the correct operating system. If you have computers that are running Windows 2000 Server, WMI filtering is not available, and you must create a computer group to contain the accounts for those computers, and then apply security permissions to GPOs for all later operating systems so that other members of that group do not apply the GPOs. The Woodgrove Bank examples throughout this guide illustrate the technique. Different Active Directory trust environments When you design a domain isolation policy, consider any logical boundaries that might affect IPsec-secured communications. For example, the trust relationships between your domains and forests are critical in determining an appropriate IKE authentication method. Kerberos V5 authentication is recommended for use in a two-way (mutual) domain and forest trust environment. You can use Kerberos V5 for IKE authentication across domains that have two-way trusts established, if the domains are in the same forest or different forests. If the two domains are in different forests, you must configure two external trusts, one for each direction, between the domains. The external trusts must use the fully qualified domain name (FQDN) of the domains, and IPsec policy must allow an IKE initiator in one domain to communicate with any domain controller in the forest domain hierarchy, so that the initiator can obtain a Kerberos V5 ticket from a domain controller in the responder s domain. If firewalls separate the domains then you must configure the firewall to allow Kerberos V5 traffic over UDP destination port 88, TCP destination port 88, and UDP destination port 389. For more information, see "Active Directory in Networks Segmented by Firewalls" at If the use of Kerberos V5 authentication is not possible because two-way trusts across forests cannot be established as in some large enterprise environments, you can use a public key infrastructure (PKI) and digital certificates to establish IPsec-trusted communication. For an example of how Microsoft deployed their PKI, see "Deploying PKI Inside Microsoft" at 51

52 Creating firewall rules to permit ISAKMP, AH, and ESP traffic In some cases, IPsec-secured traffic might have to pass through a router, perimeter firewall, or other filtering device. In the case of a router, unless the router filters TCP and UDP traffic or other upper-level protocol headers, no special configuration is required to allow the IPsec traffic to be forwarded. In the case of a filtering router or a firewall, you must configure these devices to allow IPsec traffic to be forwarded. Configure the firewall to allow IPsec traffic on UDP source and destination port 500 (ISAKMP), UDP source and destination port 4500 (IPsec NAT-T), and IP Protocol 50 (ESP). You might also have to configure the firewall to allow IPsec traffic on IP protocol 51 (AH) to allow troubleshooting by IPsec administrators and to allow the IPsec traffic to be inspected. For more information, see "How to Enable IPsec Traffic Through a Firewall" at Network load balancing and server clusters There are challenges implementing connection security for network traffic going to and from network load balancing (NLB) clusters and server clusters. NLB enables multiple servers to be clustered together to provide high availability for a service by providing automatic failover to other nodes in the cluster. Because IPsec matches a security association to a specific computer, it prevents different computers from handling the same client connection. If a different node in the cluster responds to an IPsec connection that was originally established by another node, the traffic will be dropped by the client computer as untrusted. This means that NLB in "no affinity" mode is not supported by IPsec at all. If you must use "no affinity" mode in the cluster then consider including the servers that make up the cluster in your IPsec exemption group, and allowing clients to communicate with the servers without IPsec. Issues with IPsec on clusters running on Windows 2000 Server or Windows Server 2003 Even when not using "no affinity" mode there are challenges. If a node in the cluster fails, existing IPsec connections to that server cannot detect the failover, but attempt to rebuild the security association until the preset time-out period expires. In Windows 2000 Server, IPsec must be idle for five minutes before the client attempts to re-authenticate. This causes a two-to-six minute interruption in service for that client. Windows XP with SP2, and Windows Server 2003 with SP1 reduce the preset time-out period to one minute. There will always be a delay if a client is connected to a cluster node that fails. For more information about IPsec and configuring NLB clusters, see the following articles on the Microsoft Support Site: "How to Configure Network Load Balancing to Work with IPsec" at "IPsec is not designed for failover" at "How to Configure IPsec on an Exchange Server 2003 Back-End Server That Is Running on a Windows Server 2003 Server Cluster" at IPsec improvements for clusters running Windows Server

53 In Windows Server 2008, IPsec is much more tightly integrated into TCP/IP than in earlier versions of Windows. When a TCP connection is dropped because of a cluster node failover, IPsec on a computer that is running Windows Vista and Windows Server 2008 detects the TCP connection failure and removes the IPsec SAs for that connection. When the new TCP connection is established to another node, IPsec can negotiate new SAs immediately without having to wait for the obsolete SAs to time out. Network inspection technologies Within a TCP/IP packet, IPsec without encryption changes the offsets for the destination ports and protocols. These changes can adversely affect applications that are running on network devices such as routers that monitor and manage traffic on the network. While some network applications have been updated to support IPsec, some are not yet compatible. Check with the vendor of your device to see whether the changes in the protocol and port fields caused by IPsec are compatible with the device. Any device designed to view network traffic, such as hardware protocol analyzers or Microsoft Network Monitor, cannot parse ESP-encrypted traffic. Only the destination computer, with which the originating computer negotiated the connection, can decrypt the traffic. In general, IPsec defeats network-based prioritization and port- or protocol-based traffic management. For encrypted packets, there is no workaround; the host 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. If you cannot upgrade monitoring or management devices to support IPsec, it is important that you record this information and figure it into your domain or server isolation design. Network Monitor includes parsers for the ISAKMP (IKE), AH, and ESP protocols. Network Monitor parsers for ESP can parse inside the ESP packet only if ESP null-encryption is being used. Network Monitor cannot parse the encrypted parts of IPsec ESP traffic when encryption is performed in software. However, if encryption is performed by an IPsec hardware offload network adapter, the ESP packets can be decrypted when Network Monitor captures them on either the source or the destination and, therefore, they can be parsed. To diagnose ESP softwareencrypted communication, you must disable ESP encryption and use ESP-null encryption by changing the IPsec policy or connection security rule on both computers. Network Monitor is available as a free download from Microsoft at Next: Determining the Trusted State of Your Computers Determining the Trusted State of Your Computers After obtaining information about the computers that are currently part of the IT infrastructure, you must determine at what point a computer is considered trusted. The term trusted can mean different things to different people. Therefore, you must communicate a firm definition for it to all stakeholders in the project. Failure to do this can lead to problems with the security of the trusted 53

54 environment, because the overall security cannot exceed the level of security set by the least secure client that achieves trusted status. Note In this context, the term trust has nothing to do with an Active Directory trust relationship between domains. The trusted state of your computers just indicates the level of risk that you believe the computer brings to the network. Trusted computers bring little risk whereas untrusted computers can potentially bring great risk. Trust states To understand this concept, consider the four basic states that apply to computers in a typical IT infrastructure. These states are (in order of risk, lowest risk first): 1. Trusted 2. Trustworthy 3. Known, untrusted 4. Unknown, untrusted The remainder of this section defines these states and how to determine which computers in your organization belong in each state. Trusted state Classifying a computer as trusted means that the computer's security risks are managed, but it does not imply that it is perfectly secure or invulnerable. The responsibility for this managed state falls to the IT and security administrators, in addition to the users who are responsible for the configuration of the computer. A trusted computer that is poorly managed will likely become a point of weakness for the network. When a computer is considered trusted, other trusted computers can reasonably assume that the computer will not initiate a malicious act. For example, trusted computers can expect that other trusted computers will not run a virus that attacks them, because all trusted computers are required to use mechanisms (such as antivirus software) to mitigate the threat of viruses. Spend some time defining the goals and technology requirements that your organization considers appropriate as the minimum configuration for a computer to obtain trusted status. A possible list of technology requirements might include the following: Operating system. A trusted client computer should run Windows Vista or Windows XP with SP2. A trusted server should run Windows Server 2008 or Windows Server Domain membership. A trusted computer will belong to a managed Active Directory domain, which means that the IT department has security management rights and can configure member computers by using Group Policy. Management client. All trusted computers must run a specific network management client to allow for centralized management and control of security policies, configurations, and software. Microsoft System Center Configuration Manager is one such management system 54

55 with an appropriate client. For more information, see Antivirus software. All trusted computers will run antivirus software that is configured to check for and automatically update the latest virus signature files daily. Microsoft ForeFront Client Security is one such antivirus software program. For more information, see File system. All trusted computers will be configured to use the NTFS file system. BIOS settings. All trusted portable computers will be configured to use a BIOS-level password that is under the management of the IT support team. Password requirements. Trusted clients must use strong passwords. It is important to understand that the trusted state is not constant; it is a transitive state that is subject to changing security standards and compliance with those standards. New threats and new defenses emerge constantly. For this reason, the organization's management systems must continually check the trusted computers to ensure ongoing compliance. Additionally, the management systems must be able to issue updates or configuration changes if they are required to help maintain the trusted status. A computer that continues to meet all these security requirements can be considered trusted. However it is possible that most computers that were identified in the discovery process discussed earlier do not meet these requirements. Therefore, you must identify which computers can be trusted and which ones cannot. To help with this process, you use the intermediate trustworthy state. The remainder of this section discusses the different states and their implications. Trustworthy state It is useful to identify as soon as possible those computers in your current infrastructure that can achieve a trusted state. A trustworthy state can be assigned to indicate that the current computer can physically achieve the trusted state with required software and configuration changes. For each computer that is assigned a trustworthy status, make an accompanying configuration note that states what is required to enable the computer to achieve trusted status. This information is especially important to both the project design team (to estimate the costs of adding the computer to the solution) and the support staff (to enable them to apply the required configuration). Generally, trustworthy computers fall into one of the following two groups: Configuration required. The current hardware, operating system, and software enable the computer to achieve a trustworthy state. However, additional configuration changes are required. For example, if the organization requires a secure file system before a computer can be considered trusted, a computer that uses a FAT32-formatted hard disk does not meet this requirement. Upgrade required. These computers require upgrades before they can be considered trusted. The following list provides some examples of the type of upgrade these computers might require: 55

56 Operating system upgrade required. If the computer's current operating system cannot support the security needs of the organization, an upgrade would be required before the computer could achieve a trusted state. Software required. A computer that is missing a required security application, such as an antivirus scanner or a management client, cannot be considered trusted until these applications are installed and active. Hardware upgrade required. In some cases, a computer might require a specific hardware upgrade before it can achieve trusted status. This type of computer usually needs an operating system upgrade or additional software that forces the required hardware upgrade. For example, security software might require additional hard disk space on the computer. Computer replacement required. This category is reserved for computers that cannot support the security requirements of the solution because their hardware cannot support the minimum acceptable configuration. For example, a computer that cannot run a secure operating system because it has an old processor (such as a 100-megahertz [MHz] x86- based computer). Use these groups to assign costs for implementing the solution on the computers that require upgrades. Known, untrusted state During the process of categorizing an organization's computers, you will identify some computers that cannot achieve trusted status for specific well-understood and well-defined reasons. These reasons might include the following types: Financial. The funding is not available to upgrade the hardware or software for this computer. Political. The computer must remain in an untrusted state because of a political or business situation that does not enable it to comply with the stated minimum security requirements of the organization. It is highly recommended that you contact the business owner or independent software vendor (ISV) for the computer to discuss the added value of server and domain isolation. Functional. The computer must run a nonsecure operating system or must operate in a nonsecure manner to perform its role. For example, the computer might be required to run an older operating system because a specific line of business application will only work on that operating system. There can be multiple functional reasons for a computer to remain in the known untrusted state. The following list includes several examples of functional reasons that can lead to a classification of this state: Computers that run unsupported versions of Windows. This includes Windows Millennium Edition, Windows 98, Windows 95, or Windows NT. Computers that run these versions of the Windows operating system cannot be classified as trustworthy because these operating systems do not support the required security infrastructure. For example, although 56

57 Windows NT does support a basic security infrastructure, it does not support deny ACLs on local resources, any way to ensure the confidentiality and integrity of network communications, smart cards for strong authentication, or centralized management of computer configurations (although limited central management of user configurations is supported). Stand-alone computers. Computers running any version of Windows that are configured as stand-alone computers or as members of a workgroup usually cannot achieve a trustworthy state. Although these computers fully support the minimum required basic security infrastructure, the required security management capabilities are unlikely to be available when the computer is not a part of a trusted domain. Computers in an untrusted domain. A computer that is a member of a domain that is not trusted by an organization's IT department cannot be classified as trusted. An untrusted domain is a domain that cannot provide the required security capabilities to its members. Although the operating systems of computers that are members of this untrusted domain might fully support the minimum required basic security infrastructure, the required security management capabilities cannot be fully guaranteed when computers are not in a trusted domain. Unknown, untrusted state The unknown, untrusted state should be considered the default state for all computers. Because computers in this state have a configuration that is unknown, you can assign no trust to them. All planning for computers in this state must assume that the computer is an unacceptable risk to the organization. Designers of the solution should strive to minimize the impact that the computers in this state can have on their organizations. Capturing upgrade costs for current computers The final step in this part of the process is to record the approximate cost of upgrading the computers to a point that they can participate in the server and domain isolation design. You must make several key decisions during the design phase of the project that require answers to the following questions: Does the computer meet the minimum hardware requirements necessary for isolation? Does the computer meet the minimum software requirements necessary for isolation? What configuration changes must be made to integrate this computer into the isolation solution? What is the projected cost or impact of making the proposed changes to enable the computer to achieve a trusted state? By answering these questions, you can quickly determine the level of effort and approximate cost of bringing a particular computer or group of computers into the scope of the project. It is important to remember that the state of a computer is transitive, and that by performing the listed remedial actions you can change the state of a computer from untrusted to trusted. After you decide whether to place a computer in a trusted state, you are ready to begin planning and 57

58 designing the isolation groups, which the next section Planning Domain Isolation Zones discusses. The following table is an example of a data sheet that you could use to help capture the current state of a computer and what would be required for the computer to achieve a trusted state. Computer name Hardware reqs met Software reqs met Configuration required Details Projected cost CLIENT001 No No Upgrade hardware and software. SERVER001 Yes No Join trusted domain and upgrade from Windows 2000 to Windows Server Current operating system is Windows Old hardware is not compatible with Windows Vista. No antivirus software present. $?? $?? In the previous table, the computer CLIENT001 is currently "known, untrusted" because its hardware must be upgraded. However, it could be considered trustworthy if the required upgrades are possible. However, if many computers require the same upgrades, the overall cost of the solution would be much higher. The computer SERVER001 is "trustworthy" because it meets the hardware requirements but its operating system must be upgraded. It also requires antivirus software. The projected cost is the amount of effort that is required to upgrade the operating system and install antivirus software, along with their purchase costs. With the other information that you have gathered in this section, this information will be the foundation of the efforts performed later in the Planning Domain Isolation Zones section. The costs identified in this section only capture the projected cost of the computer upgrades. Many additional design, support, test, and training costs should be accounted for in the overall project plan. For more information about how to configure firewalls to support IPsec, see "Configuring Firewalls" at For more information about WMI, see "Windows Management Instrumentation" at Next: Planning Your Windows Firewall with Advanced Security Design 58

59 Planning Your Windows Firewall with Advanced Security Design After you have gathered the relevant information in the previous sections, and understand the basics of the designs as described earlier in this guide, you can select the design (or combination of designs) that meet your needs. Basic firewall design We recommend that you deploy at least the basic firewall design. As discussed in the Protect Computers from Unwanted Network Traffic section, host-based firewalls are an important element in a defense-in-depth strategy and complement most other security measures you put in place in your organization. When you are ready to examine the options for firewall policy settings, see the Planning Settings for a Basic Firewall Policy section. Algorithm and method support and selection To create a domain isolation or server isolation design, you must understand the algorithms available in each version of Windows, as well as their relative strengths. To review the algorithms and methods supported in versions of the Windows operating system, see IPsec Algorithms and Methods Supported in Windows ( IPsec performance considerations Although IPsec is critically important in securing network traffic going to and from your computers, there are costs associated with its use. The mathematically intensive cryptographic algorithms require a significant amount of computing power, which can prevent your computer from making use of all of the available bandwidth. For example, an IPsec-enabled computer using the AES encryption protocols on a 1000 megabits per second (Mbps) network link might see a throughput of only 40 Mbps. This is due to the demands placed on the CPU to perform the cryptographic functions required by the IPsec integrity and encryption algorithms. IPsec task offload is a Windows technology that supports network adapters equipped with dedicated cryptographic processors to perform the computationally intensive work required by IPsec. This frees up a computer s CPU and can dramatically increase network throughput. For more information, see Improving Network Performance by Using IPsec Task Offload ( Domain isolation design Include this design in your plans: If you have an Active Directory domain of which most of the computers are members. If you want to prevent the computers in your organization from accepting any unsolicited network traffic from computers that are not part of the domain. 59

60 If you plan on including the basic firewall design as part of your deployment, we recommend that you deploy the firewall policies first to confirm that they work properly. Also plan to enable your connection security rules in request mode at first, instead of the more restrictive require mode, until you are sure that the computers are all correctly protecting network traffic with IPsec. If something is wrong, request mode still allows communications to continue while you are troubleshooting. When you are ready to examine the options for creating an isolated domain, see the Planning Domain Isolation Zones section. Server isolation design Include this design in your plans: If you have an isolated domain and you want to additionally restrict access to specific servers to only authorized users and computers. You are not deploying an isolated domain, but want to take advantage of similar benefits for a few specific servers. You can restrict access to the isolated servers to only authorized users and computers. If you plan to include domain isolation in your deployment, we recommend that you complete that layer and confirm its correct operation before you implement the additional server isolation elements. When you are ready to examine the options for isolating servers, see the Planning Server Isolation Zones section. Certificate-based authentication design Include this design in your plans: If you want to implement some of the elements of domain or server isolation on computers that are not joined to an Active Directory domain, or do not want to use domain membership as an authentication mechanism. You have an isolated domain and want to effectively a server that is not a member of the Active Directory domain because the computer is not running Windows, or for any other reason. You must enable external computers that are not managed by your organization to access information on one of your servers, and want to do this in a secure way. If you plan to include domain or server isolation in your deployment, we recommend that you complete those elements and confirm their correct operation before you add certificate-based authentication to the computers that require it. When you are ready to examine the options for using certificate-based authentication, see the Planning Certificate-based Authentication section. 60

61 Documenting your design After you finish selecting the designs that you will use, you must assign each of your computers to the appropriate isolation zone and document the assignment for use by the deployment team. Documenting the Zones Designing groups and GPOs After you have selected a design and assigned your computers to zones, you can begin laying out the isolation groups for each zone, the network access groups for isolated server access, and the GPOs that you will use to apply the settings and rules to your computers. When you are ready to examine the options for the groups, filters, and GPOs, see the Planning Group Policy Deployment for Your Isolation Zones section. Next: Planning Settings for a Basic Firewall Policy Planning Settings for a Basic Firewall Policy After you have identified your requirements, and have the information about the network layout and computers available, you can begin to design the GPO settings and rules that will enable you to enforce your requirements on the computers. The following is a list of the firewall settings that you might consider for inclusion in a basic firewall design, together with recommendations to serve as a starting point for your analysis: Profile selection. The firewall rules can be configured for any of the network location profiles that you see in the Network and Sharing Center: domain, public, and private (on Windows Vista and Windows Server 2008), or domain and standard (on Windows XP or Windows Server 2003). Most settings are enforced in the domain profile, without an option for the user to change them. However, you might want to leave the profile settings configurable by the user on computers that can be taken from the organization's physical network and joined to a public or home network. If you lock down the public and private profiles, you might prevent a user from accessing a required network program or service. Because they are not on the organization's network, you cannot fix a connectivity problem by deploying rule changes in a GPO. For each section that follows, consider each profile and apply the rules to those profiles that make sense for your organization. Important By default, a new network adapter installed in a computer is set as a public network connection and, if not configured for a different profile, might automatically switch the computer to public profile. We recommend that on server computers that you set all rules for all profiles to prevent any unexpected profile switch from disrupting network connectivity. You might consider a similar practice for your desktop computers, and only support different profiles on portable computers. Firewall state: On. We recommend that you turn the firewall on, and prevent the user from turning it off. 61

62 Default behavior for Inbound connections: Block. We recommend that you enforce the default behavior of blocking unsolicited inbound connections. To allow network traffic for a specific program, create an inbound rule that serves as an exception to this default behavior. Default behavior for Outbound connections: Allow. We recommend that you enforce the default behavior of allowing outbound connections. Create outbound block rules to prevent the traffic that you know must be blocked. Display a notification: Yes (for client computers), No (for server computers). We recommend that you allow the client computers to display a message to the user when the firewall blocks a program. This enables the user to select whether to allow the program to listen. If the user allows the program, then Windows automatically creates a new inbound rule for the program. The user can do this only if the user's account is a member of the Administrators group, or if the user can supply administrator account credentials to the User Account Control dialog box. If set to No, you must ensure that all programs required by the computer can successfully communicate on the network as needed, either by using the default firewall behavior, or by creating an inbound firewall rule for the program. On servers, we recommend that you turn the notification off, because typically no administrators are waiting to respond if a notification is displayed. In addition, the server roles included with Windows Server 2008 create and enable appropriate rules when you install the role. For example, if you install the Active Directory Domain Controller role, a variety of rules to allow inbound network traffic for Active Directory services are created and enabled for all network location profiles. When this setting is set to No, then the Apply local firewall rules setting is typically set to No also. Allow unicast response: Yes. We recommend that you use the default setting of Yes unless you have specific requirements to do otherwise. Apply local firewall rules: Yes. We recommend that you allow users to create and use local firewall rules. If you set this to No, then when a user clicks Allow on the notification message to allow traffic for a new program, Windows does not create a new firewall rule and the traffic remains blocked. If you and the IT staff can create and maintain the list of firewall rules for all permitted applications and deploy them by using GPOs then you can set this value to No. Apply local connection security rules: No. We recommend that you prevent users from creating and using their own connection security rules. Connection failures caused by conflicting rules can be difficult to troubleshoot. Logging. We recommend that you enable logging to a file on the local hard disk. Be sure to limit the size, such as 4096 KB, to avoid causing performance problems by filling the user's hard disk. Be sure to specify a folder to which the Windows Firewall service account has write permissions. Inbound rules. Create inbound rules for programs that must be able to receive unsolicited inbound network packets from another computer on the network. Make the rules as specific 62

63 as possible to reduce the risk of malicious programs exploiting the rules. For example, specify both program and port numbers. Specifying a program ensures that the rule is only active when the program is actually running, and specifying the port number ensures that the program cannot receive unexpected traffic on a different port. Inbound rules are common on servers, because they host services to which client computers connect. When you install programs and services on a server, the installation program typically creates and enables the rules for you. Examine the rules to ensure that they do not open up more ports than are required. Important If you create inbound rules that permit RPC network traffic by using the RPC Endpoint Mapper and Dynamic RPC rule options, then all inbound RPC network traffic is permitted because the firewall cannot filter network traffic based on the UUID of the destination application. Outbound rules. Only create outbound rules to block network traffic that must be prevented in all cases. If your organization prohibits the use of certain network programs, you can support that policy by blocking the known network traffic used by the program. Be sure to test the restrictions before you deploy them to avoid interfering with traffic for needed and authorized programs. Next: Planning Domain Isolation Zones Planning Domain Isolation Zones After you have the required information about your network, Active Directory, and client and server computers, you can use that information to make decisions about the isolation zones you want to use in your environment. The bulk of the work in planning server and domain isolation is determining which computers to assign to each isolation zone. Correctly choosing the zone for each computer is important to providing the correct level of security without compromising performance or the ability a computer to send or receive required network traffic. The zones described in this guide include the following: Exemption List Isolated Domain Boundary Zone Encryption Zone Exemption List When you implement a server and domain isolation security model in your organization, you are likely to find some additional challenges. Key infrastructure servers such as DNS servers and DHCP servers typically must be available to all computers on the internal network, yet secured from network attacks. However, if they must remain available to all computers on the network, not 63

64 just to isolated domain members, then these servers cannot require IPsec for inbound access, nor can they use IPsec transport mode for outbound traffic. Some services, such as DNS, do not work well with the Fall back to clear setting when one of the computers takes three seconds between a failed IKE attempt and the follow-up plaintext attempt. This delay causes performance and timeout errors for many services. The "Simple Policy Update" for Windows XP with SP2 and Windows Server 2003 with SP1 (available at reduces the delay to one-half second. Later service packs for both Windows XP and Windows Server 2003 have the update built in. For many services, this reduction in the delay means that the services do not require exemption. This keeps the size of the exemption list as small as possible. With Windows Vista and Windows Server 2008, the delay is eliminated. When Fall back to clear is specified, both IPsec and plaintext connection attempts are made at the same time. If the remote computer responds to the IPsec request, then the plaintext attempt is abandoned. If the remote computer does not respond to the IPsec request, then the plaintext attempt is permitted to proceed, and the IPsec request eventually times out. However, if you have any computers in your organization that are running operating systems that cannot run the Simple Policy Update, then you must maintain a comprehensive exemption list. In addition to the infrastructure servers mentioned earlier, there might also be other servers on the network that trusted computers cannot use IPsec to access, which would be added to the exemption list. Generally, the following conditions are reasons to consider adding a computer to the exemption list: If the computer must be accessed by trusted computers but it does not have a compatible IPsec implementation. If the computer must provide services to both trusted and untrusted computers, but does not meet the criteria for membership in the boundary zone. If the computer must run a program that is adversely affected by IPsec encapsulation of program traffic. If the computer must support so many clients at the same time and you find that IPsec causes an unacceptable drop in performance. If the computer must be accessed by trusted computers from different isolated domains that do not have an Active Directory trust relationship established with each other. If the computer is a domain controller running version of Windows earlier than Windows Server 2008, or if any of its clients are running a version of Windows earlier than Windows Vista. If the computer must support trusted and untrusted computers, but cannot use IPsec to help secure communications to trusted computers. For large organizations, the list of exemptions might grow very large if all the exemptions are implemented by one connection security rule for the whole domain or for all trusted forests. If you can require all computers in your isolated domain to run at least Windows XP with SP2 or Windows Server 2003 with SP1 with the Simple Policy Update, you can greatly reduce the size of 64

65 this list. A large exemption list has several unwanted effects on every computer that receives the GPO, including the following: Reduces the overall effectiveness of isolation. Creates a larger management burden (because of frequent updates). Increases the size of the IPsec policy, which means that it consumes more memory and CPU resources, slows down network throughput, and increases the time required to download and apply the GPO containing the IPsec policy. To keep the number of exemptions as small as possible, you have several options: Carefully consider the communications requirements of each isolation zone, especially server-only zones. They might not be required to communicate with every exemption in the domain-level policy for clients. Consolidate server functions. If several exempt services can be hosted at one IP address, the number of exemptions is reduced. Consolidate exempted hosts on the same subnet. Where network traffic volume allows, you might be able to locate the servers on a subnet that is exempted, instead of using exemptions for each IP address. As with defining the boundary zone, create a formal process to approve hosts being added to the exemption list. For a model of processing requests for exemptions, see the decision flowchart in the Boundary Zone section. Next: Isolated Domain Isolated Domain The isolated domain is the primary zone for trusted computers. The computers in this zone use connection security and firewall rules to control the communications that can be sent between computers in the zone. The term domain in this context means a boundary of communications trust instead of an Active Directory domain. In this solution the two constructs are very similar because Active Directory domain authentication (Kerberos V5) is required for accepting inbound connections from trusted computers. However, many Active Directory domains (or forests) can be linked with trust relationships to provide a single, logical, isolated domain. In addition, computers that authenticate by using certificates can also be included in an isolated domain without joining the Active Directory domain. For most implementations, an isolated domain will contain the largest number of computers. Other isolation zones can be created for the solution if their communication requirements differ from those of the isolated domain. Examples of these differences are what result in the boundary and encryption zones described in this guide. Conceptually, the isolated domain is just the largest isolation zone, and a superset to the other zones. You must create a group in Active Directory to contain members of the isolated domain. You then apply one of several GPOs that contain connection security and firewall rules to the group so that authentication on all inbound network connections is enforced. Creation of the group and how to 65

66 link the GPOs that apply the rules to its members are discussed in the Planning Group Policy Deployment for Your Isolation Zones section. The GPOs for the isolated domain should contain the following connection security rules and settings. GPO settings for isolated domain members running Windows Vista or Windows Server 2008 GPOs for computers running Windows Vista or Windows Server 2008 should include the following: IPsec default settings that specify the following options: a. Exempt all ICMP traffic from IPsec. b. Key exchange (main mode) security methods and algorithm. We recommend that you do not include Diffie-Hellman Group 1, Data Encryption Standard (DES), or MD5 in any setting. They are included only for compatibility with earlier versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. c. Data protection (quick mode) algorithm combinations. We recommend that you do not include DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. If isolated domain members must communicate with hosts in the encryption zone, ensure that you include algorithms that are compatible with the requirements of the encryption mode policies. d. Authentication methods. Include at least computer-based Kerberos V5 authentication. If you want to use user-based access to isolated servers, then also include user-based Kerberos V5 as an optional authentication method. Likewise, if any of your isolated domain members cannot use Kerberos V5 authentication, then include certificate-based authentication as an optional authentication method. The following connection security rules: A connection security rule that exempts all computers on the exemption list from authentication. Be sure to include all your Active Directory domain controllers on this list. Enter subnet addresses, where possible, instead of discrete addresses, if applicable in your environment. A connection security rule, from any IP address to any, that requires inbound and requests outbound authentication by using Kerberos V5 authentication. Important Be sure to begin operations by using request in and request out behavior until you are sure that all the computers in your IPsec environment are communicating successfully by using IPsec. After confirming that IPsec is operating as expected, you can change the policy to require in, request out. 66

67 A registry policy that includes the following values: a. Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets the value to 1. b. Enforce the default IPsec protocol exemptions of ISAKMP only. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 3. c. If required by the organization, enable IPsec over NAT-T. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 0 (the default). To enable IPsec over NAT- T, you must change this value to either 1 or 2, as required by your environment. Note For a sample template for these registry settings, see Appendix A: Sample GPO Template Files for Settings Used in this Guide. GPO settings for isolated domain members running Windows 2000, Windows Server 2003, or Windows XP GPOs for computers running Windows 2000, Windows Server 2003, or Windows XP should include the following: An IPsec Policy that includes the following settings and security rules: a. Key exchange settings that specify main mode security methods and algorithms. We recommend that you do not include Diffie-Hellman Group 1, DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. You should use the strongest algorithm combinations that are common to all your supported operating systems. b. A permit rule for all ICMP traffic using My IP Address to Any IP Address. c. A permit rule for all computers on the exemption list. Be sure to include all your Active Directory domain controllers on this list. Take advantage of the ability to enter subnet addresses, fvif applicable in your environment. d. A negotiate rule for all network addresses using My IP Address to communicate with subnet addresses that make up the network address space. The filter action should specify Negotiate security, and then specify the same integrity and encryption protocols that are used by your other computers. We recommend that you do not include DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your 67

68 supported operating systems. If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. To initially make the IPsec policy request authentication for both inbound and outbound traffic, select both Accept unsecured communication and Allow fallback to unsecured communication check boxes. After you have confirmed that all your computers are successfully using IPsec as designed, come back to this setting, and then clear the Accept unsecured communication check box to require inbound authentication. A registry policy that includes the following values: a. Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets the value to 1. b. Enforce the default IPsec protocol exemptions. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 3 on Windows Server 2003, and sets the value to 1 on Windows XP and Windows c. If required by the organization, enable IPsec over NAT-T. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 0 (the default). To enable IPsec over NAT- T, you must change this value to either 1 or 2, as required by your environment. d. Set the Simplified IPsec Policy registry entry to a value of 0x14 to improve the 'fall back to clear' behavior in Windows XP and Windows Server To use this, you must have already deployed the update available for free download (for Windows Server 2003) from the Knowledge Base article at Note For a sample template for these registry settings, see Appendix A: Sample GPO Template Files for Settings Used in this Guide. Make sure that in your GPOs for stationary computers, such as desktop and server computers, assign all rules to all profiles. For portable computers, you might want to allow more profile flexibility to enable users to communicate successfully when they are not connected to the organization's network. Next: Boundary Zone 68

69 Boundary Zone In most organizations, some computers must be able to receive network traffic from computers that are not part of the isolated domain, and therefore cannot authenticate. To accept communications from untrusted computers, create a boundary zone within your isolated domain. Computers in the boundary zone are trusted computers that can accept communication requests both from other isolated domain member computers and from untrusted computers. Boundary zone computers try to authenticate any incoming request by using IPsec, initiating an IKE negotiation with the originating computer. However, if no IKE response is received, the computer will "fall back to clear" and begin communicating in plaintext without IPsec. The GPOs you build for the boundary zone include IPsec or connection security rules that request authentication for both inbound and outbound network connections, but do not require it. Because these boundary zone computers can receive unsolicited inbound communications from untrusted computers that use plaintext, they must be carefully managed and secured in other ways. Mitigating this additional risk is an important part of deciding whether to add a computer to the boundary zone. For example, completing a formal business justification process before adding each computer to the boundary zone can help ensure that the additional risk is minimized. The following illustration shows a sample process that can help make such a decision. 69

70 The goal of this process is to determine whether the risk of adding a computer to a boundary zone can be mitigated to a level that makes it acceptable to the organization. Ultimately, if the risk cannot be mitigated, membership must be denied. 70

71 You must create a group in Active Directory to contain the members of the boundary zones. The settings and rules for the boundary zone are typically very similar to those for the isolated domain, and you can save time and effort by copying those GPOs to serve as a starting point. The primary difference is that the authentication connection security rule must be set to request authentication for both inbound and outbound traffic, instead of requiring inbound authentication and requesting outbound authentication as used by the isolated domain. Creation of the group and how to link it to the GPOs that apply the rules to members of the group are discussed in the Planning Group Policy Deployment for Your Isolation Zones section. GPO settings for boundary zone servers running Windows Server 2008 The boundary zone GPO for computers running Windows Server 2008 should include the following: IPsec default settings that specify the following options: a. Exempt all ICMP traffic from IPsec. b. Key exchange (main mode) security methods and algorithm. We recommend that you do not include Diffie-Hellman Group 1, DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. c. Data protection (quick mode) algorithm combinations. We recommend that you do not include DES or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. If these computers must communicate with hosts in the encryption zone, ensure that you include an algorithm that is compatible with the requirements of the encryption zone GPOs. d. Authentication methods. Include at least computer-based Kerberos V5 authentication. If you want to use user-based access to isolated servers then you must also include userbased Kerberos V5 authentication as an optional authentication method. Likewise, if any of your domain isolation members cannot use Kerberos V5, you must include certificatebased authentication as an optional authentication method. The following connection security rules: A connection security rule that exempts all computers on the exemption list from authentication. Be sure to include all your Active Directory domain controllers on this list. Enter subnet addresses, if applicable in your environment. A connection security rule, from Any IP address to Any IP address, that requests inbound and outbound authentication. Important Be sure to begin operations by using request in and request out behavior until you are sure that all the computers in your IPsec environment are communicating successfully by using IPsec. After confirming that IPsec is operating as expected, you can change the policy to require in, request out. 71

72 A registry policy that includes the following values: a. Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets the value to 1. b. Enforce the default IPsec protocol exemptions of ISAKMP only. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 3. c. If required by the organization, enable IPsec over NAT-T. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 0 (the default). To enable IPsec over NAT- T, you must change this value to either 1 or 2, as required by your environment. Note For a sample template for these registry settings, see Appendix A: Sample GPO Template Files for Settings Used in this Guide. GPO settings for boundary zone servers running Windows 2000 or Windows Server 2003 You must create a new IPsec policy instead of modifying an existing IPsec policy in a copied GPO. Because all GPOs share a common store of IPsec policies, if you modify an IPsec policy in a copied GPO, you are modifying the shared one used by other GPOs. Make sure that your newly created IPsec policy is the one assigned in the GPO. The GPOs for computers that are running Windows 2000 or Windows Server 2003 should include the following: An IPsec policy that includes the following settings and security rules: a. Key exchange settings that specify main mode security methods and algorithms. We recommend that you do not include Diffie-Hellman Group 1, DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. b. A permit rule for all ICMP traffic using My IP Address to Any IP Address. c. A permit rule for all computers on the exempted list. Be sure to include all your Active Directory domain controllers on this list. Take advantage of the ability to enter subnet addresses, if applicable in your environment. d. A negotiate rule for all network addresses using My IP Address to communicate with subnet addresses that make up the network address space. The filter action should specify Negotiate security, and then specify the same integrity and encryption protocols that are used by your other computers. We recommend that you do not include DES or 72

73 MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. To make the policy request authentication for inbound and outbound traffic, select both of the Accept unsecured communication and Allow fallback to unsecured communication check boxes. Make sure that your GPOs for stationary computers, such as desktop and server computers, assign all rules to all profiles. For portable computers, you might want to allow more profile flexibility to enable users to communicate successfully when they are not connected to the organization's network. Next: Encryption Zone Encryption Zone Some servers in the organization host data that is very sensitive, including medical, financial, or other personally identifying data. Government or industry regulations might require that this sensitive information must be encrypted when it is transferred between computers. To support the additional security requirements of these servers, we recommend that you create an encryption zone to contain the computers and that requires that the sensitive inbound and outbound network traffic be encrypted. You must create a group in Active Directory to contain members of the encryption zone. The settings and rules for the encryption zone are typically similar to those for the isolated domain, and you can save time and effort by copying those GPOs to serve as a starting point. You then modify the security methods list to include only algorithm combinations that include encryption protocols. Creation of the group and how to link it to the GPOs that apply the rules to members of the group are discussed in the Planning Group Policy Deployment for Your Isolation Zones section. GPO settings for encryption zone servers running Windows Server 2008 The GPO for computers that are running Windows Server 2008 should include the following: IPsec default settings that specify the following options: a. Exempt all ICMP traffic from IPsec. b. Key exchange (main mode) security methods and algorithm. We recommend that you do not include Diffie-Hellman Group 1, DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. c. Data protection (quick mode) algorithm combinations. Check Require encryption for all connection security rules that use these settings, and then specify one or more integrity and encryption combinations. We recommend that you do not include DES or MD5 in any setting. They are included only for compatibility with previous versions of 73

74 Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. d. Authentication methods. Include at least computer-based Kerberos V5 authentication. If you want to use user-based access to isolated servers then you must also include userbased Kerberos V5 authentication as an optional authentication method. Likewise, if any of your domain isolation members cannot use Kerberos V5 authentication, then you must include certificate-based authentication as an optional authentication method. The following connection security rules: A connection security rule that exempts all computers on the exemption list from authentication. Be sure to include all your Active Directory domain controllers on this list. Enter subnet addresses, if applicable in your environment. A connection security rule, from any IP address to any, that requires inbound and requests outbound authentication using the default authentication specified earlier in this policy. Important Be sure to begin operations by using request in and request out behavior until you are sure that all the computers in your IPsec environment are communicating successfully by using IPsec. After confirming that IPsec is operating as expected, you can change the GPO to require in, request out. A registry policy that includes the following values: a. Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets the value to 1. b. Enforce the default IPsec protocol exemptions of ISAKMP only. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 3. c. If required by the organization, enable IPsec over NAT-T. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 0 (the default). To enable IPsec over NAT- T, you must change this value to either 1 or 2, as required by your environment. Note For a sample template for these registry settings, see Appendix A: Sample GPO Template Files for Settings Used in this Guide. 74

75 If domain member computers must communicate with computers in the encryption zone, ensure that you include in the isolated domain GPOs quick mode combinations that are compatible with the requirements of the encryption zone GPOs. GPO settings for encryption zone servers running Windows 2000 or Windows Server 2003 You must create a new IPsec policy instead of modifying an existing IPsec policy in a copied GPO. Because all GPOs share a common store of IPsec policies, if you modify an IPsec policy in a copied GPO, you are modifying the shared one used by other GPOs. Make sure that your newly created IPsec policy is the one assigned in the GPO. The GPOs for computers that are running Windows 2000 or Windows Server 2003 should include the following: An IPsec policy that includes the following settings and security rules: a. Key exchange settings that specify main mode security methods and algorithms. We recommend that you do not include Diffie-Hellman Group 1, DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. b. A permit rule for all ICMP traffic using My IP Address to Any IP Address. c. A permit rule for all computers on the exempted list. Be sure to include all your Active Directory domain controllers on this list. Take advantage of the ability to enter subnet addresses, if applicable in your environment. d. A negotiate rule for all network addresses using My IP Address to communicate with subnet addresses that make up the network address space. The filter action should specify Negotiate security and then specify the encryption protocols to be required by members of the zone. We recommend that you do not include DES or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. To initially make the GPO request inbound and outbound authentication, select both the Accept unsecured communication and Allow fallback to unsecured communication check boxes. After you have confirmed that all your computers are successfully using IPsec as designed, come back to this setting, and then clear the Accept unsecured communication check box to require inbound authentication. A registry policy that includes the following values: a. Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets the value to 1. 75

76 b. Enforce the default IPsec protocol exemptions. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 3 on Windows Server 2003, and sets the value to 1 on Windows XP and Windows c. If required by the organization, enable IPsec over NAT-T. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 0 (the default). To enable IPsec over NAT- T, you must change this value to either 1 or 2, as required by your environment. d. Set the Simplified IPsec Policy registry entry to a value of 0x14 to improve the 'fall back to clear' behavior in Windows XP and Windows Server To use this, you must have already deployed the update available for free download (for Windows Server 2003) from the Knowledge Base article at Note For a sample template for these registry settings, see Appendix A: Sample GPO Template Files for Settings Used in this Guide. Make sure that your GPOs for stationary computers, such as desktop and server computers, assign all rules to all profiles. For portable computers, you might want to allow more profile flexibility to enable users to communicate successfully when they are not connected to the organization's network. Next: Planning Server Isolation Zones Planning Server Isolation Zones Sometimes a server hosts data that is sensitive. If your servers host data that must not be compromised, you have several options to help protect that data. One was already addressed: adding the server to the encryption zone. Membership in that zone prevents the server from being accessed by any computers that are outside the isolated domain, and encrypts all network connections to server. The second option is to additionally restrict access to the server, not just to members of the isolated domain, but to only those users or computers who have business reasons to access the resources on the server. You can specify only approved users, or you can additionally specify that the approved users can only access the server from approved computers. To grant access, you add the approved user and computer accounts to network access groups (NAGs) that are referenced in a firewall rule on this server. When the user sends a request to the server, the standard domain isolation rules are invoked. This causes IKE to use Kerberos V5 to exchange credentials with the server. The additional firewall rule on the server causes Windows to check the provided computer and user accounts for group membership in the NAGs. If either the user or computer is not a member of a required NAG then the network connection is refused. 76

77 Isolated domains and isolated servers If you are using an isolated domain, the client computers already have the IPsec rules to enable them to authenticate traffic when the server requires it. If you add an isolated server, it must have a GPO applied to its group with the appropriate connection security and firewall rules. The rules enforce authentication and restrict access to only connections that are authenticated as coming from an authorized computer or user. If you are not using an isolated domain, but still want to isolate a server that uses IPsec, you must configure the client computers that you want to access the server to use the appropriate IPsec rules. If the client computers are members of an Active Directory domain, you can still use Group Policy to configure the clients. Instead of applying the GPO to the whole domain, you apply the GPO to only members of the NAG. Creating multiple isolated server zones Each set of servers that must be accessed by different sets of users should be set up in its own isolated server zone. After one set of GPOs for one isolated server zone has been successfully created and verified, you can copy the GPOs to a new set. You must change the GPO names to reflect the new zone, the name and membership of the isolated server zone group to which the GPOs are applied, and the names and membership of the NAG groups that determine which clients can access the servers in the isolated server zone. Creating the GPOs Creation of the groups and how to link them to the GPOs that apply the rules to members of the groups are discussed in the Planning Group Policy Deployment for Your Isolation Zones section. An isolated server is often a member of the encryption zone. Therefore, copying that GPO set serves as a good starting point. You then modify the rules to additionally restrict access to only NAG members. GPO settings for isolated servers running Windows Server 2008 GPOs for computers running Windows Server 2008 should include the following: Note The connection security rules described here are identical to the ones for the encryption zone. If you do not want to encrypt access and also restrict access to NAG members, you can use connection security rules identical to the main isolated domain. You must still add the firewall rule described at the end of this list to change it into an isolated server zone. IPsec default settings that specify the following options: a. Exempt all ICMP traffic from IPsec. b. Key exchange (main mode) security methods and algorithm. We recommend that you do not include Diffie-Hellman Group 1, DES, or MD5 in any setting. They are included only 77

78 for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. c. Data protection (quick mode) algorithm combinations. Check Require encryption for all connection security rules that use these settings, and then specify one or more integrity and encryption combinations. We recommend that you do not include DES or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. If isolated servers must communicate with hosts in the encryption zone, include an algorithm that is compatible with the requirements of the encryption zone GPOs. d. Authentication methods. Include at least computer-based Kerberos V5 authentication for compatibility with the rest of the isolated domain. If you want to restrict access to specific user accounts, also include user-based Kerberos V5 authentication as an optional authentication method. Do not make the user-based authentication method mandatory, or else computers that cannot use AuthIP instead of IKE, including Windows XP and Windows Server 2003, cannot communicate. Likewise, if any of your domain isolation members cannot use Kerberos V5, include certificate-based authentication as an optional authentication method. The following connection security and firewall rules: A connection security rule that exempts all computers on the exemption list from authentication. Be sure to include all your Active Directory domain controllers on this list. Enter subnet addresses, if applicable in your environment. A connection security rule, from Any IP address to Any IP address, that requires inbound and requests outbound authentication by using Kerberos V5 authentication. Important Be sure to begin operations by using request in and request out behavior until you are sure that all the computers in your IPsec environment are communicating successfully by using IPsec. After confirming that IPsec is operating as expected, you can change the GPO to require in, request out. A firewall rule that specifies Allow only secure connections, Require encryption, and on the Users and Computers tab includes references to both computer and user network access groups. A registry policy that includes the following values: a. Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets the value to 1. 78

79 b. Enforce the default IPsec protocol exemptions of ISAKMP only. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 3. c. If required by the organization, enable IPsec over NAT-T. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 0 (the default). To enable IPsec over NAT- T, you must change this value to either 1 or 2, as required by your environment. Note For a sample template for these registry settings, see Appendix A: Sample GPO Template Files for Settings Used in this Guide. GPO settings for isolated servers running Windows 2000 or Windows Server 2003 You must create a new IPsec policy instead of modifying an existing IPsec policy in a copied GPO. Because all GPOs share a common store of IPsec policies, if you modify an IPsec policy in a copied GPO, you are modifying the shared one used by other GPOs. Make sure that your newly created IPsec policy is the one assigned in the GPO. The GPOs for computers that are running Windows 2000 or Windows Server 2003 should include the following: Note This IPsec policy is identical to the one for the encryption zone setting, except for the addition of the User Rights Assignment setting. If you do not want to encrypt access and also restrict access to NAG members, you can use an IPsec policy identical to the main isolated domain. An IPsec policy that includes the following settings and security rules: a. Key exchange settings that specify main mode security methods and algorithms. We recommend that you do not include Diffie-Hellman Group 1, DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. b. A permit rule for all ICMP traffic using My IP Address to Any IP Address. c. A permit rule for all computers on the exempted list. Be sure to include all your Active Directory domain controllers on this list. Take advantage of the ability to enter subnet addresses, if applicable in your environment. d. A negotiate rule for all network addresses using My IP Address to subnet addresses that make up the network address space. The filter action should specify Negotiate security, and then specify the encryption protocols to be required by members of the zone. We recommend that you do not include DES or MD5 in any setting. They are included only 79

80 for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. To initially make the GPO request authentication for inbound and outbound traffic, select both the Accept unsecured communication and Allow fallback to unsecured communication check boxes. After you have confirmed that all your computers are successfully using IPsec as designed, come back to this setting, and then clear the Accept unsecured communication check box to require inbound authentication. A User Rights Assignment setting that sets the Access this computer from the network user right to only include the computer NAG, the user NAG, and the IPsec exempt computers. Ensure that users who must administer the server, and the computers from which they work are members of the NAG groups. Also under User Rights Assignment, you can consider adding groups for users or computers that must be prevented from accessing the servers in the isolation zone. They are added to the Deny access to this computer from the network user right. This might include the CG_DOMISO_Boundary group, because they are computers at a greater risk of being compromised and therefore pose a higher risk to your isolated servers. A registry policy that includes the following values: a. Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets the value to 1. b. Enforce the default IPsec protocol exemptions. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 3 on Windows Server 2003, and sets the value to 1 on Windows XP and Windows c. If required by the organization, enable IPsec over NAT-T. This setting is documented in Knowledge Base article at The sample GPO preferences XML file in Appendix A: Sample GPO Template Files for Settings Used in this Guide sets this value to 0 (the default). To enable IPsec over NAT- T, you must change this value to either 1 or 2, as required by your environment. d. Set the Simplified IPsec Policy registry entry to a value of 0x14 to improve the 'fall back to clear' behavior in Windows XP and Windows Server To use this, you must have already deployed the update available for free download (for Windows Server 2003) from the Knowledge Base article at Note For a sample template for these registry settings, see Appendix A: Sample GPO Template Files for Settings Used in this Guide. 80

81 Make sure that your GPOs for stationary computers, such as desktop and server computers, assign all rules to all profiles. For portable computers, you might want to allow more profiles to enable users to communicate successfully when they are not connected to the organization's network. Next: Planning Certificate-based Authentication Planning Certificate-based Authentication Sometimes a computer cannot join an Active Directory domain, and therefore cannot use Kerberos V5 authentication with domain credentials. However, the computer can still participate in the isolated domain by using certificate-based authentication. The non-domain member server, and the clients that must be able to communicate with it, must be configured to use cryptographic certificates based on the X.509 standard. These certificates can be used as an alternate set of credentials. During IKE negotiation, each computer sends a copy of its certificate to the other computer. Each computer examines the received certificate, and then validates its authenticity. To be considered authentic, the received certificate must be validated by a certification authority certificate in the recipient's Trusted Root Certification Authorities store on the local computer. Certificates can be acquired from commercial firms, or by an internal certificate server set up as part of the organization's public key infrastructure (PKI). Microsoft provides a complete PKI and certification authority solution with Windows Server 2008, Active Directory Certificate Services (AD CS). For more information about creating and maintaining a PKI in your organization, see Active Directory Certificate Services at Deploying certificates No matter how you acquire your certificates, you must deploy them to clients and servers that require them in order to communicate. Using Active Directory Certificate Services If you use AD CS to create your own user and computer certificates in-house, then the servers designated as certification authorities (CAs) create the certificates based on administratordesigned templates. AD CS then uses Group Policy to deploy the certificates to domain member computers. Computer certificates are deployed when a domain member computer starts. User certificates are deployed when a user logs on. If you want non-domain member computers to be part of a server isolation zone that requires access by only authorized users, make sure to include certificate mapping to associate the certificates with specific user accounts. When certificate mapping is enabled, the certificate issued to each computer or user includes enough identification information to enable IPsec to match the certificate to both user and computer accounts. AD CS automatically ensures that certificates issued by the CAs are trusted by the client computers by putting the CA certificates in the correct store on each domain member computer. 81

82 Using a commercially purchased certificate for computers running Windows You can import the certificates manually onto each computer if the number of computers is relatively small. For a deployment to more than a handful of computers, use Group Policy. You must first download the vendor's root CA certificate, and then import it to a GPO that deploys it to the Local Computer\Trusted Root Certification Authorities store on each computer that applies the GPO. You must also import the purchased certificate into a GPO that deploys it to the Local Computer\Personal store on each computer that applies the GPO. Using a commercially purchased certificate for computers running a non-windows operating system If you are installing the certificates on an operating system other than Windows, see the documentation for that operating system. Configuring IPsec to use the certificates When the clients and servers have the certificates available, you can configure the IPsec and connection security rules to include those certificates as a valid authentication method. The authentication method requires the subject name of the certificate, for example: DC=com,DC=woodgrovebank,CN=CorporateCertServer. Optionally, select Enable certificate to account mapping to support using these credentials for restricting access to users or computers that are members of authorized groups in a server isolation solution. Next: Documenting the Zones Documenting the Zones Generally, the task of determining zone membership is not complex, but it can be timeconsuming. Use the information generated during the Designing a Windows Firewall with Advanced Security Strategy section of this guide to determine the zone in which to put each host. You can document this zone placement by adding a Group column to the inventory table shown in the Designing a Windows Firewall with Advanced Security Strategy section. A sample is shown here: Host name Hardware reqs met Software reqs met Configuration required Details Projected cost Group CLIENT001 No No Upgrade hardware and software. Current operating system is Windows NT 4.0. Old hardware not compatible with Windows XP or Windows Vista. $?? Isolated domain 82

83 Host name Hardware reqs met Software reqs met Configuration required Details Projected cost Group SERVER002 Yes No Join trusted domain, upgrade from Windows NT 4.0 to Windows Server 2008 No antivirus software present. $?? Encryption SENSITIVE001 Yes Yes Not required. Running Windows Server Ready for inclusion. PRINTSVR1 Yes Yes Not required. Running Windows Server Ready for inclusion. $0 Isolated server (in zone by itself) $0 Boundary Next: Planning Group Policy Deployment for Your Isolation Zones Planning Group Policy Deployment for Your Isolation Zones After you have decided on the best logical design of your isolation environment for the network and computer security requirements, you can start the implementation plan. You have a list of isolation zones with the security requirements of each. For implementation, you must plan the groups that will hold the computer accounts in each zone, the network access groups that will be used to determine who can access an isolated server, and the GPOs with the connection security and firewall rules to apply to corresponding groups. Finally you must determine how you will ensure that the policies will only apply to the correct computers within each group. Planning Isolation Groups for the Zones Planning Network Access Groups Planning the GPOs Planning GPO Deployment 83

84 Planning Isolation Groups for the Zones Isolation groups in Active Directory are how you implement the various domain and server isolation zones. A computer is assigned to a zone by adding its computer account to the group which represents that zone. Caution Do not add computers to your groups yet. If a computer is in a group when the GPO is activated then that GPO is applied to the computer. If the GPO is one that requires authentication, and the other computers have not yet received their GPOs, the computer that uses the new GPO might not be able to communicate with the others. Universal groups are the best option to use for GPO assignment because they apply to the whole forest and reduce the number of groups that must be managed. However, if universal groups are unavailable, you can use domain global groups instead. The following table lists typical groups that can be used to manage the domain isolation zones discussed in the Woodgrove Bank example in this guide: Group name CG_DOMISO_No_IPsec CG_DOMISO_IsolatedDomain CG_DOMISO_Boundary Description A universal group of computer accounts that do not participate in the IPsec environment. Typically consists of infrastructure computer accounts that will also be included in exemption lists. This group is used in security group filters to ensure that GPOs with IPsec rules are not applied to group members. A universal group of computer accounts that contains the members of the isolated domain. During the early days of testing, this group might contain only a very small number of computers. During production, it might contain the built-in Domain Computers group to ensure that every computer in the domain participates. Members of this group receive the domain isolation GPO that requires authentication for inbound connections. A universal group of computer accounts that contains the members of the boundary zone. Members of this group receive a GPO that specifies that authentication is requested, but 84

85 Group name CG_DOMISO_Encryption CG_SRVISO_ServerRole CG_DOMISO_WINDOWS2000 Description not required. A universal group of computer accounts that contains the members of the encryption zone. Members of this group receive a GPO that specifies that both authentication and encryption are required for all inbound connections. A universal group of computer accounts that contains the members of the server isolation group. Members of this group receive the server isolation GPO that requires membership in a network access group in order to connect. There will be one group for each set of servers that have different user and computer restriction requirements. A universal group of computer accounts for all computers in the organization that are running Windows Because computers that are running Windows 2000 cannot process WMI filters, you must use security group filtering to prevent these computers from applying GPOs for other versions of Windows. Multiple GPOs might be delivered to each group. Which one actually becomes applied depends on the security group filters assigned to the GPOs in addition to the results of any WMI filtering assigned to the GPOs. Details of the GPO layout are discussed in the section Planning the GPOs. If multiple GPOs are assigned to a group, and similar rules are applied, the rule that most specifically matches the network traffic is the one that is used by the computer. For example, if one IPsec rule says to request authentication for all IP traffic, and a second rule from a different GPO says to require authentication for IP traffic to and from a specific IP address, then the second rule takes precedence because it is more specific. Next: Planning Network Access Groups Planning Network Access Groups A network access group (NAG) is used to identify users and computers that have permission to access an isolated server. The server is configured with firewall rules that allow only network 85

86 connections that are authenticated as originating from a computer, and optionally a user, whose accounts are members of its NAG. A member of the isolated domain can belong to as many NAGs as required. Minimize the number of NAGs to limit the complexity of the solution. You need one NAG for each server isolation group to restrict the computers or users that are granted access. You can optionally split the NAG into two different groups: one for authorized computers and one for authorized users. The NAGs that you create and populate become active by referencing them in the Users and Computers tab of the firewall rules in the GPO assigned to the isolated servers. The GPO must also contain connection security rules that require authentication to supply the credentials checked for NAG membership. For the Woodgrove Bank scenario, access to the computers running SQL Server that support the WGBank application are restricted to the WGBank front-end servers and to approved administrative users logged on to specific authorized administrative computers. They are also only accessed by the approved admin users and the service account that is used to the run the WGBank front end service. NAG Name CG_NAG_ServerRole_Users CG_NAG_ServerRole_Computers NAG Member Users, Computers, or Groups Svr1AdminA Svr1AdminB Group_AppUsers AppSvcAccount Desktop1 Desktop2 AdminDT1 AppAdminDT1 Description This group is for all users who are authorized to make inbound IPsec connections to the isolated servers in this zone. This group contains all computers that are authorized to make inbound IPsec connections to the isolated servers in this zone. Note Membership in a NAG does not control the level of IPsec traffic protection. The IKE negotiation is only aware of whether the computer or user passed or failed the Kerberos V5 authentication process. The connection security rules in the applied GPO control the security methods that are used for protecting traffic and are independent of the identity being authenticated by Kerberos V5. Next: Planning the GPOs 86

87 Planning the GPOs When you plan the GPOs for your different isolation zones, you must complete the layout of the required zones and their mappings to the groups that link the computers to the zones. General considerations A few things to consider as you plan the GPOs: Do not allow a computer to be a member of more than one isolation zone. A computer in more than one zone receives multiple and possibly contradictory GPOs. This can result in unexpected, and difficult to troubleshoot behavior. The examples in this guide show GPOs that are designed to prevent the requirement to belong to multiple zones. You must know the mix of computers that will be part of any specific zone. If the zone contains computers running Windows 2000, Windows XP and Windows Server 2003 as well as computers running Windows Vista and Windows Server 2008 then you must design multiple GPOs, one for each set of operating systems, with the appropriate IPsec policies, and including WMI filters to apply each GPO to the correct computers. The Planning GPO Deployment section discusses how to ensure that each operating system version receives the correct GPO. Ensure that the IPsec algorithms you specify in your GPOs are compatible across all the versions of Windows. For example, if you have any computers running Windows 2000, then you must ensure that all computers include the main mode Diffie-Hellman Group 2 key exchange algorithm, because Windows 2000 cannot use more the advanced Diffie-Hellman groups. The same principle applies to the data integrity and encryption algorithms. We recommend that you include the more advanced algorithms when you have the option of selecting several in an ordered list. The computers will negotiate down from the top of their lists, selecting one that is configured on both computers. So a computer that is running Windows Vista that is connected to a server that is running Windows Server 2008 can communicate by using a much more secure algorithm, while computers running Windows 2000 or Windows XP connect to the same server by using a less secure, but compatible algorithm. The primary difference in your domain isolation GPOs is whether the rules request or require authentication. Caution It is critical that you begin with all your GPOs set to request authentication instead of requiring it. Since the GPOs are delivered to the computers over time, applying a require policy to one computer breaks its ability to communicate with another computer that has not yet received its policy. Using request mode at the beginning enables computers to continue communicating by using plaintext connections if required. After you confirm that your computers are using IPsec where expected, you can schedule a conversion of the rules in the GPOs from requesting to requiring authentication, as required by each zone. 87

88 Windows Firewall with Advanced Security in Windows Vista and Windows Server 2008 only support one network location profile at a time. If you add a second network adapter that is connected to a different network, or not connected at all, you could unintentionally change the profile that is currently active on the computer. If your GPO specifies different firewall and connection security rules based on the current network location profile, the behavior of how the computer handles network traffic will change accordingly. We recommend for stationary computers, such as desktops and servers, that you assign any rule for the computer to all profiles. Apply GPOs that change rules per network location to computers that must move between networks, such as your portable computers. Consider creating a separate domain isolation GPO for your servers that uses the same settings as the GPO for the clients, except that the server GPO specifies the same rules for all network location profiles. For more information, see Network Location Types at Windows Server 2003 and Windows XP support only two network location profiles: domain and standard. The standard profile supported in those earlier versions of Windows is now split between the public and private profiles supported in Windows Vista and Windows Server If you apply a GPO with IPsec rules configured for the earlier versions of Windows to a computer that is running Windows Vista and Windows Server 2008, the rules for the standard profile are applied to only the private profile. After considering these issues, document each GPO that you require, and the details about the connection security and firewall rules that it needs. Woodgrove Bank example GPOs The Woodgrove Bank example uses the following set of GPOs to support its domain isolation requirements. This section only discusses the rules and settings for server and domain isolation. GPO settings that affect which computers receive the GPO, such as security group filtering and WMI filtering, are discussed in the Planning GPO Deployment section. In this section you can find information about the following: Firewall GPOs Isolated Domain GPOs Boundary Zone GPOs Encryption Zone GPOs Server Isolation GPOs Firewall GPOs All the computers on Woodgrove Bank's network that run Windows are part of the isolated domain, except domain controllers. To configure firewall rules, the two GPOs described in this section are linked to the domain container in the Active Directory OU hierarchy, and then filtered by using security group filters and WMI filters. The GPOs created for the example Woodgrove Bank scenario include the following: GPO_DOMISO_Firewall_2008_Vista GPO_DOMISO_Firewall_2003_XP 88

89 GPO_DOMISO_Firewall_2008_Vista This GPO is authored by using the Windows Firewall with Advanced Security interface in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It is intended to only apply to computers that are running either Windows Server 2008 or Windows Vista. Firewall settings This GPO provides the following settings: Unless otherwise stated, the firewall rules and settings described here are applied to all profiles. The firewall is enabled, with inbound, unsolicited connections blocked and outbound connections allowed. Under the domain profile, the settings Display notifications to the user, Apply local firewall rules, and Apply local connection security rules are all set to No. These settings are applied only to the domain profile because the computers can only receive an exception rule for a required program from a GPO if they are connected to the domain. Under the public and private profiles, those settings are all set to Yes. Note Firewall rules Enforcing these settings requires that you define any firewall exceptions for programs, because the user cannot manually permit a new program. You must deploy the exception rules by adding them to this GPO. We recommend that you do not enable these settings until you have tested all your applications and have tested the resulting rules in a test lab and then on pilot computers. This GPO provides the following rules: Built-in firewall rule groups are configured to support typically required network operation. The following rule groups are set to Allow the connection: Core Networking File and Printer Sharing Network Discovery Remote Administration Remote Desktop Remote Event Log Management Remote Scheduled Tasks Management Remote Service Management Remote Volume Management Windows Firewall Remote Management Windows Management Instrumentation (WMI) Windows Remote Management 89

90 A firewall exception rule to allow required network traffic for the WGBank dashboard program. This inbound rule allows network traffic for the program Dashboard.exe in the %ProgramFiles%\WGBank folder. The rule is also filtered to only allow traffic on port This rule is applied only to the domain profile. Next: GPO_DOMISO_Firewall_2003_XP GPO_DOMISO_Firewall_2003_XP This GPO is authored by using the Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall section in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It is intended to only apply to server computers that are running either Windows Server 2003 or Windows XP. This GPO provides the following settings and rules: Most of the Windows Firewall settings described in this section are applied to both the domain and standard profiles. However, settings that prevent users from adding their own rules are enabled on the standard profile, but disabled on the domain profile. That ability is typically required when the user is not on the organization's network. The firewall is enabled and configured by modifying the settings shown in the following table. Setting Domain Profile Standard Profile Allow local program exceptions Protect all network connections Disabled Enabled Not configured Enabled Do not allow exceptions Disabled Disabled Allow inbound file and printer sharing exception Allow ICMP exceptions Enabled, with address set to /16 Enabled, all check boxes selected Not configured Not configured Prohibit notifications Enabled Not configured Allow local port exceptions Disabled Not configured Allow inbound remote administration exception Allow inbound Remote Desktop exceptions Allow inbound UPnP framework exceptions Enabled, with address set to /16 Enabled, with address set to /16 Enabled, with address set to /16 Not configured Not configured Not configured 90

91 Note By setting Allow local program exceptions and Allow local port exceptions to Disable, and by setting Prohibit notifications to Enable, you block users from manually allowing new programs. Therefore, you must define any required firewall exception rules for programs by adding them to this GPO. We recommend that you do not enable these settings until you have tested all your applications, created the required rules, and tested the resulting rules in a test lab and then on a set of pilot computers. An inbound program exception to allow traffic for the WGBank Dashboard program is assigned to the domain profile only, with the following text added: %ProgramFiles%\WGBank\Dashboard.exe: \16:Enabled:WGBank Dashboard Next: Isolated Domain GPOs Isolated Domain GPOs All of the computers in the isolated domain are added to the group CG_DOMISO_IsolatedDomain. You must create multiple GPOs to align with this group, one for each Windows operating system that must have different rules or settings to implement the basic isolated domain functionality that you have in your isolated domain. This group is granted Read and Apply Group Policy permissions on all the GPOs described in this section. Each GPO has a security group filter that prevents the GPO from applying to members of the group GP_DOMISO_No_IPsec. A WMI filter is attached to each GPO to ensure that the GPO is applied to only the specified version of Windows. Each GPO for versions of Windows other than Windows 2000 Server also has a security group filter that denies Read and Apply Group Policy permission to computers that run Windows 2000 Server. Likewise, the GPO for Windows 2000 Server has a WMI filter that enables the GPO to apply only to computers that are running Windows 2000 Server. For more information, see the Planning GPO Deployment section. The GPOs created for the Woodgrove Bank isolated domain include the following: GPO_DOMISO_IsolatedDomain_Clients_WinVista GPO_DOMISO_IsolatedDomain_Servers_WS2008 GPO_DOMISO_IsolatedDomain_Clients_WinXP GPO_DOMISO_IsolatedDomain_Servers_WS2003 GPO_DOMISO_IsolatedDomain_Servers_Win2000 GPO_DOMISO_IsolatedDomain_Clients_WinVista This GPO is authored by using the Windows Firewall with Advanced Security interface in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It is intended to only apply to client computers that are running Windows Vista. Because client computers can sometimes be portable, the settings and rules for this GPO are applied to only the domain profile. General settings 91

92 This GPO provides the following settings: No firewall settings are included in this GPO. Woodgrove Bank created separate GPOs for firewall settings (see the Firewall GPOs section) in order to share them with all clients in all isolation zones with minimum redundancy. The ICMP protocol is exempted from authentication requirements to support easier network troubleshooting. Diffie-Hellman Group 2 is specified as the key exchange algorithm. This is the strongest algorithm available that is supported by all the operating systems that are being used at Woodgrove Bank. After Woodgrove Bank has completed the upgrade to versions of Windows that support stronger algorithms, such as Windows Vista or Windows Server 2008, they can remove the weaker key exchange algorithms, and use only the stronger ones. The registry settings shown in the following table. For more information, see the description of the registry settings in Isolated Domain. Setting Value Enable PMTU Discovery 1 IPsec Exemptions 3 Enable IPsec over NAT-T 0 The main mode security method combinations in the order shown in the following table. Integrity Secure Hash Algorithm (SHA-1) SHA-1 Encryption Advanced Encryption Standard (AES-128) 3DES The following quick mode security data integrity algorithms combinations in the order shown in the following table. Protocol Integrity Key Lifetime (minutes/kb) ESP SHA-1 60/100,000 The quick mode security data integrity and encryption algorithm combinations in the order shown in the following table. 92

93 Protocol Integrity Encryption Key Lifetime (minutes/kb) ESP SHA-1 AES /100,000 ESP SHA-1 3DES 60/100,000 Note Do not use the MD5 and DES algorithms in your GPOs. They are included only for compatibility with previous versions of Windows. Connection Security Rules This GPO provides the following rules: A connection security rule named Isolated Domain Rule with the following settings: From Any IP address to Any IP address. Require inbound and request outbound authentication requirements. Important On this, and all other GPOs that require authentication, Woodgrove Bank first chose to only request authentication. After confirming that the computers were successfully communicating by using IPsec, they switched the GPOs to require authentication. For First authentication methods, select Computer Kerberos v5 as the primary method. Add certificate-based authentication from DC=com,DC=woodgrovebank,CN=CorporateCertServer for computers that cannot run Windows or cannot join the domain, but must still participate in the isolated domain. For Second authentication, select User Kerberos v5, and then select the Second authentication is optional check box. A connection security rule to exempt computers that are in the exemption list from the requirement to authenticate: The IP addresses of all computers on the exemption list must be added individually under Endpoint 2. Authentication mode is set to Do not authenticate. Next: GPO_DOMISO_IsolatedDomain_Servers_WS2008 GPO_DOMISO_IsolatedDomain_Servers_WS2008 This GPO is authored by using the Windows Firewall with Advanced Security interface in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It is intended to only apply to server computers that are running Windows Server Because so many of the settings and rules for this GPO are common to those in the GPO for Windows Vista, you can save time by exporting the Windows Firewall with Advanced Security 93

94 piece of the GPO for Windows Vista, and importing it to the GPO for Windows Server After the import, change only the items specified here: This GPO applies all its settings to all profiles: Domain, Private, and Public. Because a server is not expected to be mobile and changing networks, configuring the GPO in this way prevents a network failure or the addition of a new network adapter from unintentionally switching the computer to the Public profile with a different set of rules. Important Windows Vista and Windows Server 2008 support only one network location profile at a time. The profile for the least secure network type is applied to the computer. If you attach a network adapter to a computer that is not physically connected to a network, the public network location type is associated with the network adapter and applied to the computer. Next: GPO_DOMISO_IsolatedDomain_Clients_WinXP GPO_DOMISO_IsolatedDomain_Clients_WinXP This GPO is authored by using the Computer Configuration\Windows Settings\Security Settings\IP Security Policies section in the GPO editing tools. The User Configuration section of the GPO is disabled. It is intended to only apply to server computers that are running Windows XP. This GPO provides the following settings and rules: IPsec rules The GPO is configured to use the following IPsec elements: IPsec filter lists The GPO is configured to use the IP filter lists shown in the following table. Name Mirrored Source <->Dest Ports Protocols All IP Traffic Yes Any <-> Any Any <-> Any Any ICMP Traffic Yes Any <-> Any Any <-> Any ICMP Exemption List Yes Any <-> IP address list of all exempted hosts Any <-> Any Any Note You must set the source and destination addresses as shown in the previous table to ensure that Windows applies the filters correctly from most specific to most general. IPsec filter actions The GPO is configured to use the IPsec filter actions shown in the following table. 94

95 Name Method Algorithms AH ESP:{integrity/encryption} Key lifetime (KB/seconds) Request Security Negotiate ESP:SHA1/none 100,000/3600 Selected ESP:SHA1/3DES Selected Allow Traffic Permit n/a Not applicable Not applicable Not applicable Require Security Negotiate ESP:SHA1/none 100,000/3600 Cleared ESP:SHA1/3DES Selected The Method column in the previous table includes of the following three settings in the following order: Permit / Block / Negotiate security options Accept unsecured communication, but always respond using IPsec check box. This is the inbound fallback-to-clear option. Allow fallback to unsecured communication if a secure connection cannot be established check box. This is the outbound fallback-to-clear option. IPsec policies The GPO is configured to use an IPsec policy named "Isolated Domain" that contains the rules shown in the following table. The rules are composed of the filter lists and filter actions that were configured earlier in this topic. IP Filter list Filter action Authentication All IP traffic Require Security (see Caution below) Kerberos V5 Certificate from internal CA ICMP traffic Allow Traffic Not applicable Exemption List Allow Traffic Not applicable Caution When the IPsec policy is first deployed, we strongly recommended that you first set the filter action to request security so that if any computers fail to receive the IPsec policy they can continue to communicate. After you confirm that all the computers are successfully communicating by using IPsec, change the filter action to require security. IPsec registry settings 95

96 The GPO is configured to use the registry settings shown in the following table. For more information, see the description of the registry settings in Isolated Domain. Setting Value Enable PMTU Discovery 1 IPsec Exemptions 1 Enable IPsec over NAT-T 0 Simplified IPsec Policy 0x14 Note The simplified IPsec policy setting has no effect on computers that are running Windows The value is ignored. Next: GPO_DOMISO_IsolatedDomain_Servers_WS2003 GPO_DOMISO_IsolatedDomain_Servers_WS2003 This GPO is authored by using the Windows Firewall and IP Security Policies sections in the GPO editing tools. The User Configuration section of the GPO is disabled. It is intended to only apply to server computers that are running Windows Server Because so many of the settings and rules for this GPO are common to those in the GPO for Windows XP, you can save time by exporting the IP Security Policies part of the GPO for Windows XP, and importing it the policy for Windows Server The firewall part of the GPO must be recreated by hand. Alternatively, you can copy the whole GPO for Windows XP, paste it as a new GPO in the Group Policy Objects container, and then change only the following items here: The Woodgrove Bank GPO for Windows Server 2003 is currently identical to the GPO for Windows XP. However, a separate GPO is maintained so that if any differences are required in the future, they are easy to add to only the correct set of computers. The registry entry settings in the GPO for Windows XP must also be duplicated in this GPO. Next: GPO_DOMISO_IsolatedDomain_Servers_Win2000 GPO_DOMISO_IsolatedDomain_Servers_Win2000 This GPO is authored by using the IP Security Policies sections in the GPO editing tools. Windows 2000 Server does not have a built-in firewall. Therefore this guide does not discuss creating firewall policies for that version of Windows. The basic policy settings for Windows Server 2003 and Windows 2000 Server are identical. Therefore you can save time by copying the whole GPO for Windows Server 2003, paste it as a new GPO in the Group Policy Objects container, and then change only the items that must be different as discussed here: 96

97 The Woodgrove Bank GPO for Windows 2000 Server is currently identical to the GPO for Windows Server However, a separate GPO is maintained so that if any differences are required in the future, they are easy to add to only the correct set of computers. Next: Boundary Zone GPOs Boundary Zone GPOs All the computers in the boundary zone are added to the group CG_DOMISO_Boundary. You must create multiple GPOs to align with this group, one for each operating system that you have in your boundary zone. This group is granted Read and Apply permissions in Group Policy on the GPOs described in this section. Note If you are designing GPOs for only Windows Vista and Windows Server 2008, you can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, computers that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any computers that are incorrectly assigned to more than one group. This means that you create a GPO for a boundary group for a specific operating system by copying and pasting the corresponding GPO for the isolated domain, and then modifying the new copy to provide the behavior required in the boundary zone. The boundary zone GPOs discussed in this guide are only for server versions of Windows because client computers are not expected to participate in the boundary zone. If the need for one occurs, either create a new GPO for that version of Windows, or expand the WMI filter attached to one of the existing boundary zone GPOs to make it apply to the client version of Windows. In the Woodgrove Bank example, only the GPO settings for a Web service on Windows Server 2008 or Windows Server 2003 are discussed. The equivalent GPO for Windows 2000 is functionally identical to the one for Windows Server 2003, with the exception of firewall rules that are not supported on Windows GPO_DOMISO_Boundary_WS2008 GPO_DOMISO_Boundary_WS2003 GPO_DOMISO_Boundary_WS2008 This GPO is authored by using the Windows Firewall with Advanced Security interface in the Group Policy editing tools. Woodgrove Bank began by copying and pasting the GPO for the 97

98 Windows Server 2008 version of the isolated domain GPO, and then renamed the copy to reflect its new purpose. This GPO supports the ability for computers that are not part of the isolated domain to access specific servers that must be available to those untrusted computers. It is intended to only apply to server computers that are running Windows Server IPsec settings The copied GPO includes and continues to use the IPsec settings that configure key exchange, main mode, and quick mode algorithms for the isolated domain when authentication can be used. Connection security rules Rename the Isolated Domain Rule to Boundary Zone Rule. Change the authentication mode to Request inbound and request outbound. In this mode, the computer uses authentication when it can, such as during communication with a member of the isolated domain. It also supports the "fall back to clear" ability of request mode when an untrusted computer that is not part of the isolated domain connects. Registry settings The boundary zone uses the same registry settings as the isolated domain to optimize IPsec operation. For more information, see the description of the registry settings in Isolated Domain. Firewall rules Copy the firewall rules for the boundary zone from the GPO that contains the firewall rules for the isolated domain. Customize this copy, removing rules for services not needed on servers in this zone, and adding inbound rules to allow the network traffic for the services that are to be accessed by other computers. For example, Woodgrove Bank added a firewall rule to allow inbound network traffic to TCP port 80 for Web client requests. Make sure that the GPO that contains firewall rules for the isolated domain does not also apply to the boundary zone to prevent overlapping, and possibly conflicting rules. Next: GPO_DOMISO_Boundary_WS2003 GPO_DOMISO_Boundary_WS2003 This GPO is authored by using the Windows Firewall and IP Security Policies sections in the GPO editing tools. Woodgrove Bank began by copying and pasting the GPO for the Windows Server 2003 version of the isolated domain GPO, and renamed the copy to reflect its new purpose. This GPO supports the ability for computers that are not part of the isolated domain to access specific servers that must be available to those untrusted computers. It is intended to only apply to server computers that are running Windows Server In addition to the existing filter lists, filter actions, and registry settings, the following are added to support computers in the boundary zone. IP filter actions Create the following IP filter action: Name: Request In/Out 98

99 Security Methods:Negotiate security, with the same security method that is used in the isolated domain GPO. Select the Accept unsecured communication, but always respond using IPsec check box (the inbound fall back to clear option). Select the Allow fallback to unsecured communication if a secure connection cannot be established check box (the outbound fall back to clear option). IPsec policies The GPO is configured to use an IPsec policy named "Boundary Zone Policy" that contains the rules shown in the following table. IP Filter list Filter action Authentication All IP traffic Request In/Out Computer-based Kerberos V5 ICMP traffic Allow Traffic Not applicable Exemption List Allow Traffic Not applicable Certificate from internal CA The same key exchange, main mode, and quick mode algorithms as specified in the isolated domain GPO for Windows Server 2003 are used here. The same registry settings added to the Windows Server 2003 isolated domain GPO are included here, using the same values. For more information, see the description of the registry settings in Isolated Domain. After creating the Boundary Zone Policy, assign it as the active policy in the GPO. Firewall rules Copy the firewall rules for the boundary zone from the GPO that contains the firewall rules for the isolated domain. Customize this copy, removing rules for services not needed on servers in this zone, and adding inbound rules to allow the network traffic for the services that are to be accessed by other computers. For example, Woodgrove Bank added a firewall rule to allow inbound network traffic to TCP port 80 for Web client requests. Make sure that the GPO that contains firewall rules for the isolated domain does not also apply to the boundary zone to prevent overlapping, and possibly conflicting rules. Next: Encryption Zone GPOs Encryption Zone GPOs Handle encryption zones in a similar manner to the boundary zones. A computer is added to an encryption zone by adding the computer account to the encryption zone group. Woodgrove Bank has a single service that must be protected, and the computers that are running that service are added to the group CG_DOMISO_Encryption. This group is granted Read and Apply Group Policy permissions in on the GPOs described in this section. 99

100 The GPOs are only for server versions of Windows. Client computers are not expected to participate in the encryption zone. If the need for one occurs, either create a new GPO for that version of Windows, or expand the WMI filter attached to one of the existing encryption zone GPOs to make it apply to the client version of Windows. GPO_DOMISO_Encryption_WS2008 GPO_DOMISO_Encryption_WS2003 GPO_DOMISO_Encryption_WS2008 This GPO is authored by using the Windows Firewall with Advanced Security interface in the Group Policy editing tools. Woodgrove Bank began by copying and pasting the GPO for the Windows Server 2008 version of the isolated domain GPO, and then renamed the copy to reflect its new purpose. This GPO supports the ability for servers that contain sensitive data to require encryption for all connection requests. It is intended to only apply to server computers that are running Windows Server IPsec settings The copied GPO includes and continues to use the IPsec settings that configure key exchange, main mode, and quick mode algorithms for the isolated domain The following changes are made to encryption zone copy of the GPO: The encryption zone servers require all connections to be encrypted. To do this, change the IPsec default settings for the GPO to enable the setting Require encryption for all connection security rules that use these settings. This disables all integrity-only algorithm combinations. Connection security rules Rename the Isolated Domain Rule to Encryption Zone Rule. Leave the authentication mode setting on Require inbound and request outbound. In this mode, the computer forces authentication for all inbound network traffic, and uses it when it can on outbound traffic. Registry settings The encryption zone uses the same registry settings as the isolated domain to optimize IPsec operation. For more information, see the description of the registry settings in Isolated Domain. Firewall rules Copy the firewall rules for the encryption zone from the GPO that contains the firewall rules for the isolated domain. Customize this copy, removing rules for services not needed on servers in this zone, and adding inbound rules to allow the network traffic for the services that are to be accessed by other computers. For example, Woodgrove Bank added a firewall rule to allow inbound network traffic to TCP port 1433 for SQL Server client requests. Change the action for every inbound firewall rule from Allow the connection to Allow only secure connections, and then select Require the connections to be encrypted. Make sure that the GPO that contains firewall rules for the isolated domain does not also apply to the boundary zone to prevent overlapping, and possibly conflicting rules. Next: GPO_DOMISO_Encryption_WS

101 GPO_DOMISO_Encryption_WS2003 This GPO is authored by using the Windows Firewall and IP Security Policies sections in the GPO editing tools. Woodgrove Bank began by copying and pasting the GPO for the Windows Server 2003 version of the isolated domain GPO, and then renamed the copy to reflect its new purpose. This GPO supports the ability for servers that contain sensitive data to require encryption for all incoming connection requests. It is intended to only apply to server computers that are running Windows Server In addition to the existing filter lists, filter actions, and registry settings, the following are added to support computers in the encryption zone. IP filter actions Create the following IP filter action: Name: Encrypt Traffic Security Methods:Negotiate security, with a security method of Integrity and encryption (defaults to SHA1 and 3DES). Select the Accept unsecured communication, but always respond using IPsec check box (the inbound fall back to clear option). Select the Allow fallback to unsecured communication if a secure connection cannot be established check box (the outbound fall back to clear option). IPsec policies The GPO is configured to use an IPsec policy named "Encryption Zone Policy" that contains the rules shown in the following table. IP filter list Filter action Authentication All IP traffic Encrypt Traffic Kerberos V5 Certificate from internal CA ICMP traffic Allow Traffic Not applicable Exemption List Allow Traffic Not applicable The same key exchange, main mode, and quick mode algorithms as specified in the isolated domain GPO for Windows Server 2003 are used here. The same registry settings added to the Windows Server 2003 isolated domain GPO are included here, using the same values. For more information, see the description of the registry settings in Isolated Domain. After creating the Boundary Zone Policy, assign it as the active policy in the GPO. Firewall rules Copy the firewall rules for the encryption zone from the GPO that contains the firewall rules for the isolated domain. Customize this copy, removing rules for services not needed on servers in 101

102 this zone, and adding inbound rules to allow the network traffic for the services that are to be accessed by other computers. For example, Woodgrove Bank added a firewall rule to allow inbound network traffic to TCP port 1433 for SQL Server client requests. Make sure that the GPO that contains firewall rules for the isolated domain does not also apply to the boundary zone to prevent overlapping, and possibly conflicting rules. Next: Server Isolation GPOs Server Isolation GPOs Each set of computers that have different users or computers accessing them require a separate server isolation zone. Each zone requires one GPO for each version of Windows running on computers in the zone. The Woodgrove Bank example has an isolation zone for their computers that run SQL Server. The server isolation zone is logically considered part of the encryption zone. Therefore, server isolation zone GPOs must also include rules for encrypting all isolated server traffic. Woodgrove Bank copied the encryption zone GPOs to serve as a starting point, and renamed them to reflect their new purpose. All of the computer accounts for computers in the SQL Server server isolation zone are added to the group CG_SRVISO_WGBANK_SQL. This group is granted Read and Apply Group Policy permissions in on the GPOs described in this section. The GPOs are only for server versions of Windows. Client computers are not expected to be members of the server isolation zone, although they can access the servers in the zone by being a member of a network access group (NAG) for the zone. GPO_SRVISO_WS2008 This GPO is identical to the GPO_DOMISO_Encryption_WS2008 GPO with the following changes: The firewall rule that enforces encryption is modified to include the NAGs on the Users and Computers tab of the rule. The NAGs granted permission include CG_NAG_SQL_Users and CG_NAG_SQL_Computers. Important Earlier versions of Windows support only computer-based authentication. If you specify that user authentication is mandatory, only users on computers that are running Windows Vista or Windows Server 2008 can connect. GPO_SRVISO_WS2003 This GPO is authored by using the Windows Firewall and IP Security Policies sections in the GPO editing tools. The User Configuration section of the policy is disabled. It is intended to only apply to server computers that are running Windows Server This GPO is identical to the GPO_DOMISO_Encryption_WS2003 GPO with the following changes: Under User Rights Assignment, add the NAGs for users and computers to the Access this computer from the network user right. You must also remove the Everyone, Power Users, 102

103 and Users group from the user right list. The NAGs granted permission include CG_NAG_SQL_Users and CG_NAG_SQL_Computers. GPO_SRVISO_WS2000 We recommend that you do not use computers that are running Windows 2000 as isolated servers. If information on these servers is sensitive enough to merit the protections of server isolation, we recommend that you use a computer that is running a version of Windows with stronger security, such as Windows Server However, if business requirements are such that a computer running Windows 2000 Server must be placed in the boundary zone, design the GPO as follows: The basic policy settings for Windows Server 2003 and Windows 2000 are identical. Therefore you can save time by copying the whole GPO for Windows Server 2003, pasting it as a new GPO in the Group Policy Objects container, and then changing only the items that must be different. In the Woodgrove Bank example, the settings are the same, and no differences must be accounted for. We recommend that you create a separate GPO to support the ability to make operating system version specific changes, in case the need occurs. Next: Planning GPO Deployment Planning GPO Deployment You can control which GPOs are applied to computers in Active Directory in a combination of three ways: Active Directory organizational unit hierarchy. This involves linking the GPO to a specific OU in the Active Directory OU hierarchy. All computers in the OU and its subordinate containers receive and apply the GPO. Controlling GPO application through linking to OUs is typically used when you can organize the OU hierarchy according to your domain isolation zone requirements. GPOs can apply settings to computers based on their location within Active Directory. If a computer is moved from one OU to another, the policy linked to the second OU will eventually take effect when Group Policy detects the change during polling. Security group filtering. This involves linking the GPOs to the domain level (or other parent OU) in the OU hierarchy, and then selecting which computers receive the GPO by using permissions that only allow correct group members to apply the GPO. The security group filters are attached to the GPOs themselves. A group is added to the security group filter of the GPO in Active Directory, and then assigned Read and Apply Group Policy permissions. Other groups can be explicitly denied Read and Apply Group Policy permissions. Only those computers whose group membership are granted Read and Apply Group Policy permissions without any explicit deny permissions can apply the GPO. WMI filtering. A WMI filter is a query that is run dynamically when the GPO is evaluated. If a computer is a member of the result set when the WMI filter query runs, the GPO is applied to the computer. 103

104 A WMI filter consists of one or more conditions that are evaluated against the local computer. You can check almost any characteristic of the computer, its operating system, and its installed programs. If all of the specified conditions are true for the computer, the GPO is applied; otherwise the GPO is ignored. Important Computers running Windows 2000 Server ignore WMI filtering and will apply the GPO even if the WMI filter is written to explicitly exclude Windows 2000 Server. Having computers that run Windows 2000 Server on the network is a common reason for combining both security group filtering and WMI filtering. This guide uses a combination of security group filtering and WMI filtering to provide the most flexible options. If you follow this guidance, even though there might be five different GPOs linked to a specific group because of operating system version differences, only the correct GPO is applied. General considerations Because Windows 2000 Server does not support WMI filters, you must add all the computers running Windows 2000 Server to a group such as CG_DOMISO_WINDOWS2000, and set a security group filter using that group on the GPOs for the other operating systems that prevents their application to the members of the Windows 2000 Server group. Set a WMI filter on the GPO for the computers running Windows 2000 Server that prevents it from being applied to later versions of Windows. Deploy your GPOs before you add any computer accounts to the groups that receive the GPOs. That way you can add your computers to the groups in a controlled manner. Be sure to add only a few test computers at first. Before adding many group members, examine the results on the test computers and verify that the configured firewall and connection security rules have the effect that you want. See the following sections for some suggestions on what to test before you continue. Test your deployed groups and GPOs After you have deployed your GPOs and added some test computers to the groups, confirm the following before you continue with more group members: Examine the GPOs that are both assigned to and filtered from the computer. Run the gpresult tool at a command prompt. Examine the rules deployed to the computer. Open the Windows Firewall with Advanced Security MMC snap-in, expand the Monitoring node, and then expand the Firewall and Connection Security nodes. Verify that communications are authenticated. Open the Windows Firewall with Advanced Security MMC snap-in, expand the Monitoring node, expand the Security Associations node, and then click Main Mode. Verify that communications are encrypted when the computers require it. Open the Windows Firewall with Advanced Security MMC snap-in, expand the Monitoring node, expand the 104

105 Security Associations node, and then select Quick Mode. Encrypted connections display a value other than None in the ESP Confidentiality column. Verify that your programs are unaffected. Run them and confirm that they still work as expected. After you have confirmed that the GPOs have been correctly applied, and that the computers are now communicating by using IPsec network traffic in request mode, you can begin to add more computers to the group accounts, in manageable numbers at a time. Continue to monitor and confirm the correct application of the GPOs to the computers. Do not enable require mode until deployment is complete If you deploy a GPO that requires authentication to a computer before the other computers have a GPO deployed, communication between them might not be possible. Wait until you have all the zones and their GPOs deployed in request mode and confirm (as described in the previous section) that the computers are successfully communicating by using IPsec. If there are problems with GPO deployment, or errors in configuration of one or more of the IPsec GPOs, computers can continue to operate, because request mode enables any computer to fall back to clear communications. Only after you have added all of the computers to their zones, and you have confirmed that communications are working as expected, you can start changing the request mode rules to require mode rules where it is required in the zones. We recommend that you enable require mode in the zones one zone at a time, pausing to confirm that they are functioning properly before you continue. Turn the required mode setting on for the server isolation zones first, then the encryption zone, and then the isolated domain. Do not change the boundary zone GPO, because it must stay in request mode for both inbound and outbound connections. If you create other zones that require either inbound or outbound require mode, make the setting change in a manner that applies the setting in stages from the smaller groups of computers to the larger groups. Example Woodgrove Bank deployment plans Woodgrove Bank links all its GPOs to the domain level container in the Active Directory OU hierarchy. It then uses the following WMI filters and security group filters to control the application of the GPOs to the correct subset of computers. All of the GPOs have the User Configuration section disabled to improve performance. GPO_DOMISO_Firewall_2008_Vista WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "6.0%" and ProductType <> "2" 105

106 Note This excludes domain controllers (which report a ProductType value of 2). Do not include domain controllers in the isolated domain if there are computers running versions of Windows earlier than Windows Vista and Windows Server Security filter. This GPO grants Read and Apply Group Policy permissions in only to computers that are members of the group CG_DOMISO_IsolatedDomain. The GPO also explicitly denies Read and Apply Group Policy permissions to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_Firewall_2003_XP WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "5.2%" or Version like "5.1%" and ProductType <> "2" Note This excludes domain controllers (which report a ProductType value of 2). Do not include domain controllers in the isolated domain if there are computers that are running versions of Windows earlier than Windows Vista and Windows Server Security filter. This GPO grants Read and Apply Group Policy permissions only to computers that are members of the group CG_DOMISO_IsolatedDomain. The GPO also explicitly denies Read and Apply Group Policy permissions to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_IsolatedDomain_Clients_WinVista WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "6.0%" and ProductType = "1" Security filter. This GPO grants Read and Apply Group Policy permissions only to computers that are members of the group CG_DOMISO_IsolatedDomain. The GPO also explicitly denies Read and Apply Group Policy permissions to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_IsolatedDomain_Servers_WS2008 WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "6.0%" and ProductType = "3" Note This excludes domain controllers (which report a ProductType value of 2). Do not include domain controllers in the isolated domain if there are computers that are running versions of Windows earlier than Windows Vista and Windows Server Security filter. This GPO grants Read and Apply Group Policy permissions only to computers that are members of the group CG_DOMISO_IsolatedDomain. The GPO also 106

107 explicitly denies Read and Apply Group Policy permissions to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_IsolatedDomain_Clients_WinXP WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "5.1%" and ProductType = "1" Security filter. This GPO grants Read and Apply Group Policy permissions only to computers that are members of the group CG_DOMISO_IsolatedDomain. The GPO also explicitly denies Read and Apply Group Policy permissions to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_IsolatedDomain_Servers_WS2003 WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "5.2%" and ProductType = "3" Note This excludes domain controllers (which report a ProductType value of 2). Do not include domain controllers in the isolated domain if there are computers that are running versions of Windows earlier than Windows Vista and Windows Server Security filter. This GPO grants Read and Apply Group Policy permissions only to computers that are members of the group CG_DOMISO_IsolatedDomain. The GPO also explicitly denies Read and Apply Group Policy permissions to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_IsolatedDomain_Servers_Win2000 WMI filter. The WMI filter attached to this GPO allows it to apply to only computers that report an operating system version of 5.0. This is to prevent the GPO from applying to computers that are running later versions of Windows. Because computers running Windows 2000 Server cannot process WMI filters, all GPOs apply unless the GPO also has a security group filter that prevents the computer from reading or apply the GPO. Security filter. This GPO grants Read and Apply Group Policy permissions only to computers that are members of the group CG_DOMISO_WINDOWS2000. GPO_DOMISO_Boundary_WS2008 WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "6.0%" and ProductType = "3" Note This excludes domain controllers (which report a ProductType value of 2). Do not include domain controllers in the isolated domain if there are computers that are running versions of Windows earlier than Windows Vista and Windows Server

108 Security filter. This GPO grants Read and Apply Group Policy permissions only to computers that are members of the group CG_DOMISO_Boundary. The GPO also explicitly denies Read and Apply Group Policy permissions to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_Boundary_WS2003 WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "5.2%" and ProductType = "3" Note This excludes domain controllers (which report a ProductType value of 2). Do not include domain controllers in the isolated domain if there are computers that are running versions of Windows earlier than Windows Vista and Windows Server Security filter. This GPO grants Read and Apply permissions in Group Policy only to computers that are members of the group CG_DOMISO_Boundary. The GPO also explicitly denies Read and Apply permissions in Group Policy to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_Encryption_WS2008 WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "6.0%" and ProductType = "3" Note This excludes domain controllers (which report a ProductType value of 2). Do not include domain controllers in the isolated domain if there are computers that are running versions of Windows earlier than Windows Vista and Windows Server Security filter. This GPO grants Read and Apply permissions in Group Policy only to computers that are members of the group CG_DOMISO_Encryption. The GPO also explicitly denies Read and Apply permissions in Group Policy to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. GPO_DOMISO_Encryption_WS2003 WMI filter. The WMI filter allows this GPO to apply only to computers that match the following WMI query: select * from Win32_OperatingSystem where Version like "5.2%" and ProductType = "3" Note This excludes domain controllers (which report a ProductType value of 2). Do not include domain controllers in the isolated domain if there are computers that are running versions of Windows earlier than Windows Vista and Windows Server Security filter. This GPO grants Read and Apply permissions in Group Policy only to computers that are members of the group CG_DOMISO_Encryption. The GPO also explicitly 108

109 denies Read and Apply permissions in Group Policy to members of the group CG_DOMISO_Windows2000, and to the group CG_DOMISO_NO_IPSEC. Next: Appendix A: Sample GPO Template Files for Settings Used in this Guide Appendix A: Sample GPO Template Files for Settings Used in this Guide You can import an XML file containing customized registry preferences into a Group Policy object (GPO) by using the Preferences feature of the Group Policy Management Console (GPMC). Creating registry setting preferences as described here is a new feature in Windows Server 2008 and Windows Vista with Service Pack 1 (SP1). To manually create the file, build the settings under Computer Configuration, Preferences, Windows Settings, Registry. After you have created the settings, drag the container to the desktop. An.xml file is created there. To import an.xml file to GPMC, drag it and drop it on the Registry node under Computer Configuration, Preferences, Windows Settings. If you copy the following sample XML code to a file, and then drag and drop it on the Registry node, it creates a Server and Domain Isolation collection with the six registry keys discussed in this guide. The following sample file uses item-level targeting to ensure that the registry keys are applied only on the versions of Windows to which they apply. Note The file shown here is for sample use only. It should be customized to meet the requirements of your organization s deployment. To customize this file, import it into a test GPO, modify the settings, and then drag the Server and Domain Isolation Settings node to your desktop. The new file will contain all of your customization. <?xml version="1.0" encoding="utf-8"?> <Collection clsid="{53b533f5-224c-47e3-b01b-ca3b3f3ff4bf}" name="server and Domain Isolation Settings"> <Registry clsid="{9cd4b2f4-923d-47f5-a062-e897dd1dad50}" name="enable IPsec over NAT (W2K, XP, W2K3)" status="assumeudpencapsulationcontextonsendrule" image="12" changed=" :37:31" uid="{49fd da f2575e27b}" desc="<b>enable IPsec over NAT-T</b><p> 109

110 This setting configures whether computers running Windows 2003 and Windows XP can make IPsec connections to servers behind NAT-enabled routers.<p> <b>0</b>: (default) No IPsec SAs to servers behind NAT<br> <b>1</b>: IPsec SAs can be made to servers behind NAT<br> <b>2</b>: IPsec SAs can be made when both server and client are behind NAT" bypasserrors="1"> <Properties action="u" displaydecimal="1" default="0" hive="hkey_local_machine" key="system\currentcontrolset\services\ipsec" name="assumeudpencapsulationcontextonsendrule" type="reg_dword" value=" "/> <Filters> <FilterOs bool="and" not="1" class="nt" version="vista" type="ne" edition="ne" sp="ne"/> <FilterOs bool="and" not="1" class="nt" version="2k8" type="ne" edition="ne" sp="ne"/> </Filters> </Registry> <Registry clsid="{9cd4b2f4-923d-47f5-a062-e897dd1dad50}" name="enable PMTU Discovery" status="enablepmtudiscovery" image="12" changed=" :37:37" 110

111 uid="{52c38fd7-a c-a8ea-b24a9614d0b5}" desc="<b>enable PMTU Discovery</b><p> This setting configures whether computers can use PMTU discovery on the network.<p> <b>1</b> -- Enable<br> <b>0</b> -- Disable" bypasserrors="1"> <Properties action="u" displaydecimal="1" default="0" hive="hkey_local_machine" key="system\currentcontrolset\services\tcpip\parameters" name="enablepmtudiscovery" type="reg_dword" value=" "/> </Registry> <Registry clsid="{9cd4b2f4-923d-47f5-a062-e897dd1dad50}" name="simplified IPsec Policy (W2K, XP, W2K3)" status="ikeflags" image="12" changed=" :43:31" uid="{b9a34efb-cdf bbed-6bb85080c96f}" desc="<b>simplified IPsec Policy</b><p> This setting configures two aspects of IPsec fallback-to-clear in Windows 2003, Windows XP, and Windows 2000.<p> <b>0x00</b>: Original 3 second fallback-to-clear<br> <b>0x04</b>: Enables 500ms fallback-to-clear<br> <b>0x10</b>: Improve fallback-to-clear in S&amp;D Iso<br> <b>0x14</b>: Both 0x4 and 0x10 settings enabled (recommended)" bypasserrors="1"> <Properties action="u" 111

112 displaydecimal="0" default="0" hive="hkey_local_machine" key="system\currentcontrolset\services\policyagent\oakley" name="ikeflags" type="reg_dword" value=" "/> <Filters> <FilterOs bool="and" not="1" class="nt" version="vista" type="ne" edition="ne" sp="ne"/> <FilterOs bool="and" not="1" class="nt" version="2k8" type="ne" edition="ne" sp="ne"/> </Filters> </Registry> <Registry clsid="{9cd4b2f4-923d-47f5-a062-e897dd1dad50}" name="ipsec Default Exemptions (W2K and XP)" status="nodefaultexempt" image="12" changed=" :35:43" uid="{60f64c68-ef12-4fac-acc9-00b4f21724fa}" desc="<b>ipsec Default Exemptions for Windows 2000 SP4 and Windows XP SP2</b><p> This setting determines which network traffic type is exempt from any IPsec authentication requirements.<p> <b>0</b>: Exempts multicast, broadcast, RSVP, Kerberos, ISAKMP<br> <b>1</b>: Exempts multicast, broadcast, ISAKMP" bypasserrors="1"> 112

113 <Properties action="u" displaydecimal="1" default="0" hive="hkey_local_machine" key="system\currentcontrolset\services\ipsec" name="nodefaultexempt" type="reg_dword" value=" "/> <Filters> <FilterOs bool="and" not="1" class="nt" version="vista" type="ne" edition="ne" sp="ne"/> <FilterOs bool="and" not="1" class="nt" version="2k8" type="ne" edition="ne" sp="ne"/> <FilterOs bool="and" not="1" class="nt" version="2k3r2" type="ne" edition="ne" sp="ne"/> <FilterOs bool="and" not="1" class="nt" version="2k3" type="ne" edition="ne" sp="ne"/> </Filters> </Registry> <Registry clsid="{9cd4b2f4-923d-47f5-a062-e897dd1dad50}" name="ipsec Default Exemptions (W2K3)" status="nodefaultexempt" image="12" 113

114 changed=" :34:03" uid="{ d-5e8a-4e16-bea3-ea efa}" desc="<b>ipsec Default Exemptions for Windows Server 2008 and later</b><p> This setting determines which network traffic type is exempt from any IPsec authentication requirements.<p> <b>0</b>: Exempts multicast, broadcast, RSVP, Kerberos, ISAKMP<br> <b>1</b>: Exempts multicast, broadcast, ISAKMP<br> <b>2</b>: Exempts RSVP, Kerberos, ISAKMP<br> <b>3</b>: Exempts ISAKMP only" bypasserrors="1"> <Properties action="u" displaydecimal="1" default="0" hive="hkey_local_machine" key="system\currentcontrolset\services\ipsec" name="nodefaultexempt" type="reg_dword" value=" "/> <Filters> <FilterOs bool="and" not="0" class="nt" version="2k3" type="ne" edition="ne" sp="ne"/> <FilterOs bool="or" not="0" class="nt" version="2k3r2" type="ne" edition="ne" sp="ne"/> </Filters> </Registry> <Registry 114

115 clsid="{9cd4b2f4-923d-47f5-a062-e897dd1dad50}" name="ipsec Default Exemptions (Vista and W2K8)" status="nodefaultexempt" image="12" changed=" :33:32" uid="{ae5c505d-283e a dfd56b6}" desc="<b>ipsec Default Exemptions for Windows Server 2008 and later</b><p> This setting determines which network traffic type is exempt from any IPsec authentication requirements.<p> <b>0</b>: Exempts multicast, broadcast, RSVP, Kerberos, ISAKMP<br> <b>1</b>: Exempts multicast, broadcast, ISAKMP<br> <b>2</b>: Exempts RSVP, Kerberos, ISAKMP<br> <b>3</b>: Exempts ISAKMP only" bypasserrors="1"> <Properties action="u" displaydecimal="1" default="0" hive="hkey_local_machine" key="system\currentcontrolset\services\policyagent" name="nodefaultexempt" type="reg_dword" value=" "/> <Filters> <FilterOs bool="and" not="0" class="nt" version="vista" type="ne" edition="ne" sp="ne"/> <FilterOs bool="or" not="0" class="nt" version="2k8" type="ne" edition="ne" sp="ne"/> 115

116 </Filters> </Registry> <Registry clsid="{9cd4b2f4-923d-47f5-a062-e897dd1dad50}" name="enable IPsec over NAT (Vista and W2K8)" status="assumeudpencapsulationcontextonsendrule" image="12" changed=" :32:56" uid="{61c18aa8-f78e-453b-809a-98354d407035}" desc="<b>enable IPsec over NAT-T</b><p> This setting configures whether computers running Windows 2003 and Windows XP can make IPsec connections to servers behind NAT-enabled routers.<p> <b>0</b>: (default) No IPsec SAs to servers behind NAT<br> <b>1</b>: IPsec SAs can be made to servers behind NAT<br> <b>2</b>: IPsec SAs can be made when both server and client are behind NAT" bypasserrors="1"> <Properties action="u" displaydecimal="1" default="0" hive="hkey_local_machine" key="system\currentcontrolset\services\policyagent" name="assumeudpencapsulationcontextonsendrule" type="reg_dword" value=" "/> <Filters> <FilterOs bool="and" not="0" class="nt" version="vista" type="ne" edition="ne" sp="ne"/> <FilterOs 116

117 bool="or" not="0" class="nt" version="2k8" type="ne" edition="ne" sp="ne"/> </Filters> </Registry> </Collection> Additional Resources For more information about the technologies discussed in this guide, see topics referenced in the following sections. Windows Firewall with Advanced Security Windows Firewall ( This TechNet page contains links to a variety of documents available for Windows Firewall, for Windows XP, Windows Server 2003, Windows Vista, and Windows Server Windows Firewall with Advanced Security Content Roadmap ( This topic describes the documents currently available in the Windows Technical Library for Windows Firewall with Advanced Security in Windows Vista and Windows Server Windows Firewall with Advanced Security - Diagnostics and Troubleshooting ( This article describes how Windows Firewall with Advanced Security works, what the common troubleshooting situations are, and which tools you can use for troubleshooting. IPsec IPsec ( This TechNet page contains links to a variety of documents currently available for Internet Protocol security (IPsec), for Windows XP, Windows Server 2003, and the version available as connection security rules in Windows Firewall with Advanced Security on Windows Vista and Windows Server Simplifying IPsec Policy with the Simple Policy Update ( This article describes a downloadable update available for Windows XP with SP2 and Windows Server 2003 with SP1. The update changes the behavior of IPsec negotiation so that the IPsec policy rules can be simplified, in some cases significantly reducing the number of required IP filters and their ongoing maintenance. 117

118 Server and Domain Isolation Server and Domain Isolation ( This TechNet page contains links to documentation about the most common uses for IPsec: server isolation and domain isolation. Documentation is available for Windows XP, Windows Server 2003, Windows Vista, and Windows Server Group Policy Group Policy is a key method for implementing firewall and server and domain isolation designs. For more information about Group Policy and related technologies, see: Group Policy ( This page contains links to the documents currently available for Group Policy, for both the version available in Windows XP and Windows Server 2003, and the version available in Windows Vista and Windows Server WMI Filtering Using GPMC ( HOWTO: Leverage Group Policies with WMI Filters ( This article describes how to create a WMI filter to set the scope of a GPO based on computer attributes, such as operating system. Active Directory Domain Services In Windows Server 2008, organizations can use AD DS to manage users and resources, such as computers, printers, or applications, on a network. Server isolation and domain isolation also require AD DS to use the Kerberos V5 protocol for IPsec authentication. For more information about AD DS and related technologies, see: Active Directory Domain Services ( 118

119 Windows Firewall with Advanced Security Deployment Guide You can use the Windows Firewall with Advanced Security MMC snap-in in Windows Vista and Windows Server 2008 to help protect the computers and the data that they share across a network. You can use Windows Firewall to control access to the computer from the network. You can create rules that allow or block network traffic in either direction based on your business requirements. You can also create IPsec connection security rules to help protect your data as it travels across the network from computer to computer. About this guide This guide is intended for use by system administrators and system engineers. It provides detailed guidance for deploying a Windows Firewall with Advanced Security design that you or an infrastructure specialist or system architect in your organization has selected. Begin by reviewing the information in Planning to Deploy Windows Firewall with Advanced Security. If you have not yet selected a design, we recommend that you wait to follow the instructions in this guide until after you have reviewed the design options in the Windows Firewall with Advanced Security Design Guide and selected the one most appropriate for your organization. After you select your design and gather the required information about the zones (main isolation, boundary, and encryption), operating systems to support, and other details, you can then use this guide to deploy your Windows Firewall with Advanced Security design in your production environment. This guide provides steps for deploying any of the following primary designs that are described in the Design Guide: Basic Firewall Policy Design Domain Isolation Policy Design Server Isolation Policy Design Certificate-based Isolation Policy Design Use the checklists in Implementing Your Windows Firewall with Advanced Security Design Plan to determine how best to use the instructions in this guide to deploy your particular design. Caution We recommend that you use the techniques documented in this guide only for GPOs that must be deployed to the majority of the computers in your organization, and only when the OU hierarchy in your Active Directory domain does not match the deployment needs of these GPOs. These characteristics are typical of GPOs for server and domain isolation scenarios, but are not typical of most other GPOs. When the OU hierarchy supports it, 119

120 deploy a GPO by linking it to the lowest level OU that contains all of the accounts to which the GPO applies. In a large enterprise environment with hundreds or thousands of GPOs, using this technique with too many GPOs can result in user or computer accounts that are members of an excessive number of groups; this can result in network connectivity problems if network protocol limits are exceeded. For more information about the problems associated with excessive group membership, see the following articles in the Microsoft Knowledge Base: What this guide does not provide This guide does not provide: Guidance for creating firewall rules for specific network applications. For this information, see Planning Settings for a Basic Firewall Policy in the Windows Firewall with Advanced Security Design Guide. Guidance for setting up Active Directory Domain Services (AD DS) to support Group Policy. For more information, see Active Directory Domain Services ( and Group Policy ( Guidance for setting up certification authorities (CAs) to create certificates for certificatebased authentication. For this information, see Active Directory Certificate Services ( Overview of Windows Firewall with Advanced Security Windows Firewall with Advanced Security in Windows Vista and Windows Server 2008 is a stateful host firewall that helps secure the computer by allowing you to create rules that determine which network traffic is permitted to enter the computer from the network and which network traffic the computer is allowed to send to the network. Windows Firewall with Advanced Security also supports Internet Protocol security (IPsec), which you can use to require authentication from any computer that is attempting to communicate with your computer. When authentication is required, computers that cannot be authenticated as a trusted computer cannot communicate with your computer. You can also use IPsec to require that certain network traffic is encrypted to prevent it from being read by network packet analyzers that could be attached to the network by a malicious user. The Windows Firewall with Advanced Security MMC snap-in is more flexible and provides much more functionality than the consumer-friendly Windows Firewall interface found in the Control Panel. Both interfaces interact with the same underlying services, but provide different levels of control over those services. While the Windows Firewall Control Panel program can protect a single computer in a home environment, it does not provide enough centralized management or 120

121 security features to help secure more complex network traffic found in a typical business enterprise environment. For more information about Windows Firewall with Advanced Security, see Windows Firewall with Advanced Security in the Windows Server 2008 Technical Library ( Planning to Deploy Windows Firewall with Advanced Security After you collect information about your environment and decide on a design by following the guidance in the Windows Firewall with Advanced Security Design Guide, you can begin to plan the deployment of your design. With the completed design and the information in this topic, you can determine which tasks to perform to deploy Windows Firewall with Advanced Security in your organization. Reviewing your Windows Firewall with Advanced Security Design If the design team that created the Windows Firewall with Advanced Security design for your organization is different from the deployment team that will implement it, make sure that the deployment team reviews the final design with the design team. Review the following points: The design team's strategy for determining how WMI and security group filters attached to the GPOs will determine which computers apply to which GPO. The deployment team can refer to the following topics in the Windows Firewall with Advanced Security Design Guide: Planning Isolation Groups for the Zones Planning the GPOs Planning GPO Deployment The communication to be allowed between members of each of the zones in the isolated domain and computers that are not part of the isolated domain or members of the isolated domain's exemption list. The recommendation that domain controllers are exempted from IPsec authentication requirements. If they are not exempt and authentication fails, then domain clients might not be able to receive Group Policy updates to the IPsec connection security rules from the domain controllers. The rationale for configuring all IPsec authentication rules to request, not require, authentication until the successful negotiation of IPsec has been confirmed. If the rules are set to require authentication before confirming that authentication is working correctly, then communications between computers might fail. If the rules are set to request authentication only, then an IPsec authentication failure results in fall-back-to-clear behavior, so communications can continue while the authentication failures are investigated. 121

122 The requirement that all computers that must communicate with each other share a common set of: Authentication methods Main mode key exchange algorithms Quick mode data integrity algorithms If at least one set of each does not match between two computers, then the computers cannot successfully communicate. After the design and deployment teams agree on these issues, they can proceed with the deployment of the Windows Firewall with Advanced Security design. For more information, see Implementing Your Windows Firewall with Advanced Security Design Plan. Implementing Your Windows Firewall with Advanced Security Design Plan The following are important factors in the implementation of your Windows Firewall with Advanced Security design plan: Group Policy. The Windows Firewall with Advanced Security designs make extensive use of Group Policy deployed by Active Directory Domain Services (AD DS). A sound Group Policy infrastructure is required to successfully deploy the firewall and IPsec settings and rules to the computers on your network. Group Policy Troubleshooting ( can help you review and change, if necessary, your Group Policy infrastructure. Perimeter firewall. Most organizations use a perimeter firewall to help protect the computers on the network from potentially malicious network traffic from outside of the organization's network boundaries. If you plan a deployment that includes a boundary zone to enable external computers to connect to computers in that zone, then you must allow that traffic through the perimeter firewall to the computers in the boundary zone. Computers running operating systems other than Windows. If your network includes computers that are not running the Windows operating system, then you must make sure that required communication with those computers is not blocked by the restrictions put in place by your design. You must do one of the following: Include those computers in the isolated domain or zone by adding certificate-based authentication to your design. Many other operating systems can participate in an isolated domain or isolated server scenario, as long as certificate-based authentication is used. Include the computer in the authentication exemption list included in your design. You can choose this option if for any reason the computer cannot participate in the isolated domain design. 122

123 How to implement your Windows Firewall with Advanced Security design using this guide The next step in implementing your design is to determine in what order each of the deployment steps must be performed. This guide uses checklists to help you accomplish the various deployment tasks that are required to implement your design plan. As the following diagram shows, checklists and subchecklists are used as necessary to provide the end-to-end procedure for deploying a design. 123

124 Use the following parent checklists in this section of the guide to become familiar with the deployment tasks for implementing your organization's Windows Firewall with Advanced Security design. Checklist: Implementing a Basic Firewall Policy Design Checklist: Implementing a Domain Isolation Policy Design Checklist: Implementing a Standalone Server Isolation Policy Design Checklist: Implementing a Certificate-based Isolation Policy Design The procedures in these checklists use the Group Policy MMC snap-in interfaces to configure firewall and connection security rules in GPOs, but you can also use netsh advfirewall, netsh firewall, and netsh ipsec. For more information, see Use Netsh to Configure GPOs. This guide recommends using GPOs in a specific way to deploy the rules and settings for your design. For information about deploying your GPOs, see Planning Group Policy Deployment for Your Isolation Zones and the checklist Checklist: Creating Group Policy Objects. Checklist: Creating Group Policy Objects To deploy firewall or IPsec settings or firewall or connection security rules, we recommend that you use Group Policy in AD DS. This section describes a tested, efficient method that requires some up-front work, but serves an administrator well in the long run by making GPO assignments as easy as dropping a computer into a membership group. The checklists for firewall, domain isolation, and server isolation include a link to this checklist. About membership groups For most GPO deployment tasks, you must determine which computers must receive and apply which GPOs. Because different versions of Windows can support different settings and rules to achieve similar behavior, you might need multiple GPOs: one for each operating system that has settings different from the others to achieve the same result. For example, Windows Vista and Windows Server 2008 use rules and settings that are incompatible with Windows 2000, Windows XP, and Windows Server Therefore, you must create a GPO for each set of operating systems that can share common settings. To deploy typical domain isolation settings and rules, you might have five different GPOs for the versions of Windows discussed in this guide. By following the procedures in this guide, you only need one membership group to manage all five GPOs. The membership group is identified in the security group filter for all five GPOs. To apply the settings to a computer, you make that computer's account a member of the membership group. WMI filters are used to ensure that the correct GPO is applied. About exclusion groups A Windows Firewall with Advanced Security design must often take into account domain-joined computers on the network that cannot or must not apply the rules and settings in the GPOs. Because these computers are typically fewer in number than the computers that must apply the GPO, it is easier to use the Domain Members group in the GPO membership group, and then 124

125 place these exception computers into an exclusion group that is denied Apply Group Policy permissions on the GPO. Because deny permissions take precedence over allow permissions, a computer that is a member of both the membership group and the exception group is prevented from applying the GPO. Computers typically found in a GPO exclusion group for domain isolation include the domain controllers, DHCP servers, and DNS servers. You can also use a membership group for one zone as an exclusion group for another zone. For example, computers in the boundary and encryption zones are technically in the main domain isolation zone, but must apply only the GPO for their assigned role. To do this, the GPOs for the main isolation zone deny Apply Group Policy permissions to members of the boundary and encryption zones. You might also use an exclusion group if some of the computers on your network are running Windows 2000, which does not support WMI filters. You create an exclusion group that contains all of the Windows 2000 computer accounts, and then deny that group permission to apply the GPOs for the other operating systems. Because deny permissions take precedence over allow permissions, a computer that is a member of both the membership group and the Windows 2000 exclusion group is prevented from applying the GPO. Only the GPO with settings for Windows 2000 does not have the exclusion group listed in its security group filter, so those computers can apply the GPO. WMI filters on the GPO for Windows 2000 prevent the other operating systems from applying it. Checklist: Creating Group Policy objects Task Review important concepts and examples for deploying GPOs in a way that best meets the needs of your organization. Create the membership group in AD DS that will be used to contain computer accounts that must receive the GPO. If some computers in the membership group are running an operating system that does not support WMI filters, such as Windows 2000, create an exclusion group to contain the computer accounts for the computers that cannot be blocked by using a WMI filter. Reference Identifying Your Windows Firewall with Advanced Security Deployment Goals Planning Group Policy Deployment for Your Isolation Zones Create a Group Account in Active Directory 125

126 Task Create a GPO for each version of Windows that has different implementation requirements. Create security group filters to limit the GPO to only computers that are members of the membership group and to exclude computers that are members of the exclusion group. Create WMI filters to limit each GPO to only the computers that match the criteria in the filter. If you are working on a GPO that was copied from another, modify the group memberships and WMI filters so that they are correct for the new zone or version of Windows for which this GPO is intended. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Before adding any rules or configuring the GPO, add a few test computers to the membership group, and make sure that the correct GPO is received and applied to each member of the group. Reference Create a Group Policy Object Assign Security Group Filters to the GPO Create WMI Filters for the GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Checklist: Implementing a Basic Firewall Policy Design This parent checklist includes cross-reference links to important concepts about the basic firewall policy design. It also contains links to subordinate checklists that will help you complete the tasks that are required to implement this design. 126

127 Notes Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist. The procedures in this section use the Group Policy MMC snap-in interfaces to configure the GPOs, but you can also use the Netsh command-line tool. For more information, see Use Netsh to Configure GPOs. Checklist: Implementing a basic firewall policy design Task Review important concepts and examples for the basic firewall policy design to determine if this design meets the needs of your organization. Create the membership group and a GPO for each set of computers that require different firewall rules. Where GPOs will be similar, such as for Windows Vista and Windows Server 2008, create one GPO, configure it by using the tasks in this checklist, and then make a copy of the GPO for the other version of Windows. For example, create and configure the GPO for Windows Vista, make a copy of it for Windows Server 2008, and then follow the steps in this checklist to make the few required changes to the copy. If you are working on a GPO that was copied from another, modify the group membership and WMI filters so that they are correct for Reference Identifying Your Windows Firewall with Advanced Security Deployment Goals Basic Firewall Policy Design Firewall Policy Design Example Planning Settings for a Basic Firewall Policy Checklist: Creating Group Policy Objects Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows 127

128 Task the computers for which this GPO is intended. Configure the GPO with firewall default settings appropriate for your design. Create one or more inbound firewall rules to allow unsolicited inbound network traffic. Create one or more outbound firewall rules to block unwanted outbound network traffic. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Add test computers to the membership group, and then confirm that the computers receive the firewall rules from the GPOs as expected. According to the testing and rollout schedule in your design plan, add computer accounts to the membership group to deploy the completed firewall policy settings to your computers. Reference Checklist: Configuring Basic Firewall Settings Checklist: Creating Inbound Firewall Rules Checklist: Creating Outbound Firewall Rules Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Add Production Computers to the Membership Group for a Zone Checklist: Configuring Basic Firewall Settings This checklist includes tasks for configuring a GPO with firewall defaults and settings that are separate from the rules. Note Windows 2000 does not include a built-in firewall, so security group filtering should be used to prevent computers running that version of the operating system from applying the GPO. Checklist: Configuring firewall defaults and settings 128

129 Task Turn the firewall on and set the default inbound and outbound behavior. Configure the firewall to not display notifications to the user when a program is blocked, and to ignore locally defined firewall and connection security rules. Configure the firewall to record a log file. Reference Turn on Windows Firewall and Configure Default Behavior Configure Windows Firewall to Suppress Notifications When a Program Is Blocked Configure the Windows Firewall Log Checklist: Creating Inbound Firewall Rules This checklist includes tasks for creating firewall rules in your GPOs. The way in which you create these rules depends on whether the computers to which the GPO applies are running Windows Vista or Windows Server 2008 or an earlier version of the Windows operating system. Note Windows 2000 does not include a built-in firewall, so security group filtering should be used to prevent computers running that version of the operating system from applying the GPO. In this topic: Checklist for Windows Vista and Windows Server 2008 Checklist for Windows XP and Windows Server 2003 Checklist: Creating inbound firewall rules for Windows Vista or Windows Server 2008 Task Create a rule that allows a program to listen for and accept inbound network traffic on any ports it requires. Create a rule that allows inbound network traffic on a specified port number. Create a rule that allows Reference Create an Inbound Program or Service Rule on Windows Vista or Windows Server 2008 Create an Inbound Port Rule on Windows Vista or Windows Server 2008 Create an Inbound ICMP 129

130 Task inbound ICMP network traffic. Create rules that allow inbound RPC network traffic. Enable a predefined rule or a group of predefined rules. Some predefined rules for basic network services are included as part of the installation of Windows; others can be created when you install a new application or network service. Reference Rule on Windows Vista or Windows Server 2008 Create Inbound Rules to Support RPC on Windows Vista or Windows Server 2008 Enable Predefined Inbound Rules on Windows Vista or Windows Server 2008 Checklist: Creating inbound firewall rules for Windows XP or Windows Server 2003 Task Create a rule that allows a program to listen for and accept inbound network traffic on any ports it requires. Create a rule that allows inbound network traffic on a specified port number. Enable predefined rules for file and printer sharing, ICMP, remote administration, remote desktop, or network Plug and Play. Reference Create an Inbound Program Rule on Windows XP or Windows Server 2003 Create an Inbound Port Rule on Windows XP or Windows Server 2003 Enable Predefined Inbound Rules on Windows XP or Windows Server 2003 Checklist: Creating Outbound Firewall Rules This checklist includes tasks for creating outbound firewall rules in your GPOs. The firewall in earlier versions of the Windows operating system allowed all outbound network traffic, and provided no way to block it. Windows Vista and Windows Server 2008 support the use of outbound rules. 130

131 Important By default, in Windows Vista and Windows Server 2008, outbound filtering is disabled. Because all outbound network traffic is permitted, outbound rules are typically used to block traffic that is not wanted on the network. However, it is a best practice for an administrator to create outbound allow rules for those applications that are approved for use on the organization s network. If you do this, then you have the option to set the default outbound behavior to block, preventing any network traffic that is not specifically authorized by the rules you create. Note Windows XP and Windows Server 2003 do not support outbound filtering. Note Windows 2000 does not include a built-in firewall, so security group filtering should be used to prevent computers running that version of the operating system from applying the GPO. Checklist: Creating outbound firewall rules for Windows Vista or Windows Server 2008 Task Create a rule that allows a program to send any outbound network traffic on any port it requires. Create a rule that allows outbound network traffic on a specified port number. Enable a predefined rule or a group of predefined rules. Some predefined rules for basic network services are included as part of the installation of Windows; others can be created when you install a new application or network service. Reference Create an Outbound Program or Service Rule on Windows Vista or Windows Server 2008 Create an Outbound Port Rule on Windows Vista or Windows Server 2008 Enable Predefined Outbound Rules on Windows Vista or Windows Server

132 Checklist: Implementing a Domain Isolation Policy Design This parent checklist includes cross-reference links to important concepts about the domain isolation policy design. It also contains links to subordinate checklists that will help you complete the tasks that are required to implement this design. Notes Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist. The procedures in this section use the Group Policy MMC snap-ins to configure the GPOs, but you can also use the Netsh command-line tool to configure GPOs. For more information, see Use Netsh to Configure GPOs. For more information about the security algorithms and authentication methods available in each version of Windows, see IPsec Algorithms and Methods Supported in Windows ( Checklist: Implementing a domain isolation policy design Task Review important concepts and examples for the domain isolation policy design, determine your Windows Firewall with Advanced Security deployment goals, and customize this design to meet the needs of your organization. Create the GPOs and connection security rules for the isolated domain. Create the GPOs and connection security rules for the boundary zone. Create the GPOs and connection security rules for the encryption zone. Create the GPOs and Reference Identifying Your Windows Firewall with Advanced Security Deployment Goals Domain Isolation Policy Design Domain Isolation Policy Design Example Planning Domain Isolation Zones Checklist: Configuring Rules for the Isolated Domain Checklist: Configuring Rules for the Boundary Zone Checklist: Configuring Rules for the Encryption Zone Checklist: Configuring Rules 132

133 Task connection security rules for the isolated server zone. According to the testing and rollout schedule in your design plan, add computer accounts to the membership group to deploy rules and settings to your computers. After you confirm that network traffic is authenticated by IPsec, you can change authentication rules for the isolated domain and encryption zone from request to require mode. Reference for an Isolated Server Zone Add Production Computers to the Membership Group for a Zone Change Rules from Request to Require Mode Checklist: Configuring Rules for the Isolated Domain The following checklists include tasks for configuring connection security rules and IPsec settings in your GPOs to implement the main zone in the isolated domain. The way in which you configure these rules and settings depends on whether the computers to which the GPO applies are running Windows Vista or Windows Server 2008 or an earlier version of the Windows operating system. In this topic: Checklist for Windows Vista and Windows Server 2008 Checklist for Windows XP, Windows Server 2003, and Windows 2000 Checklist: Configuring isolated domain rules for computers running Windows Vista or Windows Server 2008 Note The GPOs for computers running Windows Vista and Windows Server 2008 are usually similar. If this is true for your design, create one GPO, configure it by using the tasks in this checklist, and then make a copy of the GPO for the other operating system. For example, create and configure the GPO for Windows Vista, make a copy of it for Windows Server 2008, and then follow the steps in this checklist to make the few required changes to the copy. 133

134 Task Create a GPO for the computers in the isolated domain running one of the operating systems. After you have finished the tasks in this checklist and configured the GPO for that version of Windows, you can create a copy of it. If you are working on a GPO that was copied from another GPO, modify the group memberships and WMI filters so that they are correct for the isolated domain zone and the version of Windows for which this GPO is intended. Configure IPsec to exempt all ICMP network traffic from IPsec protection. Create a rule that exempts all network traffic to and from computers on the exemption list from IPsec. Configure the key exchange (main mode) security methods and algorithms to be used. Configure the data protection (quick mode) algorithm combinations to be used. Configure the authentication methods to be used. Create the rule that requests authentication for all inbound network traffic. Reference Checklist: Creating Group Policy Objects Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Exempt ICMP from Authentication on Windows Vista and Windows Server 2008 Create an Authentication Exemption List Rule on Windows Vista and Windows Server 2008 Configure Key Exchange (Main Mode) Settings on Windows Vista and Windows Server 2008 Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server 2008 Configure Authentication Methods on Windows Vista and Windows Server 2008 Create an Authentication Request Rule on Windows Vista and Windows Server

135 Task Link the GPO to the domain level of the AD DS organizational unit hierarchy. Add your test computers to the membership group for the isolated domain. Be sure to add at least one for each operating system supported by a different GPO in the group. Verify that the connection security rules are protecting network traffic to and from the test computers. Reference Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Verify That Network Traffic Is Authenticated Do not change the rules for any of your zones to require authentication until all of the zones have been set up and are operating correctly. Checklist: Creating isolated domain IPsec rules for computers running Windows XP, Windows Server 2003, or Windows 2000 Note The GPOs for computers that run Windows Server 2003, Windows XP, and Windows 2000 are typically similar. If this is true for your design, create one GPO, configure it by using the tasks in this checklist, and then make a copy of it for the other operating systems. For example, create and configure the GPO for Windows XP, create a copy of it for Windows Server 2003, and then follow the steps in this checklist to make the few required changes to the copy. Task Create a GPO for the computers in the isolated domain running one of the operating systems. After you have finished the tasks in this checklist and configured the GPO for that version of Windows, you can create a copy of it. If you are working on a GPO that Reference Create a Group Policy Object Copy a GPO to Create a New GPO Modify GPO Filters to Apply 135

136 Task was copied from another GPO, modify the group memberships and WMI filters so that they are correct for the isolated domain zone and the version of Windows for which this GPO is intended. Add registry settings that optimize IPsec behavior to the GPO. Create a new IP Security policy in the GPO. Configure the key exchange (main mode) security methods and algorithms to be used. Create IP filter lists for ICMP traffic, the exemption list, and all inbound IP traffic. Create filter actions to allow traffic, request authentication, require authentication, and require both authentication and encryption. Create the IPsec rules that combine the filter lists and filter actions. For the main zone in the isolated domain, you create rules that use the allow filter action with the exemption and ICMP filter lists and another rule that uses the request authentication filter action with the all IP traffic filter list. Assign the IPsec policy for the isolated domain to your GPO. Reference to a Different Zone or Version of Windows Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows Create a New IP Security Policy in a GPO for Earlier Versions of Windows Configure Key Exchange (Main Mode) Settings on Earlier Versions of Windows Create Filter Lists for Isolated Domain Computers and Isolated Servers Running Earlier Versions of Windows Create Filter Actions on Earlier Versions of Windows Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows Assign an IPsec Policy to a GPO for Earlier Versions of Windows 136

137 Task Link the GPO to the domain level of the AD DS organizational unit hierarchy. Add your test computers to the membership group for the isolated domain. Be sure to add at least one for each operating system supported by a different GPO in the group. Verify that the connection security rules are correctly protecting your network traffic. Reference Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Verify That Network Traffic Is Authenticated Do not change the rules for any of your zones to require authentication until all of the zones have been set up and are operating correctly. Checklist: Configuring Rules for the Boundary Zone The following checklists include tasks for configuring connection security rules and IPsec settings in your GPOs to implement the boundary zone in an isolated domain. The way in which you configure these rules and settings depends on whether the computers to which the GPO applies are running Windows Vista or Windows Server 2008 or an earlier version of the Windows operating system. Rules for the boundary zone are typically the same as those for the isolated domain, with the exception that the final rule is left to only request, not require, authentication. In this topic: Checklist for Windows Vista and Windows Server 2008 Checklist for Windows XP, Windows Server 2003, and Windows 2000 Checklist: Configuring boundary zone rules for computers running Windows Vista or Windows Server 2008 A GPO for Windows Vista or Windows Server 2008 can simply be copied and then customized. This checklist assumes that you have already created the GPO for the isolated domain as described in Checklist: Implementing a Domain Isolation Policy Design. After you create a copy for the boundary zone, make sure that you do not change the rule from request authentication to require authentication when you create the other GPOs. 137

138 Task Make a copy of the domain isolation GPO for this version of Windows to serve as a starting point for the GPO for the boundary zone. Unlike the GPO for the main isolated domain zone, this copy is not changed after deployment to require authentication. If you are working on a copy of a GPO, modify the group memberships and WMI filters so that they are correct for the boundary zone and version of Windows for which this GPO is intended. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Add your test computers to the membership group for the boundary zone. Be sure to add at least one for each operating system supported by a different GPO in the group. Verify that the connection security configuration is protecting network traffic with authentication when it can, and that unauthenticated traffic is accepted. Reference Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Verify That Network Traffic Is Authenticated Checklist: Creating boundary zone rules for computers running Windows XP, Windows Server 2003, or Windows 2000 This checklist assumes that you have already created the IPsec policy for the isolated domain as described in Checklist: Implementing a Domain Isolation Policy Design. The key exchange 138

139 settings, filter lists, and filter actions that you defined in that section can be reused in the GPO for the boundary zone. Task Make a copy of the domain isolation GPO for this version of Windows to serve as a starting point for the GPO for the boundary zone. If you are working on a copy of a GPO, modify the group memberships and WMI filters so that they are correct for the boundary zone and version of Windows for which this GPO is intended. Create a new IP Security policy in the GPO to contain the boundary zone settings. Combine the relevant filter lists and filter actions into IPsec rules to implement the boundary zone. For the boundary zone, use the request authentication filter action. Assign the boundary zone IPsec policy to your GPO. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Add your test computers to the membership group for the boundary zone. Be sure to add at least one for each operating system supported by a different GPO in the group. Verify that the IPsec policy is protecting network traffic with Reference Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Create a New IP Security Policy in a GPO for Earlier Versions of Windows Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows Assign an IPsec Policy to a GPO for Earlier Versions of Windows Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Verify That Network Traffic Is Authenticated 139

140 Task authentication when it can, and that unauthenticated traffic is accepted. Reference In the boundary zone, do not change the rule to require authentication when you change the GPOs for the other zones. Checklist: Configuring Rules for the Encryption Zone This checklist includes tasks for configuring connection security rules and IPsec settings in your GPOs to implement the encryption zone in an isolated domain. The way in which you configure these rules and settings depends on whether the computers to which the GPO applies are running Windows Vista or Windows Server 2008 or an earlier version of the Windows operating system. Rules for the encryption zone are typically the same as those for the isolated domain, with the exception that the main rule requires encryption in addition to authentication. Checklist: Configuring encryption zone rules for Windows Vista or Windows Server 2008 A GPO for Windows Vista or Windows Server 2008 can simply be copied and then customized. This checklist assumes that you have already created the GPO for the isolated domain as described in Checklist: Implementing a Domain Isolation Policy Design. You can then copy those GPOs for use with the encryption zone. After you create the copies, modify the main rule to require encryption in addition to the authentication required by the rest of the isolated domain. Task Make a copy of the domain isolation GPOs to serve as a starting point for the GPOs for the encryption zone. Modify the group memberships and WMI filters so that they are correct for the encryption zone and the version of Windows for which this GPO is intended. Add the encryption requirements for the zone. Link the GPO to the domain level of the Active Directory Reference Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Configure the Rules to Require Encryption on Windows Vista and Windows Server 2008 Link the GPO to the Domain 140

141 Task organizational unit hierarchy. Add your test computers to the membership group for the encryption zone. Be sure to add at least one for each operating system supported by a different GPO in the group. Verify that the connection security rules are protecting network traffic. Reference Add Test Computers to the Membership Group for a Zone Verify That Network Traffic Is Authenticated Checklist: Creating encryption zone rules for Windows XP, Windows Server 2003, or Windows 2000 A GPO for Windows XP, Windows Server 2003, or Windows 2000 can often simply be copied and then customized. This checklist assumes that you have already created the GPO for the isolated domain as described in Checklist: Implementing a Domain Isolation Policy Design. You can then make copies of those GPOs for use with the encryption zone. The key exchange settings, filter lists, and filter actions that you defined in that GPO can be reused in the GPO for the encryption zone. Task Make a copy of the domain isolation GPOs to serve as a starting point for the GPOs for the encryption zone. Modify the group memberships and WMI filters so that they are correct for the encryption zone and the version of Windows for which this GPO is intended. Create a new IP Security policy that can be assigned to the encryption zone GPO. Create the IPsec rules that combine the filter lists and filter actions. For the encryption zone, you reuse the filters and filter lists you created earlier for the Reference Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Create a New IP Security Policy in a GPO for Earlier Versions of Windows Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows 141

142 Task domain isolation and boundary zones and use the filter action that requires both authentication and encryption of traffic that is not exempt. Assign the IPsec policy for the encryption zone to your GPO. Add your test computers to the membership group for the encryption zone. Be sure to add at least one for each operating system supported by a different GPO in the group. Verify that the connection security rules are protecting network traffic. Reference Assign an IPsec Policy to a GPO for Earlier Versions of Windows Add Test Computers to the Membership Group for a Zone Verify That Network Traffic Is Authenticated Checklist: Configuring Rules for an Isolated Server Zone The following checklists include tasks for configuring connection security rules and IPsec settings in your GPOs for servers in an isolated server zone that are part of an isolated domain. For information about creating a standalone isolated server zone that is not part of an isolated domain, see Checklist: Implementing a Standalone Server Isolation Policy Design. In addition to requiring authentication and optionally encryption, servers in an isolated server zone can be accessed only by users or computers who are authenticated members of a network access group (NAG). Computers that are running Windows 2000, Windows XP, or Windows Server 2003 can restrict access in IPsec only to computers that are members of the NAG, because IPsec and IKE in those versions of Windows do not support user-based authentication. If you include user accounts in the NAG, then the restrictions can still apply; they are just enforced at the application layer, rather than the IP layer. Computers that are running Windows Vista and Windows Server 2008 can identify both computers and users in the NAG because IPsec in these versions of Windows supports AuthIP in addition to IKE. AuthIP adds support for user-based authentication. For more information, see AuthIP in Windows Vista ( The way in which you configure these rules and settings depends on whether the computers to which the GPO applies are running Windows Vista or Windows Server 2008 or an earlier version of Windows. 142

143 The GPOs for an isolated server or group of servers are similar to those for the isolated domain itself or the encryption zone, if you require encryption to your isolated servers. This checklist refers you to procedures for creating rules as well as restrictions that allow only members of the NAG to connect to the server. In this topic: Creating rules for Windows Vista and Windows Server 2008 Creating rules for Windows XP, Windows Server 2003, and Windows 2000 Checklist: Configuring rules for isolated servers for computers running Windows Vista or Windows Server 2008 Note The GPOs for computers running Windows Vista and Windows Server 2008 are usually similar. If this is true for your design, create one GPO, configure it by using the tasks in this checklist, and then make a copy of the GPO for the other operating system. For example, create and configure the GPO for Windows Vista, make a copy of it for Windows Server 2008, and then follow the steps in this checklist to make the few required changes to the copy. Task Create a GPO for the computers that need to have access restricted to the same set of client computers. If there are multiple servers and they run different versions of the Windows operating system, then start by creating the GPO for one version of Windows. After you have finished the tasks in this checklist and configured the GPO for that version of Windows, you can create a copy of it. Copy the GPO from the isolated domain or from the encryption zone to serve as a starting point. Where your copy already contains elements listed in the following checklist, review the relevant procedures and compare them to your copied GPO s element to make Reference Copy a GPO to Create a New GPO 143

144 Task sure it is constructed in a way that meets the needs of the server isolation zone. Configure the security group filters and WMI filters on the GPO so that only members of the isolated server zone s membership group that are running the specified version of Windows can read and apply it. Configure IPsec to exempt all ICMP network traffic from IPsec protection. Configure the key exchange (main mode) security methods and algorithms to be used. Configure the data protection (quick mode) algorithm combinations to be used. If you require encryption for the isolated server zone, then make sure that you choose only algorithm combinations that include encryption. Configure the authentication methods to be used. Create a rule that exempts all network traffic to and from computers on the exemption list from IPsec. Create a rule that requests authentication for all network traffic. Important Just as in an isolated domain, do not set the rules to require authentication for inbound traffic until you Reference Modify GPO Filters to Apply to a Different Zone or Version of Windows Exempt ICMP from Authentication on Windows Vista and Windows Server 2008 Configure Key Exchange (Main Mode) Settings on Windows Vista and Windows Server 2008 Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server 2008 Configure Authentication Methods on Windows Vista and Windows Server 2008 Create an Authentication Exemption List Rule on Windows Vista and Windows Server 2008 Create an Authentication Request Rule on Windows Vista and Windows Server

145 Task have completed testing. That way, if the rules do not work as expected, communications are not affected by a failure to authenticate. Create the NAG to contain the computer or user accounts that are allowed to access the servers in the isolated server zone. Create a firewall rule that permits inbound network traffic only if authenticated as a member of the NAG. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Add your test server to the membership group for the isolated server zone. Be sure to add at least one server for each operating system supported by a GPO in the group. Reference Create a Group Account in Active Directory Restrict Server Access to Members of a Group Only Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Do not change the rules for any of your zones to require authentication until all of the zones have been set up and are operating correctly. Checklist: Creating rules for isolated servers for computers running Windows XP, Windows Server 2003, or Windows 2000 Note The GPOs for computers running Windows Server 2003, Windows XP, and Windows 2000 are usually similar. If this is true for your design, create one GPO, configure it by using the tasks in this checklist, and then create a copy. For example, create and configure the GPO for Windows XP, create a copy of it for Windows Server 2003, and then follow the steps in this checklist to make the few required changes to the copy. 145

146 Task Create a GPO for the computers that need to have access restricted to the same set of client computers. If there are multiple servers and they run different versions of the Windows operating system, then start by creating the GPO for one version of Windows. After you have finished the tasks in this checklist and configured the GPO for that version of Windows, you can create a copy of it. Copy the GPO from the isolated domain or from the encryption zone to serve as a starting point. Where your copy already contains elements listed in the following checklist, review the relevant procedures and compare them to your copied GPO s element to ensure that it is constructed in a way that meets the needs of the server isolation zone. Configure the security group filters and WMI filters on the GPO so that only members of the isolated server zone s membership group that are running the specified version of Windows can read and apply it. Add registry settings that optimize IPsec behavior to the GPO. Create a new IP Security policy in the GPO. Important If IPsec policies exist, do Reference Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows Create a New IP Security Policy in a GPO for Earlier Versions of Windows 146

147 Task not modify them. They are links to the IPsec policies available to all GPOs. Changes made to one will affect all GPOs that use that IPsec policy. Configure the key exchange (main mode) security methods and algorithms to be used. Create IP filter lists for ICMP traffic, the exemption list, and all other inbound IP traffic. Create filter actions to allow traffic, request authentication, and require authentication and, optionally, encryption. Combine the filter lists and filter actions into the rules required for an isolated server zone. Assign the IPsec policy to your GPO. Grant the Access this computer from the network user right to only computers or users who are authenticated members of the NAG. Add your test computers to the membership group for the isolated server zone. Be sure to add at least one server for each operating system supported by a GPO in the group. Verify that the IPsec rules are protecting your network traffic. Reference Configure Key Exchange (Main Mode) Settings on Earlier Versions of Windows Create Filter Lists for Isolated Domain Computers and Isolated Servers Running Earlier Versions of Windows Create Filter Actions on Earlier Versions of Windows Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows Assign an IPsec Policy to a GPO for Earlier Versions of Windows Restrict Server Access to Members of a Group Only Add Test Computers to the Membership Group for a Zone Verify That Network Traffic Is Authenticated 147

148 Do not change the rules for any of your zones to require authentication until all of the zones have been configured and are operating correctly. Now follow the steps in Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone. When you have finished the tasks in that checklist, you should have at least one computer in the client membership group that you can use to test your ability to connect to servers in the isolated server zone. Checklist: Implementing a Standalone Server Isolation Policy Design This checklist contains procedures for creating a server isolation policy design that is not part of an isolated domain. For the steps required to create an isolated server zone within an isolated domain, see Checklist: Configuring Rules for an Isolated Server Zone. This parent checklist includes cross-reference links to important concepts about the domain isolation policy design. It also contains links to subordinate checklists that will help you complete the tasks that are required to implement this design. Notes Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist. The procedures in this section use the Group Policy MMC snap-in interfaces to configure the GPOs, but you can also use the Netsh command-line tool. For more information, see Use Netsh to Configure GPOs. Checklist: Implementing a standalone server isolation policy design Task Review important concepts and examples for the server isolation policy design to determine if this design meets your deployment goals and the needs of your organization. Create the GPOs and connection security rules for isolated servers. Create the GPOs and connection security rules for the Reference Identifying Your Windows Firewall with Advanced Security Deployment Goals Server Isolation Policy Design Server Isolation Policy Design Example Planning Server Isolation Zones Checklist: Configuring Rules for Servers in a Standalone Isolated Server Zone Checklist: Creating Rules for Clients of a Standalone Isolated 148

149 Task client computers that must connect to the isolated servers. Verify that the connection security rules are protecting network traffic on your test computers. After you confirm that network traffic is authenticated by IPsec as expected, you can change authentication rules for the isolated server zone to require authentication instead of requesting it. According to the testing and rollout schedule in your design plan, add computer accounts for the client computers to the membership group so that you can deploy the settings. Reference Server Zone Verify That Network Traffic Is Authenticated Change Rules from Request to Require Mode Add Production Computers to the Membership Group for a Zone Checklist: Configuring Rules for Servers in a Standalone Isolated Server Zone This checklist includes tasks for configuring connection security rules and IPsec settings in your GPOs for servers in a standalone isolated server zone that is not part of an isolated domain. In addition to requiring authentication and optionally encryption, servers in a server isolation zone are accessible only by users or computers that are authenticated as members of a network access group (NAG). The GPOs described here apply only to the isolated servers, not to the client computers that connect to them. For the GPOs for the client computers, see Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone. Computers that are running Windows 2000, Windows XP, or Windows Server 2003 can restrict access only to computers that are members of the NAG because IPsec and IKE in those versions of Windows do not support user-based authentication. Computers that are running Windows Vista and Windows Server 2008 can identify both computers and users in the NAG because those versions of IPsec support AuthIP in addition to IKE. AuthIP adds support for user-based authentication. The way in which these rules and settings are configured depends on whether the computers to which the GPO applies are running Windows Vista or Windows Server 2008 or an earlier version of Windows. 149

150 The GPOs for isolated servers are similar to those for an isolated domain. This checklist refers you to those procedures for the creation of some of the rules. The other procedures in this checklist are for creating the restrictions that allow only members of the server access group to connect to the server. In this topic: Creating rules for Windows Vista and Windows Server 2008 Creating rules for Windows XP, Windows Server 2003, and Windows 2000 Checklist: Configuring rules for isolated servers running Windows Vista or Windows Server 2008 Note The GPOs for computers running Windows Vista and Windows Server 2008 are usually similar. If this is true for your design, create one GPO, configure it by using the tasks in this checklist, and then create a copy of the GPO for the other operating system. For example, create and configure the GPO for Windows Vista, make a copy of it for Windows Server 2008, and then follow the steps in this checklist to make the few required changes to the copy. Task Create a GPO for the computers that need to have access restricted to the same set of client computers. If there are multiple servers running different versions of the Windows operating system, start by creating the GPO for one version of Windows. After you have finished the tasks in this checklist and configured the GPO for that version of Windows, you can create a copy of it. If you are working on a copy of a GPO, modify the group memberships and WMI filters so that they are correct for the computers for which this GPO is intended. Configure IPsec to exempt all ICMP network traffic from IPsec Reference Checklist: Creating Group Policy Objects Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Exempt ICMP from Authentication on Windows 150

151 Task protection. Create a rule that exempts all network traffic to and from computers on the exemption list from IPsec. Configure the key exchange (main mode) security methods and algorithms to be used. Configure the data protection (quick mode) algorithm combinations to be used. Configure the authentication methods to be used. This procedure sets the default settings for the computer. If you want to set authentication on a per-rule basis, this procedure is optional. Create a rule that requests authentication for all inbound network traffic. Important Just as in an isolated domain, do not set the rules to require authentication until your testing is complete. That way, if the rules do not work as expected, communications are not affected by a failure to authenticate. If your design requires encryption in addition to authentication for access to the isolated servers, then modify the rule to require it. Reference Vista and Windows Server 2008 Create an Authentication Exemption List Rule on Windows Vista and Windows Server 2008 Configure Key Exchange (Main Mode) Settings on Windows Vista and Windows Server 2008 Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server 2008 Configure Authentication Methods on Windows Vista and Windows Server 2008 Create an Authentication Request Rule on Windows Vista and Windows Server 2008 Configure the Rules to Require Encryption on Windows Vista and Windows Server

152 Task Create the NAG to contain the computer or user accounts that are allowed to access the isolated servers. If you have multiple groups of isolated servers that are accessed by different client computers, then create a NAG for each set of servers. Create a firewall rule that allows inbound network traffic only if it is authenticated from a user or computer that is a member of the zone s NAG. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Add your test server to the membership group for the isolated server zone. Be sure to add at least one for each operating system supported by a different GPO in the group. Reference Create a Group Account in Active Directory Restrict Server Access to Members of a Group Only Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Do not change the rules for any of your zones to require authentication until all zones have been set up and thoroughly tested. Checklist: Creating rules for isolated servers running Windows XP, Windows Server 2003, or Windows 2000 Note The GPOs for computers that run Windows Server 2003, Windows XP, and Windows 2000 are usually similar. If this is true for your design, create one GPO, configure it by using the tasks in this checklist, and then create a copy of the GPO. For example, create and configure the GPO for Windows XP, make a copy of it for Windows Server 2003, and then follow the steps in this checklist to make the few required changes to the copy. 152

153 Task Create a GPO for the computers that need to have access restricted to the same set of client computers. If there are multiple servers running different versions of the Windows operating system, start by creating the GPO for one version of Windows. After you have finished the tasks in this checklist, you can create a copy of it. If you are working on a copy of a GPO, modify the group memberships and WMI filters so that they are correct for the computers for which this GPO is intended. Add registry settings that optimize IPsec behavior to the GPO. Create a new IP Security policy in the GPO. Important If IPsec policies exist, do not modify them. They are links to the IPsec policies available to all GPOs. Changes made to one will affect all GPOs that use that IPsec policy. Configure the key exchange (main mode) security methods and algorithms to be used. Create IP filter lists for ICMP traffic, the exemption list, and all inbound IP traffic. Create filter actions to allow Reference Create a Group Policy Object Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows Create a New IP Security Policy in a GPO for Earlier Versions of Windows Configure Key Exchange (Main Mode) Settings on Earlier Versions of Windows Create Filter Lists for Isolated Domain Computers and Isolated Servers Running Earlier Versions of Windows Create Filter Actions on 153

154 Task traffic, request authentication, and require authentication. If you require both authentication and encryption in your isolated server zone, then also create a filter action for that behavior. Create the IPsec rules that combine the filter lists and filter actions. Assign the IPsec policy to your GPO. If you have not already done so, create the NAG to contain the computer or user accounts that are allowed to access the isolated servers. If you have multiple groups of isolated servers that are accessed by different client computers, then create a NAG for each set of servers. Grant the Access this computer from the network user right to only computers or users who are authenticated members of the NAG. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Add your test computers to the membership group for the isolated server zone. Be sure to add at least one for each operating system supported by a different GPO in the group. Verify that the IPsec rules are protecting your network traffic. Reference Earlier Versions of Windows Create IPsec Rules for an Isolated Server Zone on Earlier Versions of Windows Assign an IPsec Policy to a GPO for Earlier Versions of Windows Create a Group Account in Active Directory Restrict Server Access to Members of a Group Only Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone Verify That Network Traffic Is Authenticated 154

155 Do not change the rules for any of your zones to require authentication until all of the zones have been configured and thoroughly tested. At this point, you can follow the steps in Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone. When you have completed the tasks in that checklist, you should have at least one computer in the client NAG that you can use to test your ability to connect to servers in the isolated server zone. Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone This checklist includes tasks for configuring connection security rules and IPsec settings in the GPOs for client computers that must connect to servers in an isolated server zone. The way in which these rules and settings are configured depends on whether the computers to which the GPO applies are running Windows Vista or Windows Server 2008 or an earlier version of the Windows operating system. In this topic: Checklist for Windows Vista and Windows Server 2008 Checklist for Windows XP, Windows Server 2003, and Windows 2000 Checklist: Configuring isolated server zone client rules for computers running Windows Vista or Windows Server 2008 Note The GPOs for computers running Windows Vista and Windows Server 2008 are usually similar. If this is true for your design, create one GPO, configure it by using the tasks in this checklist, and then create a copy of the GPO. For example, create and configure the GPO for Windows Vista, create a copy of it for Windows Server 2008, and then follow the steps in this checklist to make the required changes (if any) to the copy. Task Create a GPO for the client computers that must connect to servers in the isolated server zone, and that are running one of the versions of Windows. After you have finished the tasks in this checklist, you can make a copy of it. To determine which computers receive the GPO, assign the Reference Checklist: Creating Group Policy Objects Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of 155

156 Task NAG for the isolated servers to the security group filter for the GPO. Make sure that each GPO has the WMI filter for the correct version of Windows. Configure IPsec to exempt all ICMP network traffic from IPsec protection. Create a rule that exempts all network traffic to and from computers on the exemption list from IPsec. Configure the key exchange (main mode) security methods and algorithms to be used. Configure the data protection (quick mode) algorithm combinations to be used. Configure the authentication methods to be used. Create a rule that requests authentication for network traffic. Because fallback-to-clear behavior in Windows Vista and Windows Server 2008 has no delay when communicating with computers that cannot use IPsec, you can use the same any-to-any rule used in an isolated domain. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Add your test computers to the NAG for the isolated server Reference Windows Exempt ICMP from Authentication on Windows Vista and Windows Server 2008 Create an Authentication Exemption List Rule on Windows Vista and Windows Server 2008 Configure Key Exchange (Main Mode) Settings on Windows Vista and Windows Server 2008 Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server 2008 Configure Authentication Methods on Windows Vista and Windows Server 2008 Create an Authentication Request Rule on Windows Vista and Windows Server 2008 Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone 156

157 Task zone. Be sure to add at least one for each operating system supported by a different GPO in the group. Reference Checklist: Configuring isolated server zone client rules for computers running Windows XP, Windows Server 2003, or Windows 2000 Note The GPOs for computers that run Windows Server 2003, Windows XP, and Windows 2000 are usually similar. If this is true for your design, create one GPO, configure it by using the tasks in this checklist, and then make a copy of the GPO to capture all of the settings. For example, create and configure the GPO for Windows XP, create a copy of it for Windows Server 2003, and then follow the steps in this checklist to make the few required changes to the copy. Task Create a GPO for the client computers that must connect to servers in the isolated server zone, and that are running one of the versions of Windows. After you have finished the tasks in this checklist and configured the GPO for one version of Windows, you can create a copy of it. To determine which computers receive the GPO, assign the NAG for the isolated servers to the security group filter for the GPO. To determine which computers receive the GPO, assign the NAG for the isolated servers to the security group filter for the GPO. Make sure that each GPO has the WMI filter for the correct version of Windows. Reference Create a Group Policy Object Copy a GPO to Create a New GPO Modify GPO Filters to Apply to a Different Zone or Version of Windows 157

158 Task Add registry settings that optimize IPsec behavior to the GPO. Create a new IP Security policy in the GPO. Configure the key exchange (main mode) security methods and algorithms to be used. Create IP filter lists for ICMP traffic, the exemption list, and all other IP traffic. This filter list is potentially different from the filter list for an isolated domain. Create filter actions to allow traffic and request authentication. If the isolated servers require encryption, make sure that you include the appropriate encryption algorithms in the data protection (quick mode) settings of the request filter action. Combine the filter lists and filter actions into the required IPsec rules. Assign the IPsec policy for the isolated domain to your GPO. Link the GPO to the domain level of the Active Directory organizational unit hierarchy. Add your test computers to the membership group for the isolated domain. Be sure to add at least one for each operating system supported by a different Reference Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows Create a New IP Security Policy in a GPO for Earlier Versions of Windows Configure Key Exchange (Main Mode) Settings on Earlier Versions of Windows Create Filter Lists for Clients of Isolated Server Running Earlier Versions of Windows Create Filter Actions on Earlier Versions of Windows Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows Assign an IPsec Policy to a GPO for Earlier Versions of Windows Link the GPO to the Domain Add Test Computers to the Membership Group for a Zone 158

159 Task GPO in the group. Verify that the connection security rules are protecting your network traffic. Reference Verify That Network Traffic Is Authenticated Do not change the rules for any of your zones to require authentication until all of the zones have been set up and thoroughly tested. Checklist: Implementing a Certificate-based Isolation Policy Design This parent checklist includes cross-reference links to important concepts about using certificates as an authentication option in either a domain isolation or server isolation design. Notes Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist The procedures in this section use the Group Policy MMC snap-in interfaces for configuring the GPOs, but you can also use the Netsh command-line tool to configure GPOs. For more information, see Use Netsh to Configure GPOs. Checklist: Implementing certificate-based authentication Task Review important concepts and examples for certificate-based authentication to determine if this design meets your deployment goals and the needs of your organization. Install the Active Directory Certificate Services (AD CS) role as an enterprise root issuing certification authority (CA). This step is required only if you have Reference Identifying Your Windows Firewall with Advanced Security Deployment Goals Certificate-based Isolation Policy Design Certificate-based Isolation Policy Design Example Planning Certificate-based Authentication Install Active Directory Certificate Services 159

160 Task not already deployed a CA on your network. Configure the certificate template for workstation authentication certificates. Configure Group Policy to automatically deploy certificates based on your template to workstation computers. On a test computer, refresh Group Policy and confirm that the certificate is installed. Reference Configure the Workstation Authentication Certificate Template Configure Group Policy to Autoenroll and Deploy Certificates Confirm That Certificates Are Deployed Correctly Procedures Used in This Guide The procedures in this section appear in the checklists found earlier in this document. They should be used only in the context of the checklists in which they appear. They are presented here in alphabetical order. Add Authentication Methods to an IPsec Rule on Earlier Versions of Windows Add Production Computers to the Membership Group for a Zone Add Test Computers to the Membership Group for a Zone Assign an IPsec Policy to a GPO for Earlier Versions of Windows Assign Security Group Filters to the GPO Change Rules from Request to Require Mode Configure Authentication Methods on Windows Vista and Windows Server 2008 Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server 2008 Configure Group Policy to Autoenroll and Deploy Certificates Configure Key Exchange (Main Mode) Settings on Earlier Versions of Windows Configure Key Exchange (Main Mode) Settings on Windows Vista and Windows Server 2008 Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows Configure the Rules to Require Encryption on Windows Vista and Windows Server 2008 Configure the Windows Firewall Log Configure the Workstation Authentication Certificate Template Configure Windows Firewall to Suppress Notifications When a Program Is Blocked Confirm That Certificates Are Deployed Correctly 160

161 Copy a GPO to Create a New GPO Create a Group Account in Active Directory Create a Group Policy Object Create a New IP Security Policy in a GPO for Earlier Versions of Windows Create an Authentication Exemption List Rule on Windows Vista and Windows Server 2008 Create an Authentication Request Rule on Windows Vista and Windows Server 2008 Create an Inbound ICMP Rule on Windows Vista or Windows Server 2008 Create an Inbound Port Rule on Windows Vista or Windows Server 2008 Create an Inbound Port Rule on Windows XP or Windows Server 2003 Create an Inbound Program or Service Rule on Windows Vista or Windows Server 2008 Create an Inbound Program Rule on Windows XP or Windows Server 2003 Create an Outbound Port Rule on Windows Vista or Windows Server 2008 Create an Outbound Program or Service Rule on Windows Vista or Windows Server 2008 Create Filter Actions on Earlier Versions of Windows Create Filter Lists for Clients of Isolated Server Running Earlier Versions of Windows Create Filter Lists for Isolated Domain Computers and Isolated Servers Running Earlier Versions of Windows Create Inbound Rules to Support RPC on Windows Vista or Windows Server 2008 Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows Create IPsec Rules for an Isolated Server Zone on Earlier Versions of Windows Create IPsec Rules for Clients of an Isolated Server Zone on Earlier Versions of Windows Create WMI Filters for the GPO Enable Predefined Inbound Rules on Windows Vista or Windows Server 2008 Enable Predefined Inbound Rules on Windows XP or Windows Server 2003 Enable Predefined Outbound Rules on Windows Vista or Windows Server 2008 Exempt ICMP from Authentication on Windows Vista and Windows Server 2008 Install Active Directory Certificate Services Link the GPO to the Domain Modify GPO Filters to Apply to a Different Zone or Version of Windows Open the Group Policy Management Console to IP Security Policies Open the Group Policy Management Console to Windows Firewall Open the Group Policy Management Console to Windows Firewall with Advanced Security Open Windows Firewall with Advanced Security Restrict Server Access to Members of a Group Only Start a Command Line as an Administrator Turn on Windows Firewall and Configure Default Behavior 161

162 Use Netsh to Configure GPOs Verify That Network Traffic Is Authenticated Add Authentication Methods to an IPsec Rule on Earlier Versions of Windows You can add a single authentication method to an IPsec rule from the Authentication Method page of the Security Rule Wizard. If your design calls for more than one authentication method, follow the steps in the wizard to add the first, and then follow these steps to add the others. This procedure assumes that you have just finished creating the rule by using the wizard, and the list of rules in the IPsec policy is still on the display. To add additional authentication methods to an IPsec rule 1. Click the rule to which you want to add authentication methods, and then click Edit. 2. On the rule Properties dialog box, select the Authentication Methods tab. 3. Click Add. 4. Configure your second authentication method. For example, if you want to add certificatebased authentication so that your computers can interoperate with computers running operating systems other than Windows: a. Select Use a certificate from this certification authority (CA). b. Click Browse. c. Select the appropriate CA from the list, and then click OK. Important You must distribute a copy of a certificate issued by the selected CA to all computers that must be able to use this IPsec rule. You can use X.509 version 3 certificates generated either by a CA server operated by your organization or purchased from a commercial certification authority. Only root certificates can be used; certificates from intermediate CAs do not work. For more information, see Checklist: Implementing a Certificate-based Isolation Policy Design in this guide. 5. Click OK on each dialog box to return to the Group Policy Management Editor. Add Production Computers to the Membership Group for a Zone After you test the GPOs for your design on a small set of computers, you can deploy them to the production computers. Caution For GPOs that contain connection security rules that prevent unauthenticated connections, be sure to set the rules to request, not require, authentication during testing. 162

163 After you deploy the GPO and confirm that all of your computers are successfully communicating by using authenticated IPsec, then you can modify the GPO to require authentication. Do not change the boundary zone GPO to require mode. The method discussed in this guide uses the Domain Computers built-in group. The advantage of this method is that all new computers that are joined to the domain automatically receive the isolated domain GPO. To do this successfully, you must make sure that the WMI filters and security group filters exclude computers that must not receive the GPOs. Use computer groups that deny both read and apply Group Policy permissions to the GPOs, such as a group used in the CG_DOMISO_NOIPSEC example design. Computers that are members of some zones must also be excluded from applying the GPOs for the main isolated domain. For more information, see the "Prevent members of a group from applying a GPO" section in Assign Security Group Filters to the GPO. Without such a group (or groups), you must either add computers individually or use the groups containing computer accounts that are available to you. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the membership of the group for the GPO. In this topic: Add the group Domain Computers to the GPO membership group Refresh Group Policy on the computers in the membership group Check which GPOs apply to a computer To add domain computers to the GPO membership group 1. On a computer that has the Active Directory management tools installed, click Start, click Administrative tools, and then click Active Directory Users and Computers. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Active Directory Users and Computers, expand YourDomainName, and then the container in which you created the membership group. 4. In the details pane, double-click the GPO membership group to which you want to add computers. 5. Select the Members tab, and then click Add. 6. Type Domain Computers in the text box, and then click OK. 7. Click OK to close the group properties dialog box. After a computer is a member of the group, you can force a Group Policy refresh on the computer. 163

164 To refresh Group Policy on a computer For a computer that is running Windows Vista or Windows Server 2008, start a command prompt as an administratorstart a command prompt as an administrator, and then type the following command: gpupdate /target:computer /force For a computer that is running Windows XP or Windows Server 2003, start a command prompt, and then type the following command: gpupdate /target:computer /force For a computer that is running Windows 2000, start a command prompt, and then type the following command: secedit /refreshpolicy machine_policy After Group Policy is refreshed, you can see which GPOs are currently applied to the computer. To see which GPOs are applied to a computer For a computer that is running Windows Vista or Windows Server 2008, start a command prompt as an administratorstart a Command Line as an Administrator, and then type the following command: gpresult /r /scope:computer For a computer that is running Windows XP or Windows Server 2003, start a command prompt, and then type the following command: gpresult /scope:computer For a computer that is running Windows 2000, start a command prompt, and then type the following command: gpresult /c Add Test Computers to the Membership Group for a Zone Before you deploy your rules to large numbers of computers, you must thoroughly test the rules to make sure that communications are working as expected. A misplaced WMI filter or an incorrectly typed IP address in a filter list can easily block communications between computers. Although we recommend that you set your rules to request mode until testing and deployment is complete, we also recommend that you initially deploy the rules to a small number of computers only to be sure that the correct GPOs are being processed by each computer. 164

165 Add at least one computer of each supported operating system type to each membership group. Make sure every GPO for a specific version of Windows and membership group has a computer among the test group. After Group Policy has been refreshed on each test computer, check the output of the gpresult command to confirm that each computer is receiving only the GPOs it is supposed to receive. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the membership of the group for the GPO. In this topic: Add the test computers to the GPO membership groups Refresh Group Policy on the computers in each membership group Check which GPOs apply to a computer To add test computers to the GPO membership groups 1. On a computer that has the Active Directory management tools installed, click Start, click Administrative Tools, and then click Active Directory Users and Computers. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Active Directory Users and Computers, expand YourDomainName, and then expand the container that holds your membership group account. 4. In the details pane, double-click the GPO membership group to which you want to add computers. 5. Select the Members tab, and then click Add. 6. Type the name of the computer in the text box, and then click OK. 7. Repeat steps 5 and 6 for each additional computer account or group that you want to add. 8. Click OK to close the group properties dialog box. After a computer is a member of the group, you can force a Group Policy refresh on the computer. To refresh Group Policy on a computer For a computer that is running Windows Vista or Windows Server 2008, start a command prompt as an administratorstart a Command Line as an Administrator, and then type the following command: 165

166 gpupdate /target:computer /force For a computer that is running Windows XP or Windows Server 2003, open a command prompt, and then type the following command: gpupdate /target:computer /force For a computer that is running Windows 2000, open a command prompt, and then type the following command: secedit /refreshpolicy machine_policy After Group Policy is refreshed, you can see which GPOs are currently applied to the computer. To see which GPOs are applied to a computer For a computer that is running Windows Vista or Windows Server 2008, start a command prompt as an administratorstart a Command Line as an Administrator, and then type the following command: gpresult /r /scope:computer For a computer that is running Windows XP or Windows Server 2003, open a command prompt, and then type the following command: gpresult /scope:computer For a computer that is running Windows 2000, open a command prompt, and then type the following command: gpresult /c Assign an IPsec Policy to a GPO for Earlier Versions of Windows After creating all of the rules required in an IPsec policy, you must assign the policy in the GPO to make it apply to the computers that receive the GPO. Administrative credentials To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To assign an IPsec policy to the GPO 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, right-click the domain isolation policy that you created earlier, and then click Assign. 166

167 Caution Make sure that you assign an IPsec policy only to the GPO or GPOs that will apply those settings to the correct client and server computers. If you assign the policy to the wrong GPOs, then network communications will not be protected as expected, and might fail. Important Only one IPsec policy can be active on a computer at a time. The Group Policy Management Editor allows you to specify only one active IPsec policy in a GPO, but if multiple GPOs with IPsec policies apply to a computer, then the IPsec policy that applies to the computer depends on the precedence of the GPOs and the order in which they are applied. For more information, see Group Policy Processing and Precedence ( If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Assign Security Group Filters to the GPO To make sure that your GPO is applied to the correct computers, use the Group Policy Management MMC snap-in to assign security group filters to the GPO. Important This deployment guide uses the method of adding the Domain Computers group to the membership group for the main isolated domain after testing is complete and you are ready to go live in production. To make this method work, you must prevent any computer that is a member of either the boundary or encryption zone from applying the GPO for the main isolated domain. For example, on the GPOs for the main isolated domain, deny Read and Apply Group Policy permissions to the membership groups for the boundary and encryption zones. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the relevant GPOs. In this topic: Allow members of a group to apply a GPO Prevent members of a group from applying a GPO Use the following procedure to add a group to the security filter on the GPO that allows group members to apply the GPO. 167

168 To allow members of a group to apply a GPO 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, find and then click the GPO that you want to modify. 4. In the details pane, under Security Filtering, click Authenticated Users, and then click Remove. Note 5. Click Add. You must remove the default permission granted to all authenticated users and computers to restrict the GPO to only the groups you specify. 6. In the Select User, Computer, or Group dialog box, type the name of the group whose members are to apply the GPO, and then click OK. If you do not know the name, you can click Advanced to browse the list of groups available in the domain. Use the following procedure to add a group to the security filter on the GPO that prevents group members from applying the GPO. This is typically used to prevent computers that are running Windows 2000 from applying a GPO, because Windows 2000 does not support WMI filters. It is also used to prevent members of the boundary and encryption zones from applying the GPOs for the isolated domain. To prevent members of group from applying a GPO 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, find and then click the GPO that you want to modify. 4. In the details pane, click the Delegation tab. 5. Click Advanced. 6. Under the Group or user names list, click Add. 7. In the Select User, Computer, or Group dialog box, type the name of the group whose members are to be prevented from applying the GPO, and then click OK. If you do not know the name, you can click Advanced to browse the list of groups available in the domain. 8. Select the group in the Group or user names list, and then select the box in the Deny column for both Read and Apply group policy. 168

169 9. Click OK, and then in the Windows Security dialog box, click Yes. 10. The group appears in the list with Custom permissions. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Change Rules from Request to Require Mode After you confirm that network traffic is being correctly protected by using IPsec, you can change the rules for the domain isolation and encryption zones to require, instead of request, authentication. Do not change the rules for the boundary zone; they must stay in request mode so that computers in the boundary zone can continue to accept connections from computers that are not part of the isolated domain. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. In this topic: Convert a rule in a GPO for Windows Vista or Windows Server 2008 Convert a rule for an earlier version of Windows Refresh policy on the client computers to receive the modified GPOs To convert a rule from request to require mode for Windows Vista or Windows Server Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Connection Security Rules. 3. In the details pane, double-click the connection security rule that you want to modify. 4. Click the Authentication tab. 5. In the Requirements section, change Authenticated mode to Require inbound and request outbound, and then click OK. To convert a rule from request to require mode for Windows XP, Windows Server 2003, or Windows Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the domain isolation policy that you created earlier. 3. Find the rule that requests authentication for all IP traffic except ICMP and the exemption 169

170 list. Select the rule, but do not clear the check box, and then click Edit. 4. In the Edit Rule Properties dialog box, select the Filter Action tab. 5. Select Require Authentication or Require Authentication and Encryption as required by your design, and then click OK twice to save your changes. 6. Either manually refresh Group Policy on your client computers, or wait for automatic GPO refresh. The only change you should see to your network traffic is that unauthenticated network connections are now rejected instead of being allowed to continue in clear text. To apply the modified GPOs to the client computers 1. The next time each computer refreshes its Group Policy, it will receive the updated GPO and apply the modified rule. You can force an immediate refresh by starting a command prompt as an administratorstart a Command Line as an Administrator and running one of the following commands: On computers that are running Windows XP or later, run the following command: gpupdate /force On computers that are running Windows 2000, run the following command: secedit /refreshpolicy machine_policy /enforce 2. To verify that the modified GPO is correctly applied to the client computers, you can run one of the following commands: On computers that are running Windows Vista or Windows Server 2008 or later, run the following command: gpresult /r /scope computer On computers that are running Windows XP or Windows Server 2003, run the following command: gpresult /scope computer On computers that are running Windows 2000, run the following command: gpresult /C 3. Examine the command output for the list of GPOs that are applied to the computer, and make sure that the list contains the GPOs you expect to see on that computer. Configure Authentication Methods on Windows Vista and Windows Server 2008 This procedure shows you how to configure the authentication methods that can be used by computers in an isolated domain or standalone isolated server zone. 170

171 Note If you follow the steps in the procedure in this topic, you alter the system-wide default settings. Any connection security rule can use these settings by specifying Default on the Authentication tab. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To configure authentication methods 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the details pane on the main Windows Firewall with Advanced Security page, click Windows Firewall Properties. 3. On the IPsec Settings tab, click Customize. 4. In the Authentication Method section, select the type of authentication that you want to use from among the following: a. Default. Selecting this option tells the computer to use the authentication method currently defined by the local administrator in Windows Firewall with Advanced Security or by Group Policy as the default. b. Computer and User (using Kerberos V5). Selecting this option tells the computer to use and require authentication of both the computer and the currently logged-on user by using their domain credentials. This authentication method works only with other computers that can use Authenticated IP (AuthIP), including Windows Vista and Windows Server User-based authentication using Kerberos V5 is not supported by IKE v1. c. Computer (using Kerberos V5). Selecting this option tells the computer to use and require authentication of the computer by using its domain credentials. This option works with other computers that can use IKE v1, including earlier versions of Windows. d. User (using Kerberos V5). Selecting this option tells the computer to use and require authentication of the currently logged-on user by using his or her domain credentials. This authentication method works only with other computers that can use AuthIP, including Windows Vista and Windows Server User-based authentication using Kerberos V5 is not supported by IKE v1. e. Computer certificate from this certification authority. Selecting this option and entering the identification of a certification authority (CA) tells the computer to use and require authentication by using a certificate that is issued by the selected CA. If you also select Accept only health certificates, then only certificates that include the system health authentication enhanced key usage (EKU) typically provided in a Network Access Protection (NAP) infrastructure can be used for this rule. 171

172 f. Advanced. Click Customize to specify a custom combination of authentication methods required for your scenario. You can specify both a First authentication method and a Second authentication method. The first authentication method can be one of the following: Computer (Kerberos V5). Selecting this option tells the computer to use and require authentication of the computer by using its domain credentials. This option works with other computers that can use IKE v1, including earlier versions of Windows. Computer (NTLMv2). Selecting this option tells the computer to use and require authentication of the computer by using its domain credentials. This option works only with other computers that can use AuthIP, including Windows Vista and Windows Server User-based authentication using Kerberos V5 is not supported by IKE v1. Computer certificate from this certification authority (CA). Selecting this option and entering the identification of a CA tells the computer to use and require authentication by using a certificate that is issued by that CA. If you also select Accept only health certificates, then only certificates issued by a NAP server can be used. Preshared key (not recommended). Selecting this method and entering a preshared key tells the computer to authenticate by exchanging the preshared keys. If they match, then the authentication succeeds. This method is not recommended, and is included only for backward compatibility and testing purposes. If you select First authentication is optional, then the connection can succeed even if the authentication attempt specified in this column fails. The second authentication method can be one of the following: User (Kerberos V5). Selecting this option tells the computer to use and require authentication of the currently logged-on user by using his or her domain credentials. This authentication method works only with other computers that can use AuthIP, including Windows Vista and Windows Server User-based authentication using Kerberos V5 is not supported by IKE v1. User (NTLMv2). Selecting this option tells the computer to use and require authentication of the currently logged-on user by using his or her domain credentials, and uses the NTLMv2 protocol instead of Kerberos V5. This authentication method works only with other computers that can use AuthIP, including Windows Vista and Windows Server User-based authentication using Kerberos V5 is not supported by IKE v1. User health certificate from this certification authority (CA). Selecting this option and entering the identification of a CA tells the computer to use and require userbased authentication by using a certificate that is issued by the specified CA. If you also select Enable certificate to account mapping, then the certificate can be associated with a user in Active Directory for purposes of granting or denying access to specified users or user groups. 172

173 Computer health certificate from this certification authority (CA). Selecting this option and entering the identification of a CA tells the computer to use and require authentication by using a certificate that is issued by the specified CA. If you also select Accept only health certificates, then only certificates that include the system health authentication EKU typically provided in a NAP infrastructure can be used for this rule. If you select Second authentication is optional, then the connection can succeed even if the authentication attempt specified in this column fails. Important Make sure that you do not select the check boxes to make both first and second authentication optional. Doing so allows plaintext connections whenever authentication fails. 5. Click OK on each dialog box to save your changes and return to the Group Policy Management Editor. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server 2008 This procedure shows you how to configure the data protection (quick mode) settings for connection security rules in an isolated domain or a standalone isolated server zone. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To configure quick mode settings 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the details pane on the main Windows Firewall with Advanced Security page, click Windows Firewall Properties. 3. On the IPsec Settings tab, click Customize. 4. In the Data protection (Quick Mode) section, click Advanced, and then click Customize. 5. If you require encryption for all network traffic in the specified zone, then check Require encryption for all connection security rules that use these settings. Selecting this option disables the Data integrity section, and forces you to select only integrity algorithms that are combined with an encryption algorithm. If you do not select this option, then you can use only data integrity algorithms. Before selecting this option, consider the performance impact and the increase in network traffic that will result. We 173

174 recommend that you use this setting only on network traffic that truly requires it, such as to and from computers in the encryption zone. 6. If you did not select Require encryption, then select the data integrity algorithms that you want to use to help protect the data sessions between the two computers. If the data integrity algorithms displayed in the list are not what you want, then do the following: a. From the left column, remove any of the data integrity algorithms that you do not want by selecting the algorithm and then clicking Remove. b. Add any required data integrity algorithms by clicking Add, selecting the appropriate protocol (ESP or AH) and algorithm (SHA1 or MD5), selecting the key lifetime in minutes or sessions, and then clicking OK. We recommend that you do not include MD5 in any combination. It is included for backward compatibility only. We also recommend that you use ESP instead of AH if you have any devices on your network that use network address translation (NAT). c. In Key lifetime (in sessions), type the number of times that the quick mode session can be rekeyed. After this number is reached, the quick mode SA must be renegotiated. Be careful to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance because of the more frequent renegotiating of the quick mode SA. We recommend that you use the default value unless your risk analysis indicates the need for a different value. d. Click OK to save your algorithm combination settings. e. After the list contains only the combinations you want, use the up and down arrows to the right of the list to rearrange them in the correct order for your design. The algorithm combination that is first in the list is tried first, and so on. 7. Select the data integrity and encryption algorithms that you want to use to help protect the data sessions between the two computers. If the algorithm combinations displayed in the list are not what you want, then do the following: a. From the second column, remove any of the data integrity and encryption algorithms that you do not want by selecting the algorithm combination and then clicking Remove. b. Add any required integrity and encryption algorithm combinations by clicking Add, and then doing the following: c. Select the appropriate protocol (ESP or AH). We recommend that you use ESP instead of AH if you have any devices on your network that use NAT. d. Select the appropriate encryption algorithm. The choices include, in order of decreasing security: AES-256, AES-192, AES-128, 3DES, and DES. We recommend that you do not include DES in any combination. It is included for backward compatibility only. e. Select the appropriate integrity algorithm (SHA1 or MD5). We recommend that you do not include MD5 in any combination. It is included for backward compatibility only. f. In Key lifetime (in minutes), type the number of minutes. When the specified 174

175 number of minutes has elapsed, any IPsec operations between the two computers that negotiated this key will require a new key. Be careful to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance because of the more frequent rekeying. We recommend that you use the default value unless your risk analysis indicates the need for a different value. 8. Click OK three times to save your settings. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Configure Group Policy to Autoenroll and Deploy Certificates You can use this procedure to configure Group Policy to automatically enroll client computer certificates and deploy them to the workstations on your network. Follow this procedure for each GPO that contains IPsec connection security rules that require this certificate. Administrative credentials To complete these procedures, you must be a member of both the Domain Admins group in the root domain of your forest and a member of the Enterprise Admins group. To configure Group Policy to autoenroll certificates 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO you want to modify, and then click Edit. 4. In the navigation pane, expand the following path: Computer Configuration, Policies, Windows Settings, Security Settings, Public Key Policies. 5. Double-click Certificate Services Client - Auto-Enrollment. 6. In the Properties dialog box, change Configuration Model to Enabled. 7. Select both Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates. 8. Click OK to save your changes. Computers apply the GPO and download the certificate the next time Group Policy is refreshed. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. 175

176 Configure Key Exchange (Main Mode) Settings on Earlier Versions of Windows After you have created a new IP Security policy, you can configure the key exchange algorithms that will be used to negotiate and specify how frequently the keys must be changed. You must specify algorithm combinations that are compatible with the other computers with which the local computer must communicate. Each combination includes an encryption algorithm, an integrity algorithm, and a Diffie-Hellman Group. The order in which the combinations are listed is the order in which they are tried, so place the ones you need most frequently at the top of the list. Important We recommend that you do not include DES, MD5, or Diffie-Hellman Group 1 in any combination. They are no longer considered secure, and are included for backward compatibility only. Use the strongest algorithms that are supported by your computers. If you have some computers that do not support some of the stronger algorithms, then include combinations that include the stronger algorithms for those computers that can use them, and include combinations that are less strong for compatibility with computers that do not support the stronger ones. Place the combinations with the stronger algorithms at the top of the list to ensure that they are used if both computers support them. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To configure key exchange settings 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, right-click the IP Security policy that you want to modify, and then click Properties. 3. Select the General tab, and then click Settings. 4. Specify a key lifetime for the main mode key, in both minutes and sessions. When either value is reached, Windows generates a new main mode key. 5. Click Methods. 6. In the Key Exchange Security Methods dialog box, click Add to create a new combination, or select an existing combination from the list, and click Edit. 7. In the IKE Security Algorithms dialog box, select an integrity algorithm, an encryption algorithm, and a Diffie-Hellman group, and then click OK. 8. After you add or modify the last combination, click OK three times to save your changes. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. 176

177 Configure Key Exchange (Main Mode) Settings on Windows Vista and Windows Server 2008 This procedure shows you how to configure the main mode key exchange settings used to secure the IPsec authentication traffic. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To configure key exchange settings 1. Open the Group Policy Management Console to the Windows Firewall with Advanced Security. 2. In the details pane on the main Windows Firewall with Advanced Security page, click Windows Firewall Properties. 3. On the IPsec Settings tab, click Customize. 4. In the Key exchange (Main Mode) section, click Advanced, and then click Customize. 5. Select the security methods to be used to help protect the main mode negotiations between the two computers. If the security methods displayed in the list are not what you want, then do the following: Important In Windows Vista and Windows Server 2008, you can specify only one key exchange algorithm. This means that if you want to communicate by using IPsec with another computer running Windows Vista or Windows Server 2008, then you must select the same key exchange algorithm on both computers. Because Windows XP, Windows Server 2003, and Windows 2000 support multiple key exchange algorithms, the one selected on Windows Vista or Windows Server 2008 must match one of the algorithms in the list on the earlier versions of Windows. Also, if you create a connection security rule that specifies an option that requires AuthIP instead of IKE, then only the one combination of the top integrity and encryption security method are used in the negotiation. Make sure that all of your computers that run Windows Vista or Windows Server 2008 have the same methods at the top of the list and the same key exchange algorithm selected. Note When AuthIP is used, no Diffie-Hellman key exchange protocol is used. Instead, when Kerberos V5 authentication is requested, the Kerberos V5 service ticket secret is used in place of a Diffie-Hellman value. When either certificate authentication or NTLM authentication is requested, a transport level security (TLS) session is established, and its secret is used in place of the Diffie-Hellman value. This happens no matter which Diffie-Hellman key exchange protocol you select. 177

178 a. Remove any of the security methods that you do not want by selecting the method and then clicking Remove. b. Add any required security method combinations by clicking Add, selecting the appropriate encryption algorithm and integrity algorithm from the lists, and then clicking OK. Caution We recommend that you do not include MD5 or DES in any combination. They are included for backward compatibility only. c. After the list contains only the combinations you want, use the up and down arrows to the right of the list to arrange them in the order of preference. The combination that appears first in the list is tried first, and so on. 6. From the list on the right, select the key exchange algorithm that you want to use. Caution We recommend that you do not use Diffie-Hellman Group 1. It is included for backward compatibility only. 7. In Key lifetime (in minutes), type the number of minutes. When the specified number of minutes has elapsed, any IPsec operation between the two computers requires a new key. Note You need to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance. 8. In Key lifetime (in sessions), type the number of sessions. After the specified number of quick mode sessions have been created within the security association protected by this key, IPsec requires a new key. 9. Click OK three times to save your settings. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows We recommend that you use Group Policy to include the following registry settings before deploying IPsec rules to computers running Windows Server 2003 or Windows XP. The first setting changes the protocols that are exempted from IPsec by default. This setting is documented in article in the Microsoft Knowledge Base ( We recommend setting the value to 2 to exempt RSVP, Kerberos, and ISAKMP protocol traffic, but not multicast or broadcast traffic. The second setting is for configuring simplified IPsec policy. This setting is documented in article in the Microsoft Knowledge Base ( We 178

179 recommend that you set the bits 0x14 in the IKEFlags setting. This value is interpreted as a bitmap, so if the existing value is not 0, then you should take steps to preserve the existing bits and add these bits to the existing value. If the value is initially a 0, then you can simply write the value 0x14 to the registry key. If you are running Windows Server 2003 with Service Pack 2 (SP2) or earlier or Windows XP with SP2 or earlier, then you must first install the update documented in article in the Microsoft Knowledge Base to enable simplified IPsec policy ( The update is included with Windows XP with SP3. The next setting is to support IPsec over NAT-T when the client or the server is behind a network address translator. This setting is documented in article in the Microsoft Knowledge Base ( By default, IPsec connections are blocked if a computer is separated from the other computer by a NAT device. If one of the computers must be behind a NAT device, then use one of the values supported by the documented registry key to enable the appropriate scenario. If you do not have NAT devices separating computers that must communicate by using IPsec, then set the value to 0. The final setting is for performance; it configures the IP stack to dynamically discover the largest packet size available between two communicating computers, instead of using a potentially inefficient default, fixed size. This setting is already set to the correct value in Windows Vista, but for earlier versions of Windows, and to ensure that it cannot be changed on the client computers, set the value to 1. The setting is documented in EnablePMTUDiscovery ( To support the changing of registry settings by using a GPO, you must first configure the Group Policy Management Console (GPMC) with a custom.xml template file that defines the registry settings to the Group Policy Management Editor. You can use the sample file provided in Appendix A: Sample GPO Template Files for Settings Used in this Guide in the Windows Firewall with Advanced Security Design Guide. The sample file also includes recommended values for two other settings that are useful for configuring IPsec on the network. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To configure the custom.xml file to use the settings in GPMC 1. Open the folder containing the custom.xml file. If the file does not yet exist, you can use the sample file shown in Appendix A: Sample GPO Template Files for Settings Used in this Guide in the Windows Firewall with Advanced Security Design Guide as a starting point. Copy the source data into Notepad, and then save the file with an.xml extension to your desktop. Before you use the file, make sure that you customize it to meet your organization s requirements. 2. Click Start, click Administrative Tools, and then click Group Policy Management. 3. Find the GPO to which you want to add the custom registry settings, right-click it, and then click Edit. 179

180 4. In the Group Policy Management Editor, expand Computer Configuration, expand Preferences, and then expand Windows Settings. 5. Drag and drop your custom.xml file onto the Registry node in the navigation pane. 6. When asked to confirm that you want to import the document, click Yes. 7. Click the Server and Domain Isolation Settings folder to see the individual settings. The sample file uses the recommended values for each registry key as the default value. Change the registry keys as required for your environment before deploying the GPO. To change one, double-click the setting, and on the General tab, change Value data. 8. Link the GPO to the appropriate container or containers and use WMI filters to restrict application of the GPO to only those computers that require the setting. For an isolated domain, you might consider assigning the GPO to the domain container and using a WMI filter to apply it to only computers running Windows XP or Windows Server For an isolated server environment without an isolated domain, you can assign the GPO to only those computers that must access the isolated server. To do this, assign the GPO to the domain container, use WMI filters to restrict the GPO to only those computers running Windows XP or Windows Server 2003, and then place the group that grants access to the isolated server in the security group filter for the GPO. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Configure the Rules to Require Encryption on Windows Vista and Windows Server 2008 If you are creating a zone that requires encryption, you must configure the rules to add the encryption algorithms and delete the algorithm combinations that do not use encryption. Administrative credentials To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To modify an authentication request rule to also require encryption 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Connection Security Rules. 3. In the details pane, double-click the connection security rule you want to modify. 4. On the Name page, rename the connection security rule, edit the description to reflect the new use for the rule, and then click OK. 5. In the navigation pane, right-click Windows Firewall with Advanced Security LDAP://CN={guid}, and then click Properties. 6. Click the IPsec Settings tab. 180

181 7. Under IPsec defaults, click Customize. 8. Under Data protection (Quick Mode), click Customize. 9. Click Require encryption for all connection security rules that use these settings. This disables the data integrity rules section. Make sure the Data integrity and encryption list contains all of the combinations that your client computers will use to connect to members of the encryption zone. The client computers receive their rules through the GPO for the zone to which they reside. You must make sure that those rules contain at least one of the data integrity and encryption algorithms that are configured in this rule, or the client computers in that zone will not be able to connect to computers in this zone. 10. If you need to add an algorithm combination, click Add, and then select the combination of encryption and integrity algorithms. The options are described in Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server Notes Not all of the algorithms available in Windows Vista with Service Pack 1 or Windows Server 2008 can be selected in the Windows Firewall with Advanced Security user interface. To select them, you must use the Netsh command-line tool. Quick mode settings can also be configured on a per-rule basis, but not by using the Windows Firewall with Advanced Security user interface. Instead, you must create or modify the rules by using the Netsh command-line tool. For more information, see the Netsh Technical Reference ( 11. During negotiation, algorithm combinations are proposed in the order shown in the list. Make sure that the more secure combinations are at the top of the list so that the negotiating computers select the most secure combination that they can jointly support. 12. Click OK three times to save your changes. Configure the Windows Firewall Log To configure Windows Firewall to log dropped packets or successful connections, use the Windows Firewall with Advanced Security node (for Windows Vista or Windows Server 2008) or Windows Firewall (for Windows XP or Windows Server 2003) in the Group Policy Management MMC snap-in. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. In this topic: To configure Windows Firewall logging for Windows XP or Windows Server

182 To configure Windows Firewall logging for Windows Vista or Windows Server Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the details pane, in the Overview section, click Windows Firewall Properties. 3. For each network location type (Domain, Private, Public), perform the following steps. a. Click the tab that corresponds to the network location type. b. Under Logging, click Customize. c. The default path for the log is %windir%\system32\logfiles\firewall\pfirewall.log. If you want to change this, type the path to the new location, or click Browse to select a file location. Important The location you specify must have permissions assigned that permit the Windows Firewall service to write to the log file. d. The default maximum file size for the log is 4,096 kilobytes (KB). If you want to change this, type in the new size in KB, or use the up and down arrows to select a size. The file will not grow beyond this size; when the limit is reached, old log entries are deleted to make room for the newly created ones. e. No logging occurs until you set one of following two options: To create a log entry when Windows Firewall drops an incoming network packet, change Log dropped packets to Yes. To create a log entry when Windows Firewall allows an inbound connection, change Log successful connections to Yes. f. Click OK twice. To configure Windows Firewall logging for Windows XP or Windows Server Open the Group Policy Management Console to Windows Firewall. 2. In the navigation pane, click either Domain Profile or Standard Profile. 3. In the details pane, double-click Windows Firewall: Allow logging. 4. Click Enabled. 5. No logging actually occurs until you set one of following two options: To create a log entry when Windows Firewall drops an incoming network packet, select Log dropped packets. To create a log entry when Windows Firewall allows an inbound connection, select Log successful connections. 182

183 6. The default path for the log is %windir%\pfirewall.log. If you want to change this, type the path to the new location, or click Save As to select a file location. 7. The default maximum file size for the log is 4096 KB. If you want to change this, type in the new size in KB, or use the up and down arrows to select a size. The file will not grow beyond this size; when the limit is reached, old log entries are deleted to make room for the newly created ones. 8. Click OK twice. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Configure the Workstation Authentication Certificate Template This procedure describes how to configure a certificate template that Active Directory Certification Services (AD CS) uses as the starting point for computer certificates that are automatically enrolled and deployed to workstations in the domain. It shows how to create a copy of a template, and then configure the template according to your design requirements. Administrative credentials To complete these procedures, you must be a member of both the Domain Admins group in the root domain of your forest, and a member of the Enterprise Admins group. To configure the workstation authentication certificate template and autoenrollment 1. On the computer where AD CS is installed, click Start, click Administrative Tools, and then click Certification Authority. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, right-click Certificate Templates, and then click Manage. 4. In the details pane, click the Workstation Authentication template. 5. On the Action menu, click Duplicate Template. In the Duplicate Template dialog box, select the template version that is appropriate for your deployment, and then click OK. For the resulting certificates to have maximum compatibility with the available versions of Windows, we recommended that you select Windows Server 2003, Enterprise Edition. 6. On the General tab, in Template display name, type a new name for the certificate template, such as Domain Isolation Workstation Authentication Template. 7. Click the Subject Name tab. Make sure that Build from this Active Directory information is selected. In Subject name format, select Fully distinguished name. 8. Click the Request Handling tab. You must determine the best minimum key size for your environment. Large key sizes provide better security, but they can affect server performance. We recommended that you use the default setting of Click the Security tab. In Group or user names, click Domain Computers, under Allow, select Enroll and Autoenroll, and then click OK. 183

184 Note If you want do not want to deploy the certificate to every computer in the domain, then specify a different group or groups that contain the computer accounts that you want to receive the certificate. 10. Close the Certificate Templates Console. 11. In the Certification Authority MMC snap-in, in the left pane, right-click Certificate Templates, click New, and then click Certificate Template to Issue. 12. In the Enable Certificate Templates dialog box, click the name of the certificate template you just configured, and then click OK. Configure Windows Firewall to Suppress Notifications When a Program Is Blocked To configure Windows Firewall to suppress the display of a notification when it blocks a program that tries to listen for network traffic and to prohibit locally defined rules, use the Windows Firewall with Advanced Security node (for Windows Vista or Windows Server 2008) or Windows Firewall (for Windows XP or Windows Server 2003) in the Group Policy Management MMC snap-in. Caution If you choose to disable alerts and prohibit locally defined rules, then you must create firewall rules that allow your users programs to send and receive the required network traffic. If a firewall rule is missing, then the user does not receive any kind of warning, the network traffic is silently blocked, and the program might fail. We recommend that you do not enable these settings until you have created and tested the required rules. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. In this topic: To configure Windows Firewall to suppress the display of a notification for a blocked program and to ignore locally defined rules on Windows XP or Windows Server 2003 To configure Windows Firewall to suppress the display of a notification for a blocked program and to ignore locally defined rules on Windows Vista or Windows Server Open the Group Policy Management Console to Windows Firewall with Advanced Security. 184

185 2. In the details pane, in the Overview section, click Windows Firewall Properties. 3. For each network location type (Domain, Private, Public), perform the following steps. a. Click the tab that corresponds to the network location type. b. Under Settings, click Customize. c. Under Firewall settings, change Display a notification to No. d. Under Rule merging, change Apply local firewall rules to No. e. Although a connection security rule is not a firewall setting, you can also use this tab to prohibit locally defined connection security rules if you are planning to deploy IPsec rules as part of a server or domain isolation environment. Under Rule merging, change Apply local connection security rules to No. f. Click OK twice. To configure Windows Firewall to suppress the display of a notification for a blocked program and to ignore locally defined rules on Windows XP or Windows Server Open the Group Policy Management Console to Windows Firewall. 2. In the navigation pane, click either Domain Profile or Standard Profile. 3. In the details pane, double-click Windows Firewall: Allow local program exceptions. 4. Click Disabled, and then click OK. 5. In the details pane, double-click Windows Firewall: Do not allow exceptions. 6. Click Disabled, and then click OK. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Confirm That Certificates Are Deployed Correctly After configuring your certificates and autoenrollment in Group Policy, you can confirm that the policy is being applied as expected, and that the certificates are being properly installed on the workstation computers. In these procedures, you refresh Group Policy on a client computer, and then confirm that the certificate is deployed correctly. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. In this topic: Refresh Group Policy on a computer Verify that a certificate is installed 185

186 To refresh Group Policy on a computer On a computer running Windows Vista, or Windows Server 2008, start a command prompt as an administratorstart a Command Line as an Administrator, and then type the following command: gpupdate /target:computer /force On a computer running Windows XP or Windows Server 2003, start a command prompt, and then type the following command: gpupdate /target:computer /force On a computer running Windows 2000, start a command prompt, and then type the following command: secedit /refreshpolicy machine_policy After Group Policy is refreshed, you can see which GPOs are currently applied to the computer. To verify that a certificate is installed 1. Click Start, in the Start Search box, type certmgr.msc, and then press ENTER. 2. In the navigation pane, expand Trusted Root Certification Authorities, and then click Certificates. The CA that you created appears in the list. Copy a GPO to Create a New GPO To create the GPO for the boundary zone computers, make a copy of the main domain isolation GPO, and then change the settings to request, instead of require, authentication. To make a copy of a GPO, use the Active Directory Users and Computers MMC snap-in. Administrative credentials To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new GPOs. To make a copy of a GPO 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest:YourForestName, expand Domains, expand 186

187 YourDomainName, and then click Group Policy Objects. 4. In the details pane, right-click the GPO you want to copy, and then click Copy. 5. In the navigation pane, right-click Group Policy Objects again, and then click Paste. 6. In the Copy GPO dialog box, click Preserve the existing permissions, and then click OK. Selecting this option preserves any exception groups to which you denied Read and Apply GPO permissions, making the change simpler. 7. After the copy is complete, click OK. The new GPO is named Copy of Original GPO Name. 8. To rename it, right-click the GPO, and then click Rename. 9. Type the new name, and then press ENTER. 10. You must change the security filters to apply the policy to the correct group of computers. To do this, click the Scope tab, and in the Security Filtering section, select the group that grants permissions to all members of the isolated domain, for example CG_DOMISO_IsolatedDomain, and then click Remove. 11. In the confirmation dialog box, click OK. 12. Click Add. 13. Type the name of the group that contains members of the boundary zone, for example CG_DOMISO_Boundary, and then click OK. 14. If required, change the WMI filter to one appropriate for the new GPO. For example, if the original GPO is for client computers running Windows Vista, and the new boundary zone GPO is for computers running Windows Server 2008, then select a WMI filter that allows only those computers to read and apply the GPO. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create a Group Account in Active Directory To create a security group to contain the computer accounts for the computers that are to receive a set of Group Policy settings, use the Active Directory Users and Computers MMC snap-in. Administrative credentials To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new group accounts. To add a new membership group in Active Directory 1. On a computer that has Active Directory management tools installed, click Start, click Administrative Tools, and then click Active Directory Users and Computers. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, select the container in which you want to store your group. This is 187

188 typically the Users container under the domain. 4. Click Action, click New, and then click Group. 5. In the Group name text box, type the name for your new group. Note Be sure to use a name that clearly indicates its purpose. Check to see if your organization has a naming convention for groups. 6. In the Description text box, enter a description of the purpose of this group. 7. In the Group scope section, select either Global or Universal, depending on your Active Directory forest structure. If your group must include computers from multiple domains, then select Universal. If all of the members are from the same domain, then select Global. 8. In the Group type section, click Security. 9. Click OK to save your group. Create a Group Policy Object To create a new GPO, use the Active Directory Users and Computers MMC snap-in. Administrative credentials To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new GPOs. To create a new GPO 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest:YourForestName, expand Domains, expand YourDomainName, and then click Group Policy Objects. 4. Click Action, and then click New. 5. In the Name text box, type the name for your new GPO. Note Be sure to use a name that clearly indicates the purpose of the GPO. Check to see if your organization has a naming convention for GPOs. 6. Leave Source Starter GPO set to (none), and then click OK. 7. If your GPO will not contain any user settings, then you can improve performance by disabling the User Configuration section of the GPO. To do this, perform these steps: a. In the navigation pane, click the new GPO. 188

189 b. In the details pane, click the Details tab. c. Change the GPO Status to User configuration settings disabled. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create a New IP Security Policy in a GPO for Earlier Versions of Windows Computers running Windows Server 2003, Windows XP, and Windows 2000 use an IPsec policy, which is a collection of filter lists and filter actions, combined with authentication settings. Only one policy can be active on a computer at a time. A policy consists of a collection of rules. A rule consists of an IPsec filter list, a filter action, and if required by the filter action, a list of authentication methods. Inbound and outbound network packets are compared to the criteria in the filter lists. If a packet matches the criteria, then the associated filter action is applied. Filter actions can allow or block the packet, or require that the packet is authenticated and, optionally, encrypted. In this procedure, you create the IPsec policy to contain the IPsec rules you define. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create a new IPsec policy in a GPO 1. Open the Group Policy Management Console to IP Security Policies. 2. Click Action, and then click Create IP Security Policy. 3. On the Welcome page of the wizard, click Next. 4. On the IP Security Policy Name page, type a name for your IPsec policy, type a description for the policy, and then click Next. 5. On the Requests for Secure Communication page, clear the Activate the default response rule option, and then click Next. 6. On the Completing the IP Security Policy Wizard page, clear the Edit properties option, click Finish, and then click OK. You will modify the policy s properties later. Your new policy appears in the list in the details pane. 7. If you want this IPsec policy to be the active one for the GPO, right-click the policy, and then click Assign. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. 189

190 Create an Authentication Exemption List Rule on Windows Vista and Windows Server 2008 In almost any isolated server or isolated domain scenario, there are some computers or devices that cannot communicate by using IPsec. This procedure shows you how to create rules that exempt those computers from the authentication requirements of your isolation policies. notedsdoc112778pads Security Note Adding computers to the exemption list for a zone reduces security because it permits computers in the zone to send network traffic that is unprotected by IPsec to the computers on the list. As discussed in the Windows Firewall with Advanced Security Design Guide, you must add only managed and trusted computers to the exemption list. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create a rule that exempts specified hosts from authentication 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Connection Security Rules. 3. Click Action, and then click New Rule. 4. On the Rule Type page of the New Connection Security Rule Wizard, click Authentication exemption, and then click Next. 5. On the Exempt Computers page, to create a new exemption, click Add. To modify an existing exemption, click it, and then click Edit. 6. In the IP Address dialog box, do one of the following: To add a single IP address, click This IP address or subnet, type the IP address of the host in the text box, and then click OK. To add an entire subnet by address, click This IP address or subnet, and then type the IP address of the subnet, followed by a forward slash (/) and the number of bits in the corresponding subnet mask. For example, /16 represents the class B subnet that begins with address , and ends with address Click OK when you are finished. To add the local computer s subnet, click Predefined set of computers, select Local subnet from the list, and then click OK. Note If you select the local subnet from the list rather than typing the subnet address in manually, the computer automatically adjusts the active local subnet to match the computer s current IP address. To add a discrete range of addresses that do not correspond to a subnet, click This IP address range, type the beginning and ending IP addresses in the From and To 190

191 text boxes, and then click OK. To exempt all of the remote hosts that the local computer uses for a specified network service, click Predefined set of computers, select the network service from the list, and then click OK. 7. Repeat steps 5 and 6 for each exemption that you need to create. 8. Click Next when you have created all of the exemptions. 9. On the Profile page, check the profile for each network location type to which this set of exemptions applies, and then click Next. Caution If all of the exemptions are on the organization s network and that network is managed by an Active Directory domain, then consider restricting the rule to the Domain profile only. Selecting the wrong profile can reduce the protection for your computer because any computer with an IP address that matches an exemption rule will not required to authenticate. 10. On the Name page, type the name of the exemption rule, type a description, and then click Finish. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create an Authentication Request Rule on Windows Vista and Windows Server 2008 After you have configured IPsec algorithms and authentication methods, you can create the rule that requires the computers on the network to use those protocols and methods before they can communicate. Administrative credentials To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create the authentication request rule 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, right-click Connection Security Rules, and then click New Rule. 3. On the Rule Type page, select Isolation, and then click Next. 4. On the Requirements page, select Request authentication for inbound and outbound connections. Caution Do not configure the rule to require inbound authentication until you have confirmed that all of your computers are receiving the correct GPOs, and are 191

192 successfully negotiating IPsec and authenticating with each other. Allowing the computers to communicate even when authentication fails prevents any errors in the GPOs or their distribution from breaking communications on your network. 5. On the Authentication Method page, select the authentication option you want to use on your network. To select multiple methods that are tried in order until one succeeds, click Advanced, click Customize, and then click Add to add methods to the list. If your rule must be compatible with Windows Server 2003 and earlier versions of Windows, do not include any methods in the Second authentication methods list. Second authentication methods require Authenticated IP (AuthIP), which is supported only on Windows Vista and Windows Server a. Default. Selecting this option tells the computer to request authentication by using the method currently defined as the default on the computer. This default might have been configured when the operating system was installed or it might have been configured by Group Policy. Selecting this option is appropriate when you have configured system-wide settings by using the Configure Authentication Methods on Windows Vista and Windows Server 2008 procedure. b. Computer and User (using Kerberos V5). Selecting this option tells the computer to request authentication of both the computer and the currently logged-on user by using their domain credentials. This authentication method works only with other computers that can use AuthIP, including Windows Vista and Windows Server User-based authentication using Kerberos V5 is not supported by IKE v1. c. Computer (using Kerberos V5). Selecting this option tells the computer to request authentication of the computer by using its domain credentials. This option works with other computers than can use IKE v1, including earlier versions of Windows. d. Computer certificate. Selecting this option and entering the identification of a certification authority (CA) tells the computer to request authentication by using a certificate that is issued by the specified CA. If you also select Only accept health certificates, then only certificates issued by a Network Access Protection (NAP) server can be used for this rule. e. Advanced. Click Customize to specify a custom combination of authentication methods required for your scenario. You can specify both a First authentication method and a Second authentication method. The first authentication method can be one of the following: Computer (Kerberos V5). Selecting this option tells the computer to request authentication of the computer by using its domain credentials. This option works with other computers than can use IKE v1, including earlier versions of Windows. Computer (NTLMv2). Selecting this option tells the computer to use and require authentication of the computer by using its domain credentials. This option works only with other computers that can use AuthIP, including Windows Vista and Windows Server User-based authentication using Kerberos V5 is not supported by IKE v1. 192

193 Computer certificate from this certification authority (CA). Selecting this option and entering the identification of a CA tells the computer to request authentication by using a certificate that is issued by the specified CA. If you also select Accept only health certificates, then only certificates issued by a NAP server can be used for this rule. Preshared key (not recommended). Selecting this method and entering a preshared key tells the computer to authenticate by exchanging the preshared keys. If the keys match, then the authentication succeeds. This method is not recommended, and is included for backward compatibility and testing purposes only. If you select First authentication is optional, then the connection can succeed even if the authentication attempt specified in this column fails. The second authentication method can be one of the following: User (Kerberos V5). Selecting this option tells the computer to use and require authentication of the currently logged-on user by using his or her domain credentials. This authentication method works only with other computers that can use AuthIP, including Windows Vista and Windows Server User-based authentication using Kerberos V5 is not supported by IKE v1. User (NTLMv2). Selecting this option tells the computer to use and require authentication of the currently logged-on user by using his or her domain credentials, and uses the NTLMv2 protocol instead of Kerberos V5. This authentication method works only with other computers that can use AuthIP, including Windows Vista and Windows Server User-based authentication using NTLMv2 is not supported by IKE v1. User health certificate from this certification authority (CA). Selecting this option and entering the identification of a CA tells the computer to request user-based authentication by using a certificate that is issued by the specified CA. If you also select Enable certificate to account mapping, then the certificate can be associated with a user in Active Directory for purposes of granting or denying access to certain users or user groups. Computer health certificate from this certification authority (CA). Selecting this option and entering the identification of a CA tells the computer to use and require authentication by using a certificate that is issued by the specified CA. If you also select Accept only health certificates, then only certificates issued by a NAP server can be used for this rule. If you check Second authentication is optional, the connection can succeed even if the authentication attempt specified in this column fails. Important Make sure that you do not select the boxes to make both first and second authentication optional. Doing so allows plaintext connections whenever authentication fails. 6. After you have configured the authentication methods, click OK on each dialog box to 193

194 save your changes and close it, until you return to the Authentication Method page in the wizard. Click Next. 7. On the Profile page, select the check boxes for the network location type profiles to which this rule applies. On portable computers, consider clearing the Private and Public boxes to enable the computer to communicate without authentication when it is away from the domain network. On computers that do not move from network to network, consider selecting all of the profiles. Doing so prevents an unexpected switch in the network location type from disabling the rule. Click Next. 8. On the Name page, type a name for the connection security rule and a description, and then click Finish. The new rule appears in the list of connection security rules. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create an Inbound ICMP Rule on Windows Vista or Windows Server 2008 To allow inbound Internet Control Message Protocol (ICMP) network traffic, use the Windows Firewall with Advanced Security node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows ICMP requests and responses to be sent and received by computers on the network. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. This topic describes how to create a port rule that allows inbound ICMP network traffic. For other inbound port rule types, see: Create an Inbound Port Rule on Windows Vista or Windows Server 2008 Create Inbound Rules to Support RPC on Windows Vista or Windows Server 2008 To create an inbound ICMP rule 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Inbound Rules. 3. Click Action, and then click New rule. 4. On the Rule Type page of the New Inbound Rule Wizard, click Custom, and then click Next. 194

195 5. On the Program page, click All programs, and then click Next. 6. On the Protocol and Ports page, select ICMPv4 or ICMPv6 from the Protocol type list. If you use both IPv4 and IPv6 on your network, you must create a separate ICMP rule for each. 7. Click Customize. 8. In the Customize ICMP Settings dialog box, do one of the following: To allow all ICMP network traffic, click All ICMP types, and then click OK. To select one of the predefined ICMP types, click Specific ICMP types, and then select each type in the list that you want to allow. Click OK. To select an ICMP type that does not appear in the list, click Specific ICMP types, select the Type number from the list, select the Code number from the list, click Add, and then select the newly created entry from the list. Click OK 9. Click Next. 10. On the Scope page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click Next. 11. On the Action page, select Allow the connection, and then click Next. 12. On the Profile page, select the network location types to which this rule applies, and then click Next. Note If this GPO is targeted at server computers that never move, consider modifying the rules to apply to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public network location type. 13. On the Name page, type a name and description for your rule, and then click Finish. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create an Inbound Port Rule on Windows Vista or Windows Server 2008 To allow inbound network traffic on only a specified TCP or UDP port number, use the Windows Firewall with Advanced Security node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows any program that listens on a specified TCP or UDP port to receive network traffic sent to that port. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. 195

196 This topic describes how to create a standard port rule for a specified protocol or TCP or UDP port number. For other inbound port rule types, see: Create an Inbound ICMP Rule on Windows Vista or Windows Server 2008 Create Inbound Rules to Support RPC on Windows Vista or Windows Server 2008 To create an inbound port rule 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Inbound Rules. 3. Click Action, and then click New rule. 4. On the Rule Type page of the New Inbound Rule Wizard, click Custom, and then click Next. Note Although you can create rules by selecting Program or Port, those choices limit the number of pages presented by the wizard. If you select Custom, you see all of the pages, and have the most flexibility in creating your rules. 5. On the Program page, click All programs, and then click Next. Note This type of rule is often combined with a program or service rule. If you combine the rule types, you get a firewall rule that limits traffic to a specified port and allows the traffic only when the specified program is running. The specified program cannot receive network traffic on other ports, and other programs cannot receive network traffic on the specified port. If you choose to do this, follow the steps in the Create an Inbound Program or Service Rule on Windows Vista or Windows Server 2008 procedure in addition to the steps in this procedure to create a single rule that filters network traffic using both program and port criteria. 6. On the Protocol and Ports page, select the protocol type that you want to allow. To restrict the rule to a specified port number, you must select either TCP or UDP. Because this is an incoming rule, you typically configure only the local port number. If you select another protocol, then only packets whose protocol field in the IP header match this rule are permitted through the firewall. To select a protocol by its number, select Custom from the list, and then type the number in the Protocol number box. When you have configured the protocols and ports, click Next. 7. On the Scope page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click Next. 8. On the Action page, select Allow the connection, and then click Next. 196

197 9. On the Profile page, select the network location types to which this rule applies, and then click Next. Note If this GPO is targeted at server computers that never move, consider modifying the rules to apply to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public network location type. 10. On the Name page, type a name and description for your rule, and then click Finish. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create an Inbound Port Rule on Windows XP or Windows Server 2003 To allow inbound network traffic to a specified port number, use the Windows Firewall node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows inbound network traffic addressed to a specified port number to be received by a program that is listening on that port. Note Unlike in Windows Vista and Windows Server 2008, Windows Firewall in earlier versions of Windows does not support the creation of a rule that restricts network traffic to both a specified program and a specified port number. If you create a program rule, then that program can receive inbound network traffic on any port on which it listens. If you create a port rule, then any program listening on the specified port receives the inbound network traffic. For information about creating a program rule, see Create an Inbound Program Rule on Windows XP or Windows Server Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the relevant GPOs. To create an inbound firewall rule for a TCP or UDP port 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO in which you want to create the rule, and then click Edit. 197

198 4. In the Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, expand Network Connections, and then expand Windows Firewall. 5. Expand Domain Profile or Standard Profile. Rules created in the Domain Profile section apply whenever the client computer is connected to a network on which it can contact a domain controller for its assigned Active Directory domain. Rules created in the Standard section apply when the computer cannot contact a domain controller for its domain. 6. In the details pane, double-click Windows Firewall: Define inbound port exceptions. 7. On the Setting tab, click Enabled, and then click Show. 8. In the Show Contents dialog box, click Add. 9. In the Add item dialog box, type the string that represents the port on which you want to allow inbound network traffic. The text string must conform to the following syntax, with each parameter separated by a colon (:). Port:Transport:Scope:Status:Name Parameter Port Transport Scope Status Name Meaning The decimal port number to which inbound network traffic is allowed. The protocol for the port number. Either TCP or UDP. Select one of the following options: An asterisk (*) to represent all networks. A comma-separated list of IP address or subnets, such as: , /24. The string localsubnet. Either Enabled or Disabled. This allows you to disable a single port rule without disabling any others or deleting the rule and losing its configuration. The name for the rule. 10. Click OK three times to save your changes. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. 198

199 Create an Inbound Program or Service Rule on Windows Vista or Windows Server 2008 To allow inbound network traffic to a specified program or service, use the Windows Firewall with Advanced Security node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows the program to listen and receive inbound network traffic on any port. Note This type of rule is often combined with a program or service rule. If you combine the rule types, you get a firewall rule that limits traffic to a specified port and allows the traffic only when the specified program is running. The program cannot receive network traffic on other ports, and other programs cannot receive network traffic on the specified port. To combine the program and port rule types into a single rule, follow the steps in the Create an Inbound Port Rule on Windows Vista or Windows Server 2008 procedure in addition to the steps in this procedure. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create an inbound firewall rule for a program or service 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Inbound Rules. 3. Click Action, and then click New rule. 4. On the Rule Type page of the New Inbound Rule Wizard, click Custom, and then click Next. Note Although you can create rules by selecting Program or Port, those choices limit the number of pages presented by the wizard. If you select Custom, you see all of the pages, and have the most flexibility in creating your rules. 5. On the Program page, click This program path. 6. Type the path to the program in the text box. Use environment variables, where applicable, to ensure that programs installed in different locations on different computers work correctly. 7. Do one of the following: If the executable file contains a single program, click Next. If the executable file is a container for multiple services that must all be allowed to receive inbound network traffic, click Customize, select Apply to services only, click OK, and then click Next. If the executable file is a container for a single service or contains multiple services but the rule only applies to one of them, click Customize, select Apply to this 199

200 service, and then select the service from the list. If the service does not appear in the list, click Apply to service with this service short name, and then type the short name for the service in the text box. Click OK, and then click Next. 8. It is a best practice to restrict the firewall rule for the program to only the ports it needs to operate. On the Protocols and Ports page, you can specify the port numbers for the allowed traffic. If the program tries to listen on a port different from the one specified here, it is blocked. For more information about protocol and port options, see Create an Inbound Port Rule on Windows Vista or Windows Server After you have configured the protocol and port options, click Next. 9. On the Scope page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click Next. 10. On the Action page, select Allow the connection, and then click Next. 11. On the Profile page, select the network location types to which this rule applies, and then click Next. Note If this GPO is targeted at server computers that never move, consider applying the rule to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public network location type. 12. On the Name page, type a name and description for your rule, and then click Finish. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create an Inbound Program Rule on Windows XP or Windows Server 2003 To allow inbound network traffic to a specified program or service, use the Windows Firewall node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows the program to listen and receive inbound network traffic on any port. Note Unlike in Windows Vista and Windows Server 2008, Windows Firewall in earlier versions of Windows does not support the creation of a rule that restricts network traffic to both a specified program and a specified port number. If you create a program rule, then that program can receive inbound network traffic on any port on which it listens. If you create a port rule, then any program listening on the specified port receives the inbound network traffic. For information about creating a port rule on Windows XP or Windows Server 2003, see Create an Inbound Port Rule on Windows XP or Windows Server

201 Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create an inbound firewall rule for a program or service 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO in which you want to create the rule, and then click Edit. 4. In the Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, expand Network Connections, and then expand Windows Firewall. 5. Expand Domain Profile or Standard Profile. Rules created in the Domain Profile section apply whenever the client computer is connected to a network on which it can contact a domain controller for its assigned Active Directory domain. Rules created in the Standard section apply when the computer cannot contact a domain controller for its domain. 6. In the details pane, double-click Windows Firewall: Define inbound program exceptions. 7. On the Setting tab, click Enabled, and then click Show. 8. In the Show Contents dialog box, click Add. 9. In the Add item dialog box, type the full path to the executable file that you want to receive inbound network traffic, and then click OK on each dialog box to save your changes. Notes Use environment variables instead of hard-coded paths when the path to the file might vary from computer to computer. For example, use: If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create an Outbound Port Rule on Windows Vista or Windows Server 2008 By default, Windows Firewall with Advanced Security allows all outbound network traffic unless it matches a rule that prohibits the traffic. To block outbound network traffic on a specified TCP or UDP port number, use the Windows Firewall with Advanced Security node in the Group Policy 201

202 Management MMC snap-in to create firewall rules. This type of rule blocks any outbound network traffic that matches the specified TCP or UDP port numbers. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create an outbound port rule 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Outbound Rules. 3. Click Action, and then click New rule. 4. On the Rule Type page of the New Outbound Rule wizard, click Custom, and then click Next. Note Although you can create rules by selecting Program or Port, those choices limit the number of pages presented by the wizard. If you select Custom, you see all of the pages, and have the most flexibility in creating your rules. 5. On the Program page, click All programs, and then click Next. 6. On the Protocol and Ports page, select the protocol type that you want to block. To restrict the rule to a specified port number, you must select either TCP or UDP. Because this is an outbound rule, you typically configure only the remote port number. If you select another protocol, then only packets whose protocol field in the IP header match this rule are blocked by Windows Firewall. Network traffic for protocols is allowed as long as other rules that match do not block it. To select a protocol by its number, select Custom from the list, and then type the number in the Protocol number box. When you have configured the protocols and ports, click Next. 7. On the Scope page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click Next. 8. On the Action page, select Block the connection, and then click Next. 9. On the Profile page, select the network location types to which this rule applies, and then click Next. Note If this GPO is targeted at server computers that never move, consider applying the rules to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public 202

203 network location type. 10. On the Name page, type a name and description for your rule, and then click Finish. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create an Outbound Program or Service Rule on Windows Vista or Windows Server 2008 By default, Windows Firewall with Advanced Security allows all outbound network traffic unless it matches a rule that prohibits the traffic. To block outbound network traffic for a specified program or service, use the Windows Firewall with Advanced Security node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule prevents the program from sending any outbound network traffic on any port. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create an outbound firewall rule for a program or service 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Outbound Rules. 3. Click Action, and then click New rule. 4. On the Rule Type page of the New Outbound Rule Wizard, click Custom, and then click Next. Note Although you can create many rules by selecting Program or Port, those choices limit the number of pages presented by the wizard. If you select Custom, you see all of the pages, and have the most flexibility in creating your rules. 5. On the Program page, click This program path. 6. Type the path to the program in the text box. Use environment variables as appropriate to ensure that programs installed in different locations on different computers work correctly. 7. Do one of the following: If the executable file contains a single program, click Next. If the executable file is a container for multiple services that must all be blocked from sending outbound network traffic, click Customize, select Apply to services only, click OK, and then click Next. If the executable file is a container for a single service or contains multiple services but the rule only applies to one of them, click Customize, select Apply to this service, and then select the service from the list. If the service does not appear in the 203

204 list, then click Apply to service with this service short name, and type the short name for the service in the text box. Click OK, and then click Next. 8. If you want the program to be allowed to send on some ports, but blocked from sending on others, then you can restrict the firewall rule to block only the specified ports or protocols. On the Protocols and Ports page, you can specify the port numbers or protocol numbers for the blocked traffic. If the program tries to send to or from a port number different from the one specified here, or by using a protocol number different from the one specified here, then the default outbound firewall behavior allows the traffic. For more information about the protocol and port options, see Create an Outbound Port Rule on Windows Vista or Windows Server When you have configured the protocol and port options, click Next. 9. On the Scope page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click Next. 10. On the Action page, select Block the connection, and then click Next. 11. On the Profile page, select the network location types to which this rule applies, and then click Next. Note If this GPO is targeted at server computers that never move, consider modifying the rules to apply to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public network location type. 12. On the Name page, type a name and description for your rule, and then click Finish. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create Filter Actions on Earlier Versions of Windows IP Security rules for Windows 2000, Windows XP, and Windows Server 2003 are composed of filter lists, filter actions, and authentication methods. In this section, you create the filter actions that you later combine with filter lists and authentication method lists. Although you might not need all of these filter actions for your design immediately, creating them now allows you to adapt your design more easily in the future. The filter actions you need for either a domain or server isolation scenario include: Permit. This filter action permits any network traffic that matches the associated filter list. This filter action exists by default, but the procedure in this topic shows you how to re-create it, if necessary. Request Authentication. This filter action causes the computer to request authentication when a computer on the network attempts to connect. If authentication fails, then the computer 204

205 permits the connection without authentication. This filter action exists by default with the name Request security (optional), but the procedure in this topic shows you how to recreate it, if necessary. If you use the default Request Security (Optional) filter action, you must at least configure the list of integrity and encryption methods according to your design. Remove the combinations that you do not want to use on the network. Important We recommend that you do not use MD5 or DES in any combination. They are no longer considered to be secure, and are included for backward compatibility only. This filter action is primarily used by the boundary zone rules, but is also used in the primary domain isolation zone and server isolation zone rules during the testing and piloting phases. This filter action is also used with isolated server clients when an isolated domain is not used. Require Authentication. This filter action causes the computer to require authentication when a computer on the network attempts to connect. If authentication fails, then the connection is refused. This filter action exists by default with the name Require security, but the procedure in this topic shows you how to re-create it, if necessary. If you use the default Require Security filter action, you must at least configure the list of integrity and encryption methods according to your design. Remove the combinations that you do not want to use on the network. This filter action is primarily used by the isolated domain after testing and piloting are complete. It can also be used by isolated servers if encryption is not required. It is not used with the isolated server clients. Request Authentication and Encryption. This filter action causes the computer to request both authentication and encryption when a computer on the network tries to connect. If authentication fails or an encryption algorithm cannot be negotiated, then the connection is permitted to fall back to clear. This filter is used in the encryption zone of an isolated domain during testing. It can also optionally be used by servers in an isolated server zone during testing, and by the clients of an isolated server zone that requires encryption. Require Authentication and Encryption. This filter action causes the computer to require both authentication and encryption when a computer on the network tries to connect. If authentication fails or an encryption algorithm cannot be negotiated, then the connection is refused. This filter is used in the encryption zone of an isolated domain. It can also be used by servers in an isolated server zone when encryption is required. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create the Permit filter action 1. Open the Group Policy Management Console to IP Security Policies. 205

206 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage Filter Actions tab. 4. Click Add. 5. On the Welcome page of the Filter Action Wizard, click Next. 6. In the Name box, type Permit, in the description box, type Permit unsecured IP packets to pass through, and then click Next. 7. On the Filter Action General Options page, click Permit, click Next, and then click Finish. To create the Request Authentication filter action 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage Filter Actions tab. 4. Click Add. 5. On the Welcome page of the Filter Action Wizard, click Next. 6. In the Name box, type Request Authentication (Optional), in the description box, type Requests authentication on both inbound and outbound connections, but allows fallback to clear if authentication fails, and then click Next. 7. On the Filter Action General Options page, click Negotiate security, and then click Next. 8. On the Communicating with computers that do not support IPsec page, click Allow unsecured communication if a secure connection cannot be established. This enables outbound fallback-to-clear behavior. In a later step, you will configure inbound fallback-to-clear behavior. 9. On the IP Traffic Security page, click Integrity only, and then click Next. This is equivalent to selecting ESP using SHA1 integrity and no encryption. You can add only one integrity and encryption algorithm combination at this time. You add the others (if required) in a later step. 10. On the Completing page, select Edit properties, and then click Finish. The Properties page for the filter action appears. 11. Select Accept unsecured communication, but always respond using IPsec to enable inbound fallback-to-clear behavior. The Allows fallback to unsecured communication if a secure connection cannot be established option is already selected because you enabled outbound fallback-to-clear behavior in an earlier step. 12. If you are deploying an isolated domain that includes an encryption zone or an isolated 206

207 server zone that requires encryption of all network traffic inbound to those servers, then you must add one or more quick mode algorithm combinations that enable encryption so that client computers using this rule can connect to the protected servers. On the Security Methods tab, click Add. 13. You can select Integrity and encryption if your design specifies using ESP with SHA1 as the integrity algorithm and 3DES as the encryption algorithm. If you require a different combination, then click Custom, click Data integrity and encryption (ESP), and then select the integrity and encryption algorithms required by your design. Caution We recommend that you do not use MD5 or DES in any combination. They are no longer considered to be secure, and are included for backward compatibility only. 14. If your design requires it, specify a custom session key lifetime by selecting either or both of the Generate a new key boxes, and then entering the appropriate size (in kilobytes) or time (in seconds). 15. Click OK to save the combination. 16. Click OK to add your completed combination to the list in the filter action. 17. When you have added security method combinations, click OK to save your filter action. To create the Require Authentication filter action 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage Filter Actions tab. 4. Click Add. 5. On the Welcome page of the Filter Action Wizard, click Next. 6. In the Name box, type Require Authentication, in the description box, type Requires authentication for all inbound connection attempts, but can fallback to clear when connecting outbound to a host that does not support IPsec, and then click Next. 7. On the Filter Action General Options page, click Negotiate security, and then click Next. 8. On the Communicating with computers that do not support IPsec page, select Allow unsecured communication if a secure connection cannot be established. This option enables outbound fallback-to-clear behavior. 9. On the IP Traffic Security page, click Integrity only, and then click Next. This is equivalent to selecting ESP using SHA1 with null encryption. You can add only one integrity and encryption algorithm combination at this time. You 207

208 add the others (if required) in a later step. Important Configure the same security method combinations in the same order, as you did for the Request Security filter action. 10. On the Completing page, check Edit properties, and then click Finish. The Properties page for the filter action appears. 11. Make sure that the Accept unsecured communication, but always respond using IPsec option is not selected to disable inbound fallback-to-clear behavior. The Allows fallback to unsecured communication if a secure connection cannot be established option is selected because you enabled outbound fallback-to-clear behavior in an earlier step. 12. If you are deploying an isolated domain that includes an encryption zone or an isolated server zone that requires encryption of all network traffic inbound to those servers, then you must add one or more quick mode algorithm combinations that enable encryption so that client computers using this rule can connect to the protected servers. On the Security Methods tab, click Add. 13. You can select Integrity and encryption if your design specifies using ESP with SHA1 as the integrity algorithm and 3DES as the encryption algorithm. If you require a different combination, then click Custom, click Data integrity and encryption (ESP), and select the integrity and encryption algorithms required by your design. Caution We recommend that you do not use MD5 or DES in any combination. They are no longer considered to be secure, and are included for backward compatibility only. 14. If your design requires it, specify a custom session key lifetime by selecting either or both of the Generate a new key boxes, and then entering the appropriate size (in kilobytes) or time (in seconds). 15. Click OK to save the combination. 16. Click OK to add your completed combination to the list in the filter action. 17. When you have added security method combinations, click OK to save your filter action. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. To create the Request Authentication and Encryption filter action 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 208

209 3. Select the Manage Filter Actions tab. 4. Click Add. 5. On the Welcome page of the Filter Action Wizard, click Next. 6. In the Name box, type Request Authentication and Encryption, in the description box, type Requests both authentication and encryption for connection attempts, but can fallback to clear when connecting outbound to a host that does not support IPsec., and then click Next. 7. On the Filter Action General Options page, click Negotiate security, and then click Next. 8. On the Communicating with computers that do not support IPsec page, select Do not allow unsecured communication if a secure connection cannot be established. This option enables outbound fallback-to-clear behavior. 9. On the IP Traffic Security page, click Integrity and encryption, and then click Next. This is equivalent to selecting ESP using SHA1 with 3DES encryption. Caution We recommend that you do not use MD5 or DES in any combination. They are no longer considered to be secure, and are included for backward compatibility only. 10. On the Completing page, select Edit properties, and then click Finish. The Properties page for the filter action appears. 11. Select the Accept unsecured communication, but always respond using IPsec option to enable inbound fallback-to-clear behavior. The Allows fallback to unsecured communication if a secure connection cannot be established option is selected because you enabled outbound fallback-to-clear behavior in an earlier step. 12. If your design requires it, specify a custom session key lifetime by selecting the security method in the list, and then clicking Edit. Change the security method to Custom, click Settings, select either or both of the Generate a new key boxes, and then enter the appropriate size (in kilobytes) or time (in seconds). Click OK. 13. When you have configured security method combinations, click OK to save your filter action. 14. When you have created and configured filter actions, click Close. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. To create the Require Authentication and Encryption filter action 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory 209

210 (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage Filter Actions tab. 4. Click Add. 5. On the Welcome page of the Filter Action Wizard, click Next. 6. In the Name box, type Require Authentication and Encryption, in the description box, type Requires both authentication and encryption for all inbound connection attempts, but can fallback to clear when connecting outbound to a host that does not support IPsec, and then click Next. 7. On the Filter Action General Options page, click Negotiate security, and then click Next. 8. On the Communicating with computers that do not support IPsec page, select Do not allow unsecured communication if a secure connection cannot be established. This option enables outbound fallback-to-clear behavior. 9. On the IP Traffic Security page, click Integrity and encryption, and then click Next. This is equivalent to selecting ESP using SHA1 with 3DES encryption. Caution We recommend that you do not use MD5 or DES in any combination. They are no longer considered to be secure, and are included for backward compatibility only. 10. On the Completing page, select Edit properties, and then click Finish. The Properties page for the filter action appears. 11. Make sure that the Accept unsecured communication, but always respond using IPsec option is not selected to disable inbound fallback-to-clear behavior. The Allows fallback to unsecured communication if a secure connection cannot be established option is selected because you enabled outbound fallback-to-clear behavior in an earlier step. 12. If your design requires it, specify a custom session key lifetime by selecting the security method in the list, and then clicking Edit. Change the security method to Custom, click Settings, select either or both of the Generate a new key boxes, and then enter the appropriate size (in kilobytes) or time (in seconds). Click OK when finished. 13. When you have configured security method combinations, click OK to save your filter action. 14. When you have created and configured filter actions, click Close. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. 210

211 Create Filter Lists for Clients of Isolated Server Running Earlier Versions of Windows IP Security rules for Windows 2000, Windows XP, and Windows Server 2003 are composed of filter lists, filter actions, and authentication methods. In this section, you create the filter lists for your isolated server zone clients that you later combine with filter actions and authentication method lists. The filter lists you need for either a domain isolation or server isolation scenario include: All ICMP Traffic. This filter list exists by default, but the procedure in this topic shows you how to re-create it, if necessary. This filter contains a single filter that matches any ICMP network packets. It is used to create an exemption rule that allows ICMP to work without authentication to simplify network troubleshooting. All Exempted Computers. This is a new filter that you must create. The list contains filters for any computers that cannot participate in IPsec authentication, and that do not work well with the delays caused by fallback-to-clear behavior. Note Remember that with the simplified IPsec policy described in article in the Microsoft Knowledge Base ( and implemented in Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows, the fallback-to-clear timeout is reduced from 3 seconds to 500 milliseconds. Consider not including in this list any servers whose network services work with fallback-to-clear to keep the list small and manageable. Include only those servers whose services do not work well even with the reduced fallback-to-clear timeout. All IP Traffic. This filter list exists by default, but the procedure in this topic shows you how to re-create it, if necessary. This filter list contains a single filter that matches traffic that is not better matched by another filter list. If all of the services on your network work well with the 500 ms fallback-to-clear timeout used by IPsec in Windows Server 2003 and earlier versions of Windows, then you can simplify your deployment by associating this filter list with the Request Security filter action in the GPO for the client computers that are members of the NAG. In that case, you do not need to create the IP Traffic to Isolated Servers filter list. If you must use the IP Traffic to Isolated Servers filter list, then associate this filter list with the Permit filter action in the GPO. IP Traffic to Isolated Servers. This filter list contains only the IP addresses of the computers in the isolated server zone. Create this filter list if you have network services that do not work well with the 500 ms fallback-to-clear timeout. It requires more maintenance, because you must keep the list of IP addresses up to date. This IP filter list is associated with the Request Security filter action in the GPO. Administrative credentials 211

212 To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the relevant GPOs. To create the All ICMP Traffic filter 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage IP Filter Lists tab. 4. If All ICMP Traffic appears in the list, and that filter list has not been modified, you can use it as is. If it does not exist, click Add. 5. In the Name text box, type All ICMP Traffic. 6. Provide a good description that will help you understand the purpose of the filter list when you refer to it in the future (for example, Matches all ICMP packets between this computer and any other computer). 7. Click Add. 8. On the Welcome page, click Next. 9. On the IP Filter Description and Mirrored Property page, type a good description that will help you understand the purpose of the IP filter when you refer to it in the future. 10. Select Mirrored, and then click Next. Mirroring allows the rule to apply to traffic flowing either way for a connection, without having to create a second rule in which the addresses are reversed. 11. On the IP Traffic Source page, select My IP Address from the list, and then click Next. 12. On the IP Traffic Destination page, select Any IP Address from the list, and then click Next. 13. On the IP Protocol Type page, select ICMP from the list, and then click Next. 14. On the Completing the IP Filter Wizard page, click Finish. To create the All Exempted Computers filter 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage IP Filter Lists tab. 4. Click Add. 5. In the Name text box, type All Exempted Computers. 212

213 6. Provide a good description that will help you to understand the purpose of the filter list when you refer to it in the future (for example, Matches all network traffic between this computer and any computer on the exemption list). 7. Click Add. 8. On the Welcome page, click Next. 9. On the IP Filter Description and Mirrored Property page, type a good description that will help you understand the purpose of the IP filter when you refer to it in the future (for example, All Exchange servers on the /24 Network). 10. Check Mirrored, and then click Next. Mirroring allows the rule to apply to traffic flowing either way for a connection, without having to create a second rule in which the addresses are reversed. 11. On the IP Traffic Source page, select My IP Address from the list, and then click Next. 12. On the IP Traffic Destination page, select one of the following: For a single computer by name, select A specific DNS Name, type the host name, and then click Next. On the Security Warning dialog box, the discovered IP addresses are displayed. Click Yes to add each address to the IP filter list. Warning The DNS name is not stored. It is only used to look up the IP address, which is stored in the IP filter. If the IP address of the computer changes, this value is not dynamically updated; you must manually update the IP filter with the new IP address. For a single computer by IP address, or for a group of computers by subnet address, select A specific IP Address or Subnet., type the IP address or subnet address in the text box, and then click Next. For a typical IPv4 subnet address, use the format ipaddress/nn, where nn is the number of bits in the subnet mask. For example, /24 indicates all IP addresses from to For computers performing a specified server role, select one of the following: DNS Servers, WINS Servers, DHCP Servers, or Default Gateway. This filter matches when the local computer attempts to connect to a computer for the specified service. 13. On the IP Protocol Type page, select Any from the list, and then click Next. 14. On the Completing the IP Filter Wizard page, click Finish. 15. Using the set of computers that you identified as your exemption list in your domain isolation design, repeat steps 6 through 13 for each computer or set of computers to complete the exemption list. 16. When the list is complete, click OK to save the exemption list. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. 213

214 To create the All IP Traffic filter 1. Open the Group Policy Management Console to IP Security Policies 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage IP Filter Lists tab. 4. If the list includes All IP Traffic, and that filter list has not been modified, you can use it as is. If it does not exist, click Add. 5. In the Name text box, type All IP Traffic. 6. Provide a good description that will help you understand the purpose of the filter list when you refer to it in the future (for example, Matches all IP packets from this computer to any other computer, except those protocols exempted by NoDefaultExempt registry key). 7. Click Add. 8. On the Welcome page, click Next. 9. On the IP Filter Description and Mirrored Property page, type a good description that will help you understand the purpose of the IP filter when you refer to it in the future. 10. Check Mirrored, and then click Next. Mirroring allows the rule to apply to traffic flowing either way for a connection, without having to create a second rule in which the addresses are reversed. 11. On the IP Traffic Source page, select My IP Address from the list, and then click Next. 12. On the IP Traffic Destination page, select Any IP Address from the list, and then click Next. 13. On the IP Protocol Type page, select Any from the list, and then click Next. 14. On the Completing the IP Filter Wizard page, click Finish. To create the IP Traffic to Isolated Servers filter 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage IP Filter Lists tab. 4. Click Add to create a new IP filter list. 5. In the Name text box, type IP Traffic to Isolated Servers. 6. Provide a good description that will help you understand the purpose of the filter list when you refer to it in the future (for example, Matches IP packets from this computer to the 214

215 servers in the Isolated Server zone). 7. Click Add to create a new IP filter. 8. On the Welcome page, click Next. 9. On the IP Filter Description and Mirrored Property page, type a good description that will help you understand the purpose of the IP filter when you refer to it in the future. For example, enter the name of the isolated server whose IP address is being added here. 10. Check Mirrored, and then click Next. Mirroring allows the rule to apply to traffic flowing either way for a connection, without having to create a second rule in which the addresses are reversed. 11. On the IP Traffic Source page, select My IP Address from the list, and then click Next. 12. On the IP Traffic Destination page, select A Specific IP Address or Subnet from the list. Important Alternatively, you can enter the address by using the A specific DNS Name option, but DNS name resolution only occurs when the filter list is created. If the IP address of the server changes, the policy is not updated automatically. To update the IP address, you must edit the policy. 13. Type the IP address of one of the isolated servers in the zone, and then click Next. 14. On the IP Protocol Type page, select Any from the list, and then click Next. 15. On the Completing the IP Filter Wizard page, click Finish. Create Filter Lists for Isolated Domain Computers and Isolated Servers Running Earlier Versions of Windows IP Security rules for Windows 2000, Windows XP, and Windows Server 2003 are composed of filter lists, filter actions, and authentication methods. In this section, you create the filter lists that you later combine with filter actions and authentication method lists. The filter lists you need for either a domain isolation or standalone server isolation scenario include: All IP Traffic. This filter list exists by default, but the procedure in this topic shows you how to re-create it, if necessary. This filter list contains a single filter that matches traffic that is not better matched by another filter list, and is initially associated with the Request Security filter action to create the basic domain isolation rule. After testing is complete, the rule is changed to use the Require Security filter action instead. All ICMP Traffic. This filter list exists by default, but the procedure in this topic shows you how to re-create it, if necessary. This filter contains a single filter that matches any ICMP network packets. It is used to create an exemption rule that allows ICMP to work without authentication to simplify network troubleshooting. 215

216 Important Because of its usefulness in troubleshooting network connectivity problems, we recommend that you use this filter to exempt all ICMP traffic unless your network risk analysis indicates a need to protect ICMP traffic. All Exempted Computers. This is a new filter that you must create. The list contains filters for any computers that cannot participate in IPsec authentication, and that do not work well with the delays caused by fallback-to-clear behavior. notedsdoc112778pads Security Note Adding computers to the exemption list for a zone reduces security because it permits computers in the zone to send network traffic that is unprotected by IPsec to the computers on the list. As discussed in the Windows Firewall with Advanced Security Design Guide, add only managed and trusted computers to the exemption list. Note Remember that with the simplified IPsec policy described in article in the Microsoft Knowledge Base ( and implemented in Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows, the fallback-to-clear timeout is reduced from 3 seconds to 500 milliseconds. Consider not including in this list any servers whose network services work with fallback-to-clear to keep the list small and manageable. Include only those servers whose services do not work well even with the reduced fallback-to-clear timeout. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create the All IP Traffic filter 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage IP Filter Lists tab. 4. If the list includes All IP Traffic, and that filter list has not been modified, you can use it as is. If it does not exist, click Add. 5. In the Name text box, type All IP Traffic. 6. Provide a good description that will help you understand the purpose of the filter list when you refer to it in the future (for example, Matches all IP packets from this computer to any other computer, except those protocols exempted by NoDefaultExempt 216

217 registry key). 7. Click Add. 8. On the Welcome page, click Next. 9. On the IP Filter Description and Mirrored Property page, type a good description that will help you understand the purpose of the IP filter when you refer to it in the future. 10. Check Mirrored, and then click Next. Mirroring allows the rule to apply to traffic flowing either way for a connection, without having to create a second rule in which the addresses are reversed. 11. On the IP Traffic Source page, select My IP Address from the list, and then click Next. 12. On the IP Traffic Destination page, select Any IP Address from the list, and then click Next. 13. On the IP Protocol Type page, select Any from the list, and then click Next. 14. On the Completing the IP Filter Wizard page, click Finish. To create the All ICMP Traffic filter 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage IP Filter Lists tab. 4. If All ICMP Traffic appears in the list, and that filter list has not been modified, you can use it as is. If it does not exist, click Add. 5. In the Name text box, type All ICMP Traffic. 6. Provide a good description that will help you understand the purpose of the filter list when you refer to it in the future (for example, Matches all ICMP packets between this computer and any other computer). 7. Click Add. 8. On the Welcome page, click Next. 9. On the IP Filter Description and Mirrored Property page, type a good description that will help you understand the purpose of the IP filter when you refer to it in the future. 10. Check Mirrored, and then click Next. Mirroring allows the rule to apply to traffic flowing either way for a connection, without having to create a second rule in which the addresses are reversed. 11. On the IP Traffic Source page, select My IP Address from the list, and then click Next. 12. On the IP Traffic Destination page, select Any IP Address from the list, and then click Next. 13. On the IP Protocol Type page, select ICMP from the list, and then click Next. 217

218 14. On the Completing the IP Filter Wizard page, click Finish. To create the All Exempted Computers filter 1. Open the Group Policy Management Console to IP Security Policies. 2. In the navigation pane, right-click IP Security Policies on Active Directory (YourDomainName), and then click Manage IP filter lists and filter actions. 3. Select the Manage IP Filter Lists tab. 4. Click Add. 5. In the Name text box, type All Exempted Computers. 6. Provide a good description that will help you understand the purpose of the filter list when you refer to it in the future (for example, Matches all network traffic between this computer and any computer on the exemption list). 7. Click Add. 8. On the Welcome page, click Next. 9. On the IP Filter Description and Mirrored Property page, type a good description that will help you understand the purpose of the IP filter when you refer to it in the future (for example, All Exchange servers on the /24 Network). 10. Select Mirrored, and then click Next. Mirroring allows the rule to apply to traffic flowing either way for a connection, without having to create a second rule in which the addresses are reversed. 11. On the IP Traffic Source page, select My IP Address from the list, and then click Next. 12. On the IP Traffic Destination page, select one of the following: For a single computer by name, select A specific DNS Name, type the host name, and then click Next. On the Security Warning dialog box, the discovered IP addresses are displayed. Click Yes to add each address to the IP filter list. Warning The DNS name is not stored. It is used only to look up the IP address, which is stored in the IP filter. If the IP address of the computer changes, this value is not dynamically updated; you must manually update the IP filter with the new IP address. For a single computer by IP address, or for a group of computers by subnet address, select A specific IP Address or Subnet., type the IP address or subnet address in the text box, and then click Next. For a typical IPv4 subnet address, use the format ipaddress/nn, where nn is the number of bits in the subnet mask. For example, /24 indicates all IP addresses from to For computers performing a specified server role, select one of the following: DNS Servers, WINS Servers, DHCP Servers, or Default Gateway. This filter matches 218

219 when the local computer attempts to connect to a computer for the specified service. 13. On the IP Protocol Type page, select Any from the list, and then click Next. 14. On the Completing the IP Filter Wizard page, click Finish. 15. Using the set of computers that you identified as your exemption list in your domain isolation design, repeat steps 6 through 13 for each computer or set of computers to complete the exemption list. 16. When the list is complete, click OK to save the exemption list. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create Inbound Rules to Support RPC on Windows Vista or Windows Server 2008 To allow inbound remote procedure call (RPC) network traffic, use the Windows Firewall with Advanced Security node in the Group Policy Management MMC snap-in to create two firewall rules. The first rule allows incoming network packets on TCP port 135 to the RPC Endpoint Mapper service. The incoming traffic consists of requests to communicate with a specified network service. The RPC Endpoint Mapper replies with a dynamically-assigned port number that the client must use to communicate with the service. The second rule allows the network traffic that is sent to the dynamically-assigned port number. Using the two rules configured as described in this topic helps to protect your computer by allowing network traffic only from computers that have received RPC dynamic port redirection and to only those TCP port numbers assigned by the RPC Endpoint Mapper. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. This topic describes how to create rules that allow inbound RPC network traffic. For other inbound port rule types, see: Create an Inbound Port Rule on Windows Vista or Windows Server 2008 Create an Inbound ICMP Rule on Windows Vista or Windows Server 2008 In this topic: To create a rule to allow inbound network traffic to the RPC Endpoint Mapper service To create a rule to allow inbound network traffic to RPC-enabled network services To create a rule to allow inbound network traffic to the RPC Endpoint Mapper service 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 219

220 2. In the navigation pane, click Inbound Rules. 3. Click Action, and then click New rule. 4. On the Rule Type page of the New Inbound Rule Wizard, click Custom, and then click Next. 5. On the Program page, click This Program Path, and then type %systemroot%\system32\svchost.exe. 6. Click Customize. 7. In the Customize Service Settings dialog box, click Apply to this service, select Remote Procedure Call (RPC) with a short name of RpcSs, click OK, and then click Next. 8. On the warning about Windows service-hardening rules, click Yes. 9. On the Protocol and Ports dialog box, for Protocol type, select TCP. 10. For Local port, select RPC Endpoint Mapper, and then click Next. 11. On the Scope page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click Next. 12. On the Action page, select Allow the connection, and then click Next. 13. On the Profile page, select the network location types to which this rule applies, and then click Next. Note If this GPO is targeted at server computers that never move, consider applying the rules to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public network location type. 14. On the Name page, type a name and description for your rule, and then click Finish. To create a rule to allow inbound network traffic to RPC-enabled network services 1. On the same GPO you edited in the preceding procedure, click Action, and then click New rule. 2. On the Rule Type page of the New Inbound Rule Wizard, click Custom, and then click Next. 3. On the Program page, click This Program Path, and then type the path to the executable file that hosts the network service. Click Customize. 4. In the Customize Service Settings dialog box, click Apply to this service, and then select the service that you want to allow. If the service does not appear in the list, then 220

221 click Apply to service with this service short name, and then type the short name of the service in the text box. 5. Click OK, and then click Next. 6. On the Protocol and Ports dialog box, for Protocol type, select TCP. 7. For Local port, select Dynamic RPC, and then click Next. 8. On the Scope page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click Next. 9. On the Action page, select Allow the connection, and then click Next. 10. On the Profile page, select the network location types to which this rule applies, and then click Next. Note If this GPO is targeted at server computers that never move, consider applying the rules to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public network location type. 11. On the Name page, type a name and description for your rule, and then click Finish. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows IP Security rules for Windows 2000, Windows XP, and Windows Server 2003 are composed of filter lists, filter actions, and authentication methods. In this section, you combine those elements into complete IPsec rules that can be used by the computers to which the GPO is applied. You need the same basic set of rules for the main isolated domain, boundary zone, or isolated server zone. Although you can reuse the IPsec filters and filter actions that you created for other GPOs, you must re-create the rules that combine them for each new GPO. The rules you must create include the following: A rule that permits ICMP traffic. This rule combines the All ICMP Traffic filter list with the Permit filter action. This rule must be added to all of the IPsec policies for all of the GPOs for computers that run Windows 2000, Windows XP, or Windows Server A rule that permits traffic from members of the exemption list. This rule combines the All Exempted Computers filter list with the Permit filter action. This rule must be added to all of the IPsec policies for all of the GPOs for computers that run Windows 2000, Windows XP, or Windows Server

222 A rule that requests authentication for all other traffic. This rule combines the All IP Traffic filter list with the Request Authentication filter action. This rule is used by the main isolated domain, the boundary zone, and the client computers that must communicate with servers in a standalone isolated server zone when encryption is not required. For the isolated domain and isolated server zones, you will later modify the rule to use the Require Security filter action after you confirm that the rules are working correctly. You do not modify the rule for the boundary zone. A rule that supports authentication for IP traffic to servers in a standalone isolated server zone. This rule combines the IP Traffic to Isolated Servers filter list with the Request Authentication filter action. This rule is used only by client computers that must be able to access servers in an isolated server zone when there is no isolated domain. You later modify this rule to require authentication after you have confirmed that the rules are working correctly. A rule that requires authentication and encryption for all other traffic. This rule combines the All IP Traffic filter list with the Request Authentication filter action. After testing has confirmed that network traffic is properly secured, the rule is modified to use the Require Both Authentication and Encryption filter action. This rule is used by the encryption zone in an isolated domain, and can be used by the servers in an isolated server zone. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create a rule that permits ICMP network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All ICMP Traffic, and then click Next. 8. On the Filter Action page, select Permit, and then click Next. 9. On the Completing the Security Rule Wizard page, click Finish. 10. Continue adding other required rules, including those shown in the next two procedures. When you have added the rules, make sure that the rules identified in this topic are selected, and that the <Dynamic> Default response rule is not selected, and then click OK to save your rules in the policy. 222

223 To create a rule that permits network traffic from members of the exemption list 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All Exempted Computers, and then click Next. 8. On the Filter Action page, select Permit, and then click Next. 9. On the Completing the Security Rule Wizard page, click Finish. 10. Continue adding other required rules, including the one in the next procedure. When you have added the rules, make sure that all of your rules are selected, and that the <Dynamic> Default response rule is not selected, and then click OK to save your rules in the policy. To create a rule that requests authentication for all other network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All IP Traffic, and then click Next. 8. On the Filter Action page, select Request Security (Optional), and then click Next. 9. On the Authentication Method page, select Active Directory default (Kerberos V5 protocol), and then click Next. You can add only one method on this wizard page. If your design requires more than one authentication method, you can another in the next step. 10. If you only need one authentication method, click Finish, and then skip to step 14. Otherwise, select Edit properties, and then click Finish. 11. On the New Rule Properties dialog box, select the Authentication Methods tab. 12. Click Add. 13. Configure your second authentication method. For example, if you want to add certificate- 223

224 based authentication for when you need to interoperate with computers running operating systems other than Windows: a. Select Use a certificate from this certification authority (CA). b. On the Warning dialog box, click Yes. c. Select the appropriate certification authority from the list, and then click OK. Important You must separately distribute the certificate to all computers that must be able to use this IPsec rule. You can use X.509 version 3 certificates either generated by a certification authority running on a server in your organization or purchased from a commercial certification authority. For more information, see Checklist: Implementing a Certificate-based Isolation Policy Design in this guide. 14. When you have added authentication methods, click OK to save your rule in the policy. To create a rule that requests authentication for all network traffic to a standalone isolated server zone 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select IP Traffic to Isolated Servers, and then click Next. 8. On the Filter Action page, select Request Security (Optional), and then click Next. 9. On the Authentication Method page, select Active Directory default (Kerberos V5 protocol), and then click Next. You can add only one method on this wizard page. If your design requires more than one authentication method, you can add another in the next step. 10. If you only need one authentication method, click Finish, and then skip to step 14. Otherwise, select Edit properties, and then click Finish. 11. On the New Rule Properties dialog box, select the Authentication Methods tab. 12. Click Add. 13. Configure your second authentication method. For example, if you want to add certificatebased authentication for when you need to interoperate with computers running operating systems other than Windows: 224

225 a. Select Use a certificate from this certification authority (CA). b. On the Warning dialog box, click Yes. c. Select the appropriate certification authority from the list, and then click OK. Important You must separately distribute the certificate to all computers that must be able to use this IPsec rule. You can use X.509 version 3 certificates either generated by a certification authority running on a server in your organization or purchased from a commercial certification authority. For more information, see Checklist: Implementing a Certificate-based Isolation Policy Design in this guide. 14. When you have added authentication methods, click OK to save your rule in the policy. To create a rule that requires both authentication and encryption for all other inbound network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All IP Traffic, and then click Next. 8. On the Filter Action page, select Require Both Authentication and Encryption, and then click Next. 9. On the Authentication Method page, select Active Directory default (Kerberos V5 protocol), and then click Next. You can add only one method on this wizard page. If your design requires more than one authentication method, you can add another in the next step. 10. If you only need the one authentication method, click Finish, and then skip to step 14. Otherwise, check Edit properties, and then click Finish. 11. On the New Rule Properties dialog box, select the Authentication Methods tab. 12. Click Add. 13. Configure your second authentication method. For example, if you want to add certificatebased authentication for when you need to interoperate with computers running operating systems other than Windows: a. Select Use a certificate from this certification authority (CA). 225

226 b. On the Warning dialog box, click Yes. c. Select the appropriate certification authority from the list, and then click OK. Important You must separately distribute the certificate to all computers that must be able to use this IPsec rule. You can use X.509 version 3 certificates either generated by a certification authority running on a server in your organization or purchased from a commercial certification authority. For more information, see Checklist: Implementing a Certificate-based Isolation Policy Design in this guide. 14. When you have added authentication methods, click OK to save your rule in the policy. 15. Continue adding any other rules required by your design. When you have added rules, make sure that all of your rules are selected, and that the <Dynamic> Default response rule is not selected, and then click OK to save your rules in the policy. Create IPsec Rules for an Isolated Server Zone on Earlier Versions of Windows IP Security rules for Windows 2000, Windows XP, and Windows Server 2003 are composed of filter lists, filter actions, and authentication methods. In this section, you combine those elements into complete IPsec rules that can be used by the computers to which the GPO is applied. In these procedures, you create the rules required for a server isolation zone that is part of an isolated domain by combining IPsec filters and filter actions. The rules you create include the following: A rule that permits ICMP traffic. This rule combines the All ICMP Traffic filter list with the Permit filter action. This rule is added to all of the IPsec policies for all of the GPOs for computers running Windows 2000, Windows XP, or Windows Server A rule that permits traffic from members of the exemption list. This rule combines the All Exempted Computers filter list with the Permit filter action. This rule is added to all IPsec policies for all of the GPOs for computers running Windows 2000, Windows XP, or Windows Server A rule that requires authentication for all other traffic. This rule initially combines the All IP Traffic filter list with the Request Authentication filter action. After testing has confirmed that the rules are working correctly, you will modify the rule to use the Require Security filter action. This rule is used by the servers in the isolated server zone when encryption is not required. A rule that requires authentication and encryption for all other traffic. This rule initially combines the All IP Traffic filter list with the Request Authentication and Encryption filter action. After testing has confirmed that the rules are working correctly, the rule is modified to use the Require Authentication and Encryption filter action. This rule is used by the servers in the isolated server zone when encryption, in addition to authentication, is required. 226

227 Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create a rule that permits ICMP network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All ICMP Traffic, and then click Next. 8. On the Filter Action page, select Permit, and then click Next. 9. On the Completing the Security Rule Wizard page, click Finish. To create a rule that permits network traffic from members of the exemption list 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All Exempted Computers, and then click Next. 8. On the Filter Action page, select Permit, and then click Next. 9. On the Completing the Security Rule Wizard page, click Finish. To create a rule that requires authentication for all other network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 227

228 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All IP Traffic, and then click Next. 8. On the Filter Action page, select Request Authentication, and then click Next. Note Later, after testing has confirmed that authentication is working correctly, you change the filter action by selecting Require Authentication. 9. On the Authentication Method page, select Active Directory default (Kerberos V5 protocol), and then click Next. You can add only one method on this wizard page. If your design requires more than one authentication method, see Add Authentication Methods to an IPsec Rule on Earlier Versions of Windows. 10. On the Completing page, click Finish to save your rule in the policy. To create a rule that requires both authentication and encryption for all other inbound network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All IP Traffic, and then click Next. 8. On the Filter Action page, select Require Both Authentication and Encryption, and then click Next. Note Later, after testing has confirmed that authentication is working correctly, you change the filter action by selecting Require Authentication. 9. On the Authentication Method page, select Active Directory default (Kerberos V5 protocol), and then click Next. You can add only one method on this wizard page. If your design requires more than one authentication method, see Add Authentication Methods to an IPsec Rule on Earlier Versions of Windows. 10. On the Completing page, click Finish to save your rule in the policy. 228

229 11. After you have added rules, make sure that all of your rules are selected, and that the <Dynamic> Default response rule is not selected, and then click OK to save your rules in the policy. Create IPsec Rules for Clients of an Isolated Server Zone on Earlier Versions of Windows IP Security rules for Windows 2000, Windows XP, and Windows Server 2003 are composed of filter lists, filter actions, and authentication methods. In this section, you combine those elements into complete IPsec rules that can be used by the computers to which the GPO is applied. In these procedures, you combine IPsec filters and filter actions to create the rules required for the client computers of a standalone server isolation zone that is not part of an isolated domain. Important The following steps use IPsec to communicate with all computers except ICMP and the exception list, and use fallback-to-clear behavior for computers outside of the isolated server zone. Alternatively, you can create a filter list that includes only the members of the isolated server zone, and then assign that filter list instead of the All IP Traffic filter list used in the last two procedures. This means that you must manually update the addresses in the filter list if the IP addresses of the isolated servers change. Failure to update the list results in failed connections to the server with the new address. The rules you create include the following: A rule that permits ICMP traffic. This rule combines the All ICMP Traffic filter list with the Permit filter action. This rule is added to all of the IPsec policies for all of the GPOs for computers running Windows 2000, Windows XP, or Windows Server A rule that permits traffic from members of the exemption list. This rule combines the All Exempted Computers filter list with the Permit filter action. This rule is added to all IPsec policies for all of the GPOs for computers running Windows 2000, Windows XP, or Windows Server A rule that requests authentication for all other traffic. This rule combines the All IP Traffic filter list with the Request Authentication filter action. This rule supports connecting to isolated servers that require authentication, but allows fallback-to-clear behavior for all other computers. A rule that requests authentication and encryption for all other traffic. This rule combines the All IP Traffic filter list with the Request Authentication and Encryption filter action. This rule supports connecting to isolated servers that require authentication and encryption, but allows fallback-to-clear behavior for all other computers. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. 229

230 To create a rule that permits ICMP network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All ICMP Traffic, and then click Next. 8. On the Filter Action page, select Permit, and then click Next. 9. On the Completing the Security Rule Wizard page, click Finish. To create a rule that permits network traffic from members of the exemption list 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All Exempted Computers, and then click Next. 8. On the Filter Action page, select Permit, and then click Next. 9. On the Completing the Security Rule Wizard page, click Finish. To create a rule that requests authentication for all other network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 230

231 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All IP Traffic, and then click Next. 8. On the Filter Action page, select Request Authentication, and then click Next. Remember that this rule must not be changed to require mode after testing is complete. 9. On the Authentication Method page, select Active Directory default (Kerberos V5 protocol), and then click Next. You can add only one method on this wizard page. If your design requires more than one authentication method, see Add Authentication Methods to an IPsec Rule on Earlier Versions of Windows. 10. On the Completing page, click Finish to save your rule in the policy. To create a rule that requests both authentication and encryption for all other inbound network traffic 1. Open the Group Policy Management Console to IP Security Policies. 2. In the details pane, double-click the IPsec policy in which you want to create the rule. 3. On the Rules tab, click Add. 4. On the Welcome page of the Security Rule Wizard, click Next. 5. On the Tunnel Endpoint page, select This rule does not specify a tunnel, and then click Next. 6. On the Network Type page, select All network connections, and then click Next. 7. On the IP Filter List page, select All IP Traffic, and then click Next. 8. On the Filter Action page, select Request Both Authentication and Encryption, and then click Next. Remember that this rule must not be changed to require mode after testing is complete. 9. On the Authentication Method page, select Active Directory default (Kerberos V5 protocol), and then click Next. You can add only one method on this wizard page. If your design requires more than one authentication method, see Add Authentication Methods to an IPsec Rule on Earlier Versions of Windows. 10. On the Completing page, click Finish to save your rule in the policy. 11. When you have added rules, make sure that all of your rules are selected, and that the <Dynamic> Default response rule is not selected, and then click OK to save your rules in the policy. Create WMI Filters for the GPO To make sure that each GPO associated with a group can only be applied to computers running the correct version of Windows, use the Group Policy Management MMC snap-in to create and assign WMI filters to the GPO. Although you can create a separate membership group for each 231

232 GPO, you would then have to manage the memberships of the different groups. Instead, use only a single membership group, and let WMI filters automatically ensure the correct GPO is applied to each computer. To create a WMI filter that queries for a specified version of Windows To link a WMI filter to a GPO Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. First, create the WMI filter and configure it to look for a specified version (or versions) of the Windows operating system. To create a WMI filter that queries for a specified version of Windows 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, and then click WMI Filters. 4. Click Action, and then click New. 5. In the Name text box, type the name of the WMI filter. Note Be sure to use a name that clearly indicates the purpose of the filter. Check to see if your organization has a naming convention. 6. In the Description text box, type a description for the WMI filter. For example, if the filter excludes domain controllers, you might consider stating that in the description. 7. Click Add. 8. Leave the Namespace value set to root\cimv2. 9. In the Query text box, type: select * from Win32OperatingSystem where Version like "6.0%" This query will return true for computers running Windows Vista or Windows Server To set a filter for Windows Server 2003, use "5.2%". For Windows XP, use "5.1%". For Windows 2000, use "5.0%". To specify multiple versions, combine them with or, as shown in the following:... where Version like "6.0%" or Version like "5.2%" The following query returns true for any computer running Windows 2000, Windows XP, or Windows Server 2003, and false for any other version of Windows. 232

233 ... where Version like "5.%" To restrict the query to only clients or only servers, add a clause that includes the ProductType parameter. To filter for client operating systems only, such as Windows XP or Windows Vista, use only ProductType="1". For server operating systems that are not domain controllers, use ProductType="3". For domain controllers only, use ProductType="2". This is a useful distinction, because you often want to prevent your GPOs from being applied to the domain controllers on your network. The following clause returns true for all computers that are not domain controllers:... where ProductType="1" or ProductType="3" The following complete query returns true for all computers running Windows Vista, and returns false for any server operating system or any other client operating system. select * from Win32OperatingSystem where Version like "6.0%" and ProductType="1" The following query returns true for any computer running Windows Server 2003, except domain controllers: select * from Win32OperatingSystem where Version like "5.2%" and ProductType="3" 10. Click OK to save the query to the filter. 11. Click Save to save your completed filter. After you have created a filter with the correct query, link the filter to the GPO. Filters can be reused with many GPOs simultaneously; you do not have to create a new one for each GPO if an existing one meets your needs. To link a WMI filter to a GPO 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, find and then click the GPO that you want to modify. 4. Under WMI Filtering, select the correct WMI filter from the list. 5. Click Yes to accept the filter. Important Computers running Windows 2000 cannot process WMI filters, and apply any GPO to which they have read and apply permissions. To prevent a computer running Windows 2000 from applying a GPO, you must use security group filtering. 233

234 Enable Predefined Inbound Rules on Windows Vista or Windows Server 2008 Windows Firewall with Advanced Security includes many predefined rules for common networking roles and functions. When you install a new server role on a computer or enable a network feature on a client computer, the installer typically enables the rules required for that role instead of creating new ones. When deploying firewall rules to the computers on the network, you can take advantage of these predefined rules instead of creating new ones. Doing this helps to ensure consistency and accuracy, because the rules have been thoroughly tested and are ready for use. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To deploy predefined firewall rules that allow inbound network traffic for common network functions 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Inbound Rules. 3. Click Action, and then click New rule. 4. On the Rule Type page of the New Inbound Rule Wizard, click Predefined, select the rule category from the list, and then click Next. 5. On the Predefined Rules page, the list of rules defined in the group is displayed. By default, they are all selected. For rules that you do not want to deploy, clear the check boxes next to the rules, and then click Next. 6. On the Action page, select Allow the connection, and then click Finish. The selected rules are added to the GPO and applied to the computers to which the GPO is assigned the next time Group Policy is refreshed. Note If this GPO is targeted at server computers that never move, consider modifying the rules to apply to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public network location type. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. 234

235 Enable Predefined Inbound Rules on Windows XP or Windows Server 2003 The firewall included with Windows Server 2003 with SP1 and Windows XP with SP2 supports a few predefined rules that you can include in a GPO. The support for these rules allows you to easily deploy firewall settings for commonly used network functions. Caution The predefined rules included with Windows Firewall in Windows Server 2003 and Windows XP do not have the flexibility of the rules for Windows Firewall with Advanced Security in Windows Server 2008 and Windows Vista. Use the predefined rules described here only for computers running Windows Server 2003 and Windows XP. For computers running Windows Vista or Windows Server 2008, see Enable Predefined Inbound Rules on Windows Vista or Windows Server Use the procedures in this topic to create firewall exception rules for: File and printer sharing ICMP Remote administration Remote Desktop UPnP Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. File and printer sharing To share files and printers with other computers, you must permit inbound requests from the client computers that want to access the files. Enabling this firewall exception rule opens UDP ports 137 and 138 and TCP ports 139 and 445 to the IP addresses specified in the rule. To enable inbound file and printer sharing network traffic 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO in which you want to create the rule, and then click Edit. 4. In the Group Policy Management Editor navigation pane, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, expand Network Connections, and then expand Windows Firewall. 5. Expand Domain Profile or Standard Profile. Rules created in the Domain Profile 235

236 section apply whenever the client computer is connected to a network on which it can contact a domain controller for its assigned Active Directory domain. Rules created in the Standard section apply when the computer cannot contact a domain controller for its domain. 6. In the details pane, double-click Windows Firewall: Allow inbound fire and printer sharing exception. 7. On the Setting tab, click Enabled. 8. In the Allow unsolicited incoming messages from these IP addresses text box, type the string that represents the addresses of the computers from which you are willing to accept this inbound network traffic. The string can be any of, or a comma-separated list of, the following items: Text An IP address, such as A subnet description, such as /24 localsubnet Meaning Network traffic from that IP address is allowed. Network traffic from any IP address on the specified subnet is allowed. Network traffic from any IP address recognized as being on the same subnet as the local computer is allowed. * Network traffic from any address on any network is allowed. Do not combine this with the other elements. For example, if you want to allow network traffic from only a computer at IP address , from any computer on your local subnet or network /24, then type , /24,localsubnet in the Allow unsolicited incoming messages from these IP addresses text box. 9. Click OK to save your changes. ICMP Internet Control Message Protocol (ICMP) is typically used to troubleshoot network connectivity problems and to enable computers to send flow control messages to each other to optimize network traffic throughput. Only the specified ICMP packet types are allowed inbound through Windows Firewall. To enable inbound ICMP network traffic 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 236

237 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO in which you want to create the rule, and then click Edit. 4. In the Group Policy Management Editor navigation pane, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, expand Network Connections, and then expand Windows Firewall. 5. Expand Domain Profile or Standard Profile. Rules created in the Domain Profile section apply whenever the client computer is connected to a network on which it can contact a domain controller for its assigned Active Directory domain. Rules created in the Standard section apply when the computer cannot contact a domain controller for its domain. 6. In the details pane, double-click Windows Firewall: Allow ICMP exceptions. 7. On the Setting tab, click Enabled. 8. Select the box next to each ICMP subtype that you want to allow through Windows Firewall. Because of their usefulness in diagnosing and troubleshooting, we recommend that you enable each subtype unless you have a security reason to prevent it. 9. Click OK to save your changes. Remote administration Remote administration allows you to perform tasks on one computer by using the Microsoft Management Console (MMC) or programs that use Windows Management Instrumentation (WMI) from a different computer over the network. These administrative tools typically use remote procedure call (RPC) and Distributed Component Object Model (DCOM). Enabling this firewall exception rule opens TCP ports 135 and 445 to the IP addresses specified in the rule. It also allows SVCHOST.EXE and LSASS.EXE to listen on dynamically assigned TCP ports in the range of 1024 to To enable inbound remote administration network traffic 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO in which you want to create the rule, and then click Edit. 4. In the Group Policy Management Editor navigation pane, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, expand Network Connections, and then expand Windows Firewall. 237

238 5. Expand Domain Profile or Standard Profile. Rules created in the Domain Profile section apply whenever the client computer is connected to a network on which it can contact a domain controller for its assigned Active Directory domain. Rules created in the Standard section apply when the computer cannot contact a domain controller for its domain. 6. In the details pane, double-click Windows Firewall: Allow inbound remote administration exception. 7. On the Setting tab, click Enabled. 8. In the Allow unsolicited incoming messages from these IP addresses text box, type the string that represents the addresses of the computers from which you are willing to accept this inbound network traffic. The string can be any of, or a comma-separated list of, the following items: Text An IP address, such as A subnet description, such as /24 localsubnet Meaning Network traffic from that IP address is allowed. Network traffic from any IP address on the specified subnet is allowed. Network traffic from any IP address recognized as being on the same subnet as the local computer is allowed. * Network traffic from any address on any network is allowed. Do not combine this with the other elements. For example, if you want to allow network traffic from only a computer at IP address , from any computer on your local subnet or network /24, then type , /24,localsubnet in the Allow unsolicited incoming messages from these IP addresses text box. 9. Click OK to save your changes. Remote Desktop Remote desktop enables you to connect to a remote computer and access all of your programs, files, and network resources. Enabling this firewall exception rule opens TCP port 3389 to the IP addresses specified in the rule. To enable inbound Remote Desktop network traffic 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 238

239 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO in which you want to create the rule, and then click Edit. 4. In the Group Policy Management Editor navigation pane, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, expand Network Connections, and then expand Windows Firewall. 5. Expand Domain Profile or Standard Profile. Rules created in the Domain Profile section apply whenever the client computer is connected to a network on which it can contact a domain controller for its assigned Active Directory domain. Rules created in the Standard section apply when the computer cannot contact a domain controller for its domain. 6. In the details pane, double-click Windows Firewall: Allow inbound Remote Desktop exception. 7. On the Setting tab, click Enabled. 8. In the Allow unsolicited incoming messages from these IP addresses text box, type the string that represents the addresses of the computers from which you are willing to accept this inbound network traffic. The string can be any of, or a comma separated list of, the following items: Text An IP address, such as A subnet description, such as /24 localsubnet Meaning Network traffic from that IP address is allowed. Network traffic from any IP address on the specified subnet is allowed. Network traffic from any IP address recognized as being on the same subnet as the local computer is allowed. * Network traffic from any address on any network is allowed. Do not combine this with the other elements. For example, if you want to allow network traffic from only a computer at IP address , from any computer on your local subnet or network /24, then type , /24,localsubnet in the Allow unsolicited incoming messages from these IP addresses text box. 9. Click OK to save your changes. 239

240 UPnP UPnP is a set of protocols that allow computers to easily detect, configure, and use peripheral devices connected through the network, such as network-attached printers, Internet gateways, and consumer electronics equipment. Enabling this firewall exception rule opens TCP port 2869 and UDP port 1900 to the IP addresses specified in the rule. To enable inbound UPnP network traffic 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO in which you want to create the rule, and then click Edit. 4. In the Group Policy Management Editor navigation pane, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, expand Network Connections, and then expand Windows Firewall. 5. Expand Domain Profile or Standard Profile. Rules created in the Domain Profile section apply whenever the client computer is connected to a network on which it can contact a domain controller for its assigned Active Directory domain. Rules created in the Standard section apply when the computer cannot contact a domain controller for its domain. 6. In the details pane, double-click Windows Firewall: Allow inbound UPnP framework exception. 7. On the Setting tab, click Enabled. 8. In the Allow unsolicited incoming messages from these IP addresses text box, type the string that represents the addresses of the computers from which you are willing to accept this inbound network traffic. The string can be any of, or a comma-separated list of, the following items: Text An IP address, such as A subnet description, such as /24 localsubnet Meaning Network traffic from that IP address is allowed. Network traffic from any IP address on the specified subnet is allowed. Network traffic from any IP address recognized as being on the same subnet as the local computer is allowed. * Network traffic from any address on any 240

241 network is allowed. Do not combine this with the other elements. For example, if you want to allow network traffic from only a computer at IP address , from any computer on your local subnet or network /24, then type , /24,localsubnet in the Allow unsolicited incoming messages from these IP addresses text box. 9. Click OK to save your changes. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Enable Predefined Outbound Rules on Windows Vista or Windows Server 2008 By default, Windows Firewall with Advanced Security allows all outbound network traffic unless it matches a rule that prohibits the traffic. Windows Firewall with Advanced Security includes many predefined outbound rules that can be used to block network traffic for common networking roles and functions. When you install a new server role on a computer or enable a network feature on a client computer, the installer can install, but typically does not enable, outbound block rules for that role. When deploying firewall rules to the computers on the network, you can take advantage of these predefined rules instead of creating new ones. Doing this helps to ensure consistency and accuracy, because the rules have been thoroughly tested and are ready for use. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To deploy predefined firewall rules that block outbound network traffic for common network functions 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the navigation pane, click Outbound Rules. 3. Click Action, and then click New rule. 4. On the Rule Type page of the New Inbound Rule Wizard, click Predefined, select the rule category from the list, and then click Next. 5. On the Predefined Rules page, the list of rules defined in the group is displayed. They are all selected by default. For rules that you do not want to deploy, clear the check boxes next to the rules, and then click Next. 6. On the Action page, select Block the connection, and then click Finish. The selected rules are added to the GPO. Note 241

242 If this GPO is targeted at server computers that never move, consider modifying the rules to apply to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card s cable. A disconnected network card is automatically assigned to the Public network location type. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Exempt ICMP from Authentication on Windows Vista and Windows Server 2008 This procedure shows you how to add exemptions for any network traffic that uses the ICMP protocol. Important Because of its usefulness in troubleshooting network connectivity problems, we recommend that you exempt all ICMP network traffic from authentication requirements unless your network risk analysis indicates a need to protect this traffic. Administrative credentials To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To exempt ICMP network traffic from authentication 1. Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. On the main Windows Firewall with Advanced Security page, click Windows Firewall Properties. 3. On the IPsec settings tab, change Exempt ICMP from IPsec to Yes, and then click OK. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Install Active Directory Certificate Services To use certificates in a server isolation or domain isolation design, you must first set up the infrastructure to deploy the certificates. This is called a public key infrastructure (PKI). The services required for a PKI are available in Windows Server 2008 in the form of the Active Directory Certificate Services (AD CS) role. Caution Creation of a full PKI for an enterprise environment with all of the appropriate security considerations included in the design is beyond the scope of this guide. The following 242

243 procedure shows you only the basics of installing an issuing certificate server; it is appropriate for a test lab environment only. For more information about deploying AD CS in a production environment, see Active Directory Certificate Services in the Windows Server 2008 Technical Library ( To perform this procedure, the computer on which you are installing AD CS must be joined to an Active Directory domain. Administrative credentials To complete this procedure, you must be a member of both the Domain Admins group in the root domain of your forest, and a member of the Enterprise Admins group. To install AD CS 1. Log on as a member of both the Enterprise Admins group and the root domain's Domain Admins group. 2. Click Start, and then click Server Manager. The Server Manager console opens. In Roles Summary, click Add roles. 3. The Add Roles Wizard opens. Click Next. 4. On the Select Server Roles page, in Roles, select Active Directory Certificate Services, and then click Next twice. 5. On the Select Role Services page, in Role services, verify that Certification Authority is selected, and then click Next. 6. On the Specify Setup Type page, verify that Enterprise is selected, and then click Next. 7. On the Specify CA Type page, verify that Root CA is selected, and then click Next. 8. On the Set Up Private Key page, verify that Create a new private key is selected, and then click Next. 9. On the Configure Cryptography for CA page, keep the default settings for CSP (RSA#Microsoft Software Key Storage Provider) and hash algorithm (sha1), and determine the best key character length for your deployment. Large key character lengths provide optimal security, but they can affect server performance. It is recommended that you keep the default setting of 2048 or, if appropriate for your deployment, reduce key character length to Click Next. 10. On the Configure CA Name page, keep the suggested common name for the CA or change the name according to your requirements, and then click Next. 11. On the Set Validity Period page, in Select validity period for the certificate generated for this CA, type the number and select a time value (Years, Months, Weeks, or Days). The default setting of five years is recommended. Click Next. 12. On the Configure Certificate Database page, in Certificate database location and Certificate database log location, specify the folder location for these items. If you specify locations other than the default locations, make sure that the folders are secured with access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. 243

244 13. Click Next, click Install, and then click Close. Link the GPO to the Domain After you create the GPO and configure it with security group filters and WMI filters, you must link the GPO to the container in Active Directory that contains all of the target computers. If the filters comprehensively control the application of the GPO to only the correct computers, then you can link the GPO to the domain container. Alternatively, you can link the GPO to a site container or organizational unit if you want to limit application of the GPO to that subset of computers. Administrative credentials To complete this procedure, you must be a member of the Domain Admins group, or otherwise be delegated permissions to modify the GPOs. To link the GPO to the domain container in Active Directory 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, and then expand YourDomainName. 4. Right-click YourDomainName, and then click Link an Existing GPO. 5. In the Select GPO dialog box, select the GPO that you want to deploy, and then click OK. 6. The GPO appears in the Linked Group Policy Objects tab in the details pane and as a linked item under the domain container in the navigation pane. 7. You can adjust the order of the linked GPOs to ensure that the higher priority GPOs are processed last. Select a GPO and click the up or down arrows to move it. The GPOs are processed by the client computer from the highest link order number to the lowest. Modify GPO Filters to Apply to a Different Zone or Version of Windows You must reconfigure your copied GPO so that it contains the correct security group and WMI filters for its new role. If you are creating the GPO for the isolated domain, use the Block members of a group from applying a GPO procedure to prevent members of the boundary and encryption zones from incorrectly applying the GPOs for the main isolated domain. Administrative credentials 244

245 To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. In this topic: Change the security group filter for a GPO Block members of a group from applying a GPO Remove a block for members of a group from applying a GPO Use the following procedure to change a group to the security filter on the GPO that allows group members to apply the GPO. You must remove the reference to the original group, and add the group appropriate for this GPO. To change the security group filter for a GPO 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, find and then click the GPO that you want to modify. 4. In the details pane, under Security Filtering, click the currently assigned security group, and then click Remove. 5. Now you can add the appropriate security group to this GPO. Under Security Filtering, click Add. 6. In the Select User, Computer, or Group dialog box, type the name of the group whose members are to apply the GPO, and then click OK. If you do not know the name, you can click Advanced to browse the list of groups available in the domain. Use the following procedure if you need to add a group to the security filter on the GPO that blocks group members from applying the GPO. This is typically used to prevent computers running Windows 2000 from applying a GPO, because Windows 2000 does not support WMI filters. This is also used on the GPOs for the main isolated domain to prevent members of the boundary and encryption zones from incorrectly applying the GPOs for the main isolated domain. To block members of group from applying a GPO 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, find and then click the GPO that you want to modify. 245

246 4. In the details pane, click the Delegation tab. 5. Click Advanced. 6. Under the Group or user names list, click Add. 7. In the Select User, Computer, or Group dialog box, type the name of the group whose members are to be prevented from applying the GPO, and then click OK. If you do not know the name, you can click Advanced to browse the list of groups available in the domain. 8. Select the group in the Group or user names list, and then select the boxes in the Deny column for both Read and Apply group policy. 9. Click OK, and then in the Windows Security dialog box, click Yes. 10. The group appears in the list with custom permissions. If, unlike the original, this copy of the GPO is to apply to computers running Windows 2000, then you must remove the Windows 2000 group from the custom permissions list. To remove a block for members of group from applying a GPO 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, find and then click the GPO that you want to modify. 4. In the details pane, click the Delegation tab. 5. In the Groups and users list, select the group that should no longer be blocked, and then click Remove. 6. In the message box, click OK. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Open the Group Policy Management Console to IP Security Policies Procedures in this guide that refer to GPOs for earlier versions of the Windows operating system instruct you to work with the IP Security Policy section in the Group Policy Management Console (GPMC). To open a GPO to the IP Security Policies section 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 246

247 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO you want to modify, and then click Edit. 4. In the navigation pane of the Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Windows Settings, expand Security Settings, and then click IP Security Policies on Active Directory (YourDomainName). Open the Group Policy Management Console to Windows Firewall To open a GPO to Windows Firewall with Advanced Security 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO you want to modify, and then click Edit. 4. In the navigation pane of the Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, expand Network Connections, and then expand Windows Firewall. Open the Group Policy Management Console to Windows Firewall with Advanced Security Most of the procedures in this guide instruct you to use Group Policy settings for Windows Firewall with Advanced Security. To open a GPO to Windows Firewall with Advanced Security 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO you want to modify, and then click Edit. 247

248 4. In the navigation pane of the Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Windows Settings, expand Security Settings, expand Windows Firewall with Advanced Security, and then expand Windows Firewall with Advanced Security - LDAP://cn={GUID},cn=. Open Windows Firewall with Advanced Security This procedure shows you how to open the Windows Firewall with Advanced Security MMC snap-in. Administrative credentials To complete this procedure, you must be a member of the Administrators group. For more information, see Additional considerations. Opening Windows Firewall with Advanced Security Using the Windows interface Using a command line To open Windows Firewall with Advanced Security by using the Windows interface 1. Click Start, click All Programs, click Administration Tools, and then click Windows Firewall with Advanced Security. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. To open Windows Firewall with Advanced Security by using a command line 1. From a command line, type: wf.msc 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. Additional considerations Although standard users can start the Windows Firewall with Advanced Security MMC snap-in, to change most settings the user must be a member of a group with the permissions to modify those settings, such as Administrators. 248

249 Restrict Server Access to Members of a Group Only After you have configured the IPsec connection security rules that force client computers to authenticate their connections to the isolated server, you must configure the rules that restrict access to only those computers or users who have been identified through the authentication process as members of the isolated server s access group. The way in which you restrict access to the isolated server depends on which version of the Windows operating system the server is running. If the server is running Windows Server 2008, then you create a firewall rule that specifies the user and computer accounts that are allowed. The authentication method used in the connection must support the account type specified. Remember that only Windows Vista and Windows Server 2008 support user-based authentication. If the server is running Windows Server 2003 or earlier, you do not use a firewall rule. Instead, you grant the user or computer accounts the Access this computer from the network user right and deny that right to all other accounts. In this topic: Create a firewall rule to access isolated servers running Windows Server 2008 or later Remove default user rights from isolated servers running Windows Server 2003 or earlier Grant user rights to access isolated servers running Windows Server 2003 or earlier Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. To create a firewall rule that grants access to an isolated server running Windows Server Open the Group Policy Management Console to Windows Firewall with Advanced Security. You must edit the GPO that applies settings to servers in the isolated server zone. 2. In the navigation pane, right-click Inbound Rules, and then click New Rule. 3. On the Rule Type page, click Custom, and then click Next. 4. If you must restrict access to a single network program, then you can select This program path, and specify the program or service to which to grant access. Otherwise, click All programs, and then click Next. 5. If you must restrict access to only some TCP or UDP port numbers, then enter the port numbers on the Protocol and Ports page. Otherwise, set Protocol type to Any, and then click Next. 6. On the Scope page, select Any IP address for both local and remote addresses, and then click Next. 249

250 7. On the Action page, click Allow the connection if it is secure. If required by your design, you can also select Require the connections to be encrypted. Click Next. 8. On the Users and Computers page, select the check box for the type of accounts (computer or user) you want to allow, click Add, and then enter the group account that contains the computer and user accounts permitted to access the server. Caution Remember that if you specify a user group on this page, your authentication scheme must include a method that uses user-based credentials. User-based credentials are only supported on versions of Windows that support AuthIP, such as Windows Vista and Windows Server Earlier versions of Windows and other operating systems that support IKE v1 only do not support user-based authentication; computers running those versions or other operating systems will not be able to connect to the isolated server through this firewall rule. To remove default user rights to access an isolated server running Windows Server 2003 or earlier 1. On the isolated server, click Start, click Administrative Tools, and then click Local Security Policy. 2. Expand Security Settings, expand Local Policies, and then click User Rights Assignment. 3. In the navigation pane, double-click Access this computer from the network. 4. Select Authenticated Users, and then click Remove. 5. Select Everyone, and then click Remove. 6. Click OK to save your changes, and close the Local Security Policy window. To grant user rights to access to an isolated server running Windows Server 2003 or earlier 1. On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. In the navigation pane, expand Forest: YourForestName, expand Domains, expand YourDomainName, expand Group Policy Objects, right-click the GPO for the isolated server to which you must restrict access, and then click Edit. 4. In the Group Policy Management Editor, expand Computer Configuration, expand 250

251 Policies, expand Windows Settings, expand Security Settings, expand Local Policies, and then select User Rights Assignment. 5. In the details pane, double-click Access this computer from the network. 6. In the Properties dialog box, select Define these policy settings, and then click Add User or Group. 7. Type the name of the isolated server access group, or click Browse to search for it. 8. Click OK in each dialog box to close it. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Start a Command Line as an Administrator This topic describes how to open a command prompt with full administrator permissions. If your user account is a member of the Administrators group, but is not the Administrator account itself, then, by default, the programs that you run only have standard user permissions. You must explicitly specify that you require the use of your administrative permissions by using one of the procedures in this topic. Administrative credentials To complete these procedures, you must be a member of the Administrators group. To start a command prompt as an administrator 1. Click Start, click All Programs, and then click Accessories. 2. Right-click Command prompt, and then click Run as administrator. 3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. To start a command prompt as an administrator (alternative method) 1. Click Start. 2. In the Start Search box, type cmd, and then press CTRL+SHIFT+ENTER. 3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. Turn on Windows Firewall and Configure Default Behavior To enable Windows Firewall and configure its default behavior, use the Windows Firewall with Advanced Security node (for Windows Vista or Windows Server 2008) or the Windows Firewall node (for Windows XP or Windows Server 2003) in the Group Policy Management MMC snap-in. Administrative credentials 251

252 To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. In this topic: To enable Windows Firewall and configure the default behavior on Windows XP or Windows Server 2003 To enable Windows Firewall and configure the default behavior on Windows Vista or Windows Server Open the Group Policy Management Console to Windows Firewall with Advanced Security. 2. In the details pane, in the Overview section, click Windows Firewall Properties. 3. For each network location type (Domain, Private, Public), perform the following steps. Note The steps shown here indicate the recommended values for a typical deployment. Use the settings that are appropriate for your firewall design. a. Click the tab that corresponds to the network location type. b. Change Firewall state to On (recommended). c. Change Inbound connections to Block (default). d. Change Outbound connections to Allow (default). To enable Windows Firewall and configure the default behavior on Windows XP or Windows Server Open the Group Policy Management Console to Windows Firewall. 2. In the navigation pane, click either Domain Profile or Standard Profile. 3. In the details pane, double-click Windows Firewall: Protect all network connections. 4. Click Enabled, and then click OK. 5. In the details pane, double-click Windows Firewall: Do not allow exceptions. 6. Click Disabled, and then click OK. Important Setting this value to Enabled causes Windows Firewall to ignore all of the firewall rules you define and block all unsolicited inbound network traffic. 252

253 Note Windows Firewall in Windows XP and Windows Server 2003 cannot block outbound network traffic. When enabled, it blocks all unsolicited inbound network traffic that does not match a firewall rule. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Use Netsh to Configure GPOs Most of the procedures in this guide use the Windows Firewall with Advanced Security user interface in the Group Policy Management Editor to create and configure settings in GPOs. The settings for GPOs for Windows Vista and Windows Server 2008 can also be configured from a command prompt or a batch file by using the advfirewall context of the Netsh command-line tool. The use of Netsh was supported in earlier versions of Windows for local firewall and IPsec configuration, but Windows Vista and Windows Server 2008 allow you to use the command to configure a GPO. The following procedure shows you how to configure a Netsh session to save its changes to a GPO instead of to the currently active firewall and IPsec configuration on your computer. Important The procedure applies only to settings for GPOs for Windows Vista and Windows Server Netsh commands for earlier versions of Windows do not support saving changes to a GPO. For more information, see Netsh Commands for Windows Firewall with Advanced Security ( Administrative credentials To complete this procedure, you must be a member of the Administrators group. To configure Netsh to save changes to a GPO 1. Start a command line as an administratorstart a Command Line as an Administrator. 2. Start Netsh by running the following command: netsh 3. Switch to the advfirewall context by running the following command: advfirewall 4. Specify the GPO that the commands you run in a Netsh session should modify by running the following command: set store gpo= domain.example.com\gpo_name where domain.example.com is the name of your Active Directory Domain Services (AD DS) domain, and gpo_name is the name of the GPO you want to modify. The quotation marks are required if there are any spaces in the GPO name. If Netsh returns Ok, then it found and successfully connected to the GPO. The 253

254 commands you enter are run against the contents of the GPO, instead of the current configuration of the local computer. This remains in effect until you change the output with another set store command or you end the Netsh session. 5. Run the commands that configure the rules and settings required by your design. Verify That Network Traffic Is Authenticated After you have configured your domain isolation rule to request, rather than require, authentication, you must confirm that the network traffic sent by the computers on the network is being protected by IPsec authentication as expected. If you switch your rules to require authentication before all of the computers have received and applied the correct GPOs, or if there are any errors in your rules, then communications on the network can fail. By first setting the rules to request authentication, any network connections that fail authentication can continue in clear text while you diagnose and troubleshoot. In these procedures, you confirm that the rules you deployed are working correctly. Your next steps depend on which zone you are working on: Main domain isolation zone. Before you convert your main domain isolation IPsec rule from request mode to require mode, you must make sure that the network traffic is protected according to your design. By configuring your rules to request and not require authentication at the beginning of operations, computers on the network can continue to communicate even when the main mode authentication or quick mode integrity and encryption rules are not working correctly. For example, if your encryption zone contains rules that require a certain encryption algorithm, but that algorithm is not included in a security method combination on the clients, then those clients cannot successfully negotiate a quick mode security association, and the server refuses to accept network traffic from the client. By first using request mode only, you have the opportunity to deploy your rules and then examine the network traffic to see if they are working as expected without risking a loss of communications. Boundary zone. Confirming correct operation of IPsec is the last step if you are working on the boundary zone GPO. You do not convert the GPO to require mode at any time. Encryption zone. Similar to the main isolation zone, after you confirm that the network traffic to zone members is properly authenticated and encrypted, you must convert your zone rules from request mode to require mode. Note In addition to the steps shown in this procedure, you can also use network traffic capture tools such as Microsoft Network Monitor, which can be downloaded from Network Monitor and similar tools allow you to capture, parse, and display the network packets received by the network adapter on your computer. Current versions of these tools include full support for IPsec. They can identify encrypted network packets, but they cannot decrypt them. 254

255 Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. In this topic: Procedure for computers running Windows Vista or Windows Server 2008 Procedure for computers running earlier versions of Windows For computers running Windows Vista or Windows Server 2008 To verify that network connections are authenticated by using the Windows Firewall with Advanced Security MMC snap-in 1. Click Start, in the Start Search box, type wf.msc, and then press ENTER. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. Windows Firewall with Advanced Security opens. 3. In the navigation pane, expand Monitoring, and then click Connection Security Rules. 4. The details pane displays the rules currently in effect on the computer. To display the Rule Source column a. In the Actions pane, click View, and then click Add/Remove Columns. b. In the Available columns list, select Rule Source, and then click Add. c. Use the Move up and Move down buttons to rearrange the order. Click OK when you are finished. It can take a few moments for the list to be refreshed with the newly added column. 1. Examine the list for the rules from GPOs that you expect to be applied to this computer. Note If the rules do not appear in the list, then troubleshoot the GPO security group and the WMI filters that are applied to the GPO. Make sure that the local computer is a member of the appropriate groups and meets the requirements of the WMI filters. 2. In the navigation pane, expand Security Associations, and then click Main Mode. The current list of main mode associations that have been negotiated with other computers appears in the details column. 3. Examine the list of main mode security associations for sessions between the local computer and the remote computer. Make sure that the 1st Authentication Method and 2nd Authentication Method columns contain expected values. If your rules specify only 255

256 a first authentication method, then the 2nd Authentication Method column displays No authentication. If you double-click the row, then the Properties dialog box appears with additional details about the security association. 4. In the navigation pane, click Quick mode. 5. Examine the list of quick mode security associations for sessions between the local computer and the remote computer. Make sure that the AH Integrity, ESP integrity, and ESP Confidentiality columns contain expected values. To verify that network connections are authenticated by using the Netsh command-line tool 1. Start a command line as an administratorstart a Command Line as an Administrator. 2. Type the command netsh advfirewall monitor show mmsa and then press ENTER. 3. Examine the output for an entry that includes your local IP address and the IP address of a remote computer that you want to verify. The First Auth and Second Auth lines indicate the authentication method used to establish the SA between these two endpoints. For computers running earlier versions of Windows To confirm that network connections are authenticated by using the IP Security Monitor MMC snap-in 1. Open the IP Security Monitor MMC console. To do so, click Start, and in the Start Search box, type mmc. Click New, click Add/Remove Snap-in, select IP Security Monitor in the list to the left, and then click Add. Click OK to open the snap-in. 2. Expand IP Security Monitor, expand Computer Name, and then click Active Policy. 3. In the details pane, examine the IP Security Policy details. If an unexpected or incorrect policy appears here, then you must investigate the following: Which GPOs were applied to this computer? Did it receive the correct or unexpected GPOs? If unexpected GPOs were applied, then investigate the security group and WMI filters used to control the application of your GPOs. Does more than one GPO have an assigned IP security policy? Windows supports only one assigned IP security policy at a time. You should make sure that only one GPO has an assigned IP security policy. If your design calls for multiple policies, then you must investigate the precedence of the GPOs and the order in which they are applied to determine which GPO s policy was assigned. 4. Connect from the remote computer to the local computer using network traffic that is expected to be protected by IPsec. 5. In the navigation pane, expand Main Mode, and then click Security Associations. 6. In the details pane, examine the main mode security associations. Look for connections between the local computer (IP address shown in the Me column) and the remote computer (IP address shown in the Peer column). The Authentication, Encryption, 256

257 Integrity, and Diffie-Hellman columns display details about the security association negotiated by the two computers. The main mode security association is the communications channel used to negotiate the quick mode security associations. 7. In the navigation pane, expand Quick Mode, and then click Security Associations. 8. In the details pane, examine the quick mode security associations negotiated between the local computer (Me) and the remote computer (Peer). The Protocol, My Port, and Peer Port columns describe any other filters on the traffic to which this security association applies. The AH integrity column displays the algorithm used if the AH protocol is protecting the data. The ESP Confidentiality column displays the encryption algorithm used if the data is encrypted. The ESP Integrity column displays the integrity algorithm used if ESP is protecting the data. If you arrived at this page by clicking a link in a checklist, use your browser s Back button to return to the checklist. Additional Resources For more information about the technologies discussed in this guide, see topics referenced in the following sections. Windows Firewall with Advanced Security Windows Firewall ( This TechNet page contains links to a variety of documents available for Windows Firewall, for Windows XP, Windows Server 2003, Windows Vista, and Windows Server Windows Firewall with Advanced Security Content Roadmap ( This topic describes the documents currently available in the Windows Technical Library for Windows Firewall with Advanced Security in Windows Vista and Windows Server Windows Firewall with Advanced Security - Diagnostics and Troubleshooting ( This article describes how Windows Firewall with Advanced Security works, what the common troubleshooting situations are, and which tools you can use for troubleshooting. IPsec IPsec ( This TechNet page contains links to a variety of documents currently available for Internet Protocol security (IPsec), for Windows XP, Windows Server 2003, and the version available as connection security rules in Windows Firewall with Advanced Security on Windows Vista and Windows Server Simplifying IPsec Policy with the Simple Policy Update ( 257

258 This article describes a downloadable update available for Windows XP with SP2 and Windows Server 2003 with SP1. The update changes the behavior of IPsec negotiation so that the IPsec policy rules can be simplified, in some cases significantly reducing the number of required IP filters and their ongoing maintenance. Server and Domain Isolation Server and Domain Isolation ( This TechNet page contains links to documentation about the most common uses for IPsec: server isolation and domain isolation. Documentation is available for Windows XP, Windows Server 2003, Windows Vista, and Windows Server Group Policy Group Policy is a key method for implementing firewall and server and domain isolation designs. For more information about Group Policy and related technologies, see: Group Policy ( This page contains links to the documents currently available for Group Policy, for both the version available in Windows XP and Windows Server 2003, and the version available in Windows Vista and Windows Server WMI Filtering Using GPMC ( HOWTO: Leverage Group Policies with WMI Filters ( This article describes how to create a WMI filter to set the scope of a GPO based on computer attributes, such as operating system. Active Directory Domain Services In Windows Server 2008, organizations can use AD DS to manage users and resources, such as computers, printers, or applications, on a network. Server isolation and domain isolation also require AD DS to use the Kerberos V5 protocol for IPsec authentication. For more information about AD DS and related technologies, see: Active Directory Domain Services ( 258