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.
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, e-mail
addresses, logos, people, places, and events depicted in examples herein are fictitious. No
association with any real company, organization, product, domain name, e-mail address, logo,
person, place, or event is intended or should be inferred.
© 2008 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.
Contents
Windows Firewall with Advanced Security Design Guide............................... 7
Understanding the Windows Firewall with Advanced Security Design Process ....................... 12
Identifying Your Windows Firewall with Advanced Security Deployment Goals ....................... 12
Protect Computers from Unwanted Network Traffic ............................................................. 13
Restrict Access to Only Trusted Computers ........................................................................ 14
Require Encryption When Accessing Sensitive Network Resources .................................... 16
Restrict Access to Only Specified Users or Computers ........................................................ 18
Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design ....... 20
Basic Firewall Policy Design ............................................................................................... 21
Domain Isolation Policy Design ........................................................................................... 23
Server Isolation Policy Design ............................................................................................. 25
Certificate-based Isolation Policy Design ............................................................................. 27
Evaluating Windows Firewall with Advanced Security Design Examples ................................. 28
Firewall Policy Design Example .......................................................................................... 28
Domain Isolation Policy Design Example ............................................................................ 33
Server Isolation Policy Design Example .............................................................................. 35
Certificate-based Isolation Policy Design Example .............................................................. 39
Designing a Windows Firewall with Advanced Security Strategy ............................................. 40
Gathering the Information You Need ................................................................................... 42
Gathering Information about Your Current Network Infrastructure .................................... 43
Gathering Information about Your Active Directory Deployment ....................................... 47
Gathering Information about Your Computers .................................................................. 48
Gathering Other Relevant Information .............................................................................. 50
Determining the Trusted State of Your Computers .............................................................. 53
Planning Your Windows Firewall with Advanced Security Design ........................................... 59
Planning Settings for a Basic Firewall Policy ....................................................................... 61
Planning Domain Isolation Zones ........................................................................................ 63
Exemption List ................................................................................................................. 63
Isolated Domain .............................................................................................................. 65
Boundary Zone ................................................................................................................ 69
Encryption Zone .............................................................................................................. 73
Planning Server Isolation Zones.......................................................................................... 76
Planning Certificate-based Authentication ........................................................................... 81
Documenting the Zones ...................................................................................................... 82
Planning Group Policy Deployment for Your Isolation Zones ............................................... 83
Planning Isolation Groups for the Zones .......................................................................... 84
Planning Network Access Groups .................................................................................... 85
Planning the GPOs .......................................................................................................... 87
Firewall GPOs .............................................................................................................. 88
GPO_DOMISO_Firewall_2008_Vista ........................................................................... 89
GPO_DOMISO_Firewall_2003_XP .............................................................................. 90
Isolated Domain GPOs ................................................................................................. 91
GPO_DOMISO_IsolatedDomain_Clients_WinVista ...................................................... 91
GPO_DOMISO_IsolatedDomain_Servers_WS2008 ..................................................... 93
GPO_DOMISO_IsolatedDomain_Clients_WinXP ......................................................... 94
GPO_DOMISO_IsolatedDomain_Servers_WS2003 ..................................................... 96
GPO_DOMISO_IsolatedDomain_Servers_Win2000 ..................................................... 96
Boundary Zone GPOs .................................................................................................. 97
GPO_DOMISO_Boundary_WS2008 ............................................................................ 97
GPO_DOMISO_Boundary_WS2003 ............................................................................ 98
Encryption Zone GPOs................................................................................................. 99
GPO_DOMISO_Encryption_WS2008 ......................................................................... 100
GPO_DOMISO_Encryption_WS2003 ......................................................................... 101
Server Isolation GPOs ................................................................................................ 102
Planning GPO Deployment ............................................................................................ 103
Appendix A: Sample GPO Template Files for Settings Used in this Guide ............................ 109
Additional Resources ........................................................................................................... 117
Windows Firewall with Advanced Security Deployment Guide .................. 119
Planning to Deploy Windows Firewall with Advanced Security .............................................. 121
Implementing Your Windows Firewall with Advanced Security Design Plan .......................... 122
Checklist: Creating Group Policy Objects ............................................................................. 124
Checklist: Implementing a Basic Firewall Policy Design ........................................................ 126
Checklist: Configuring Basic Firewall Settings ................................................................... 128
Checklist: Creating Inbound Firewall Rules ....................................................................... 129
Checklist: Creating Outbound Firewall Rules ..................................................................... 130
Checklist: Implementing a Domain Isolation Policy Design ................................................... 132
Checklist: Configuring Rules for the Isolated Domain ........................................................ 133
Checklist: Configuring Rules for the Boundary Zone .......................................................... 137
Checklist: Configuring Rules for the Encryption Zone ........................................................ 140
Checklist: Configuring Rules for an Isolated Server Zone .................................................. 142
Checklist: Implementing a Standalone Server Isolation Policy Design ................................... 148
Checklist: Configuring Rules for Servers in a Standalone Isolated Server Zone ................. 149
Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone ....................... 155
Checklist: Implementing a Certificate-based Isolation Policy Design ..................................... 159
Procedures Used in This Guide ............................................................................................ 160
Add Authentication Methods to an IPsec Rule on Earlier Versions of Windows .................. 162
Add Production Computers to the Membership Group for a Zone ...................................... 162
Add Test Computers to the Membership Group for a Zone ................................................ 164
Assign an IPsec Policy to a GPO for Earlier Versions of Windows ..................................... 166
Assign Security Group Filters to the GPO ......................................................................... 167
Change Rules from Request to Require Mode .................................................................. 169
Configure Authentication Methods on Windows Vista and Windows Server 2008 .............. 170
Configure Data Protection (Quick Mode) Settings on Windows Vista and Windows Server
2008 .............................................................................................................................. 173
Configure Group Policy to Autoenroll and Deploy Certificates............................................ 175
Configure Key Exchange (Main Mode) Settings on Earlier Versions of Windows ............... 176
Configure Key Exchange (Main Mode) Settings on Windows Vista and Windows Server 2008
...................................................................................................................................... 177
Configure Settings to Optimize IPsec Behavior on Earlier Versions of Windows ................ 178
Configure the Rules to Require Encryption on Windows Vista and Windows Server 2008.. 180
Configure the Windows Firewall Log ................................................................................. 181
Configure the Workstation Authentication Certificate Template.......................................... 183
Configure Windows Firewall to Suppress Notifications When a Program Is Blocked .......... 184
Confirm That Certificates Are Deployed Correctly.............................................................. 185
Copy a GPO to Create a New GPO .................................................................................. 186
Create a Group Account in Active Directory ...................................................................... 187
Create a Group Policy Object............................................................................................ 188
Create a New IP Security Policy in a GPO for Earlier Versions of Windows ....................... 189
Create an Authentication Exemption List Rule on Windows Vista and Windows Server 2008
...................................................................................................................................... 190
Create an Authentication Request Rule on Windows Vista and Windows Server 2008 ...... 191
Create an Inbound ICMP Rule on Windows Vista or Windows Server 2008 ....................... 194
Create an Inbound Port Rule on Windows Vista or Windows Server 2008 ......................... 195
Create an Inbound Port Rule on Windows XP or Windows Server 2003 ............................ 197
Create an Inbound Program or Service Rule on Windows Vista or Windows Server 2008 . 199
Create an Inbound Program Rule on Windows XP or Windows Server 2003 ..................... 200
Create an Outbound Port Rule on Windows Vista or Windows Server 2008 ...................... 201
Create an Outbound Program or Service Rule on Windows Vista or Windows Server 2008
...................................................................................................................................... 203
Create Filter Actions on Earlier Versions of Windows ........................................................ 204
Create Filter Lists for Clients of Isolated Server Running Earlier Versions of Windows ...... 211
Create Filter Lists for Isolated Domain Computers and Isolated Servers Running Earlier
Versions of Windows ..................................................................................................... 215
Create Inbound Rules to Support RPC on Windows Vista or Windows Server 2008 .......... 219
Create IPsec Rules for an Isolated Domain on Earlier Versions of Windows ...................... 221
Create IPsec Rules for an Isolated Server Zone on Earlier Versions of Windows ............... 226
Create IPsec Rules for Clients of an Isolated Server Zone on Earlier Versions of Windows229
Create WMI Filters for the GPO ........................................................................................ 231
Enable Predefined Inbound Rules on Windows Vista or Windows Server 2008 ................. 234
Enable Predefined Inbound Rules on Windows XP or Windows Server 2003 .................... 235
Enable Predefined Outbound Rules on Windows Vista or Windows Server 2008 ............... 241
Exempt ICMP from Authentication on Windows Vista and Windows Server 2008 .............. 242
Install Active Directory Certificate Services........................................................................ 242
Link the GPO to the Domain ............................................................................................. 244
Modify GPO Filters to Apply to a Different Zone or Version of Windows............................. 244
Open the Group Policy Management Console to IP Security Policies ................................ 246
Open the Group Policy Management Console to Windows Firewall ................................... 247
Open the Group Policy Management Console to Windows Firewall with Advanced Security
...................................................................................................................................... 247
Open Windows Firewall with Advanced Security ............................................................... 248
Restrict Server Access to Members of a Group Only ......................................................... 249
Start a Command Line as an Administrator ....................................................................... 251
Turn on Windows Firewall and Configure Default Behavior ............................................... 251
Use Netsh to Configure GPOs .......................................................................................... 253
Verify That Network Traffic Is Authenticated ...................................................................... 254
Additional Resources ........................................................................................................... 257
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
http://go.microsoft.com/fwlink/?linkid=64343
•
Introduction to Server and Domain Isolation
http://go.microsoft.com/fwlink/?linkid=94632
For the complete list of documentation for Windows Firewall with Advanced Security, see the
Windows Firewall with Advanced Security Content Roadmap at
http://go.microsoft.com/fwlink/?LinkID=64342.
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
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:
•
http://go.microsoft.com/fwlink/?linkid=102569 (Web page)
8
•
http://go.microsoft.com/fwlink/?linkid=102571 (Downloadable Word document)
Terminology used in this guide
The following table identifies and defines terms used throughout this guide.
Term
Definition
Active Directory domain
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.
Authentication
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.
Boundary zone
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.
Connection security rule
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.
Certificate-based isolation
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
Term
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).
Domain isolation
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.
Encryption zone
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.
Firewall rule
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.
Internet Protocol security (IPsec)
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).
IPsec policy
A collection of connection security rules that
10
Term
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.
Isolated domain
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.
Server isolation
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.
Solicited network traffic
Network traffic that is sent in response to a
request. By default, Windows Firewall with
Advanced Security allows all solicited network
traffic through.
Unsolicited network traffic
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
Term
Definition
Zone
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
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
Reference links
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.
Predefined deployment goals:
Map one goal or a combination of the
predefined deployment goals to an existing
Windows Firewall with Advanced Security
design.
•
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
Based on the status of your current
•
infrastructure, document your deployment goals
for your Windows Firewall with Advanced
•
Security design into a deployment plan.
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
•
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
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
•
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
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
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
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
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
Domain Isolation
Server Isolation
Certificate-based
Policy Design
Policy Design
Policy Design
Isolation Policy
Design
Protect Computers
from Unwanted
Network Traffic
Yes
Yes
Yes
Yes
Restrict Access to
Only Trusted
Computers
-
Yes
Yes
Yes
Restrict Access to
Only Specified
Users or
Computers
-
-
Yes
Yes
Require Encryption
When Accessing
Sensitive Network
Resources
-
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
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 2008. 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
•
By default, in new installations, Windows Firewall is turned on in both Windows Vista and
Windows Server 2008. 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
http://go.microsoft.com/fwlink/?linkid=104976.
•
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 http://go.microsoft.com/fwlink/?linkid=98308.
Next: Domain Isolation Policy Design
22
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
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
•
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 http://go.microsoft.com/fwlink/?linkid=98308.
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
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
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
http://go.microsoft.com/fwlink/?linkid=98308.
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
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 http://go.microsoft.com/fwlink/?linkid=98308.
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
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 2008.
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
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 2003
30
•
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
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
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
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
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
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
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
•
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
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 nonWindows 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
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
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 2008. However, doing this prevents you from taking advantage of all the new features
performance improvements included in Windows Vista and Windows Server 2008.
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 2008. If you choose to do this then you must
41
use the Windows Firewall and IPsec guidance applicable to Windows XP and Windows
Server 2003. Design and deployment guidance for those technologies is available on the
Web at "Server and Domain Isolation Using IPsec and Group Policy"
(http://go.microsoft.com/fwlink/?linkid=110400). It is also available in downloadable form at
http://go.microsoft.com/fwlink/?linkid=110401.
•
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 2003. 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
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
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 10.0.1.10 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 (ESPNull).
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 (http://go.microsoft.com/fwlink/?linkid=94770).
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 http://go.microsoft.com/fwlink/?LinkId=45084. This is a client-side update only, and
44
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 http://go.microsoft.com/fwlink/?LinkId=45080.
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
http://go.microsoft.com/fwlink/?LinkId=45083.
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
http://go.microsoft.com/fwlink/?LinkId=45081.
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 http://go.microsoft.com/fwlink/?LinkId=45084. 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
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
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 1024.
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
•
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
•
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 http://go.microsoft.com/fwlink/?linkid=110412.
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 2008. In addition, PowerShell is available as a free
49
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”
(http://go.microsoft.com/fwlink/?linkid=110413).
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
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
http://go.microsoft.com/fwlink/?LinkId=45087.
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
http://go.microsoft.com/fwlink/?LinkId=45088.
51
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
http://go.microsoft.com/fwlink/?LinkId=45085.
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
http://go.microsoft.com/fwlink/?LinkId=45089
•
"IPsec is not designed for failover" at http://go.microsoft.com/fwlink/?LinkId=45091
•
"How to Configure IPsec on an Exchange Server 2003 Back-End Server That Is Running on
a Windows Server 2003 Server Cluster" at http://go.microsoft.com/fwlink/?LinkId=45092
IPsec improvements for clusters running Windows Server 2008
52
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
http://go.microsoft.com/fwlink/?linkid=94770.
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
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 2003.
•
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
with an appropriate client. For more information, see
http://go.microsoft.com/fwlink/?linkid=110412.
•
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
http://go.microsoft.com/fwlink/?linkid=110479.
•
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
•
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] x86based 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
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
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
Software
Configuration
reqs met
reqs met
required
Details
Projected
CLIENT001
No
No
Upgrade
hardware and
software.
Current operating
system is
Windows 2000.
Old hardware is
not compatible
with
Windows Vista.
$??
SERVER001
Yes
No
Join trusted
domain and
upgrade from
Windows 2000 to
Windows
Server 2008.
No antivirus
software present.
$??
cost
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 http://go.microsoft.com/fwlink/?linkid=69783.
For more information about WMI, see "Windows Management Instrumentation" at
http://go.microsoft.com/fwlink/?linkid=110483.
Next: Planning Your Windows Firewall with Advanced Security Design
58
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 (http://go.microsoft.com/fwlink/?linkid=129230).
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
(http://go.microsoft.com/fwlink/?linkid=129229).
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
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
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
•
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
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
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
http://go.microsoft.com/fwlink/?linkid=110514) 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
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
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
•
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 810207 at
http://go.microsoft.com/fwlink/?linkid=110516. 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 120492 at http://go.microsoft.com/fwlink/?linkid=120492. 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 NATT, 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
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 810207 at http://go.microsoft.com/fwlink/?linkid=110516. 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 2000.
c.
If required by the organization, enable IPsec over NAT-T. This setting is documented in
Knowledge Base article 120492 at http://go.microsoft.com/fwlink/?linkid=120492. 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 NATT, 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 2003. To use this, you must have
already deployed the update available for free download (for Windows Server 2003) from
the Knowledge Base article 914841 at http://go.microsoft.com/fwlink/?linkid=110514.
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
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
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
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
•
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 810207 at
http://go.microsoft.com/fwlink/?linkid=110516. 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 120492 at http://go.microsoft.com/fwlink/?linkid=120492. 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 NATT, 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
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
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 810207 at
http://go.microsoft.com/fwlink/?linkid=110516. 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 120492 at http://go.microsoft.com/fwlink/?linkid=120492. 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 NATT, 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
•
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
b. Enforce the default IPsec protocol exemptions. This setting is documented in Knowledge
Base article 810207 at http://go.microsoft.com/fwlink/?linkid=110516. 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 2000.
c.
If required by the organization, enable IPsec over NAT-T. This setting is documented in
Knowledge Base article 120492 at http://go.microsoft.com/fwlink/?linkid=120492. 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 NATT, 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 2003. To use this, you must have
already deployed the update available for free download (for Windows Server 2003) from
the Knowledge Base article 914841 at http://go.microsoft.com/fwlink/?linkid=110514.
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
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
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
b. Enforce the default IPsec protocol exemptions of ISAKMP only. This setting is
documented in Knowledge Base article 810207 at
http://go.microsoft.com/fwlink/?linkid=110516. 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 120492 at http://go.microsoft.com/fwlink/?linkid=120492. 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 NATT, 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
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 810207 at http://go.microsoft.com/fwlink/?linkid=110516. 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 2000.
c.
If required by the organization, enable IPsec over NAT-T. This setting is documented in
Knowledge Base article 120492 at http://go.microsoft.com/fwlink/?linkid=120492. 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 NATT, 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 2003. To use this, you must have
already deployed the update available for free download (for Windows Server 2003) from
the Knowledge Base article 914841 at http://go.microsoft.com/fwlink/?linkid=110514.
Note
For a sample template for these registry settings, see Appendix A: Sample GPO
Template Files for Settings Used in this Guide.
80
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 http://go.microsoft.com/fwlink/?linkid=110820.
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
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
CLIENT001
Hardware
Software
Configuration
reqs met
reqs met
required
Details
Projected
No
No
Upgrade
Current
$??
hardware
operating system
and software. is
Windows NT 4.0.
Old hardware not
compatible with
Windows XP or
Windows Vista.
Group
cost
Isolated
domain
82
Host name
Hardware
Software
Configuration
Details
Projected
Group
reqs met
reqs met
required
SERVER002
Yes
No
Join trusted
No antivirus
$??
domain,
software present.
upgrade from
Windows NT
4.0 to
Windows
Server 2008
Encryption
SENSITIVE001
Yes
Yes
Not required.
Running
Windows
Server 2008.
Ready for
inclusion.
$0
Isolated
server (in
zone by
itself)
PRINTSVR1
Yes
Yes
Not required.
Running
Windows
Server 2003.
Ready for
inclusion.
$0
Boundary
cost
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
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
Description
CG_DOMISO_No_IPsec
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.
CG_DOMISO_IsolatedDomain
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.
CG_DOMISO_Boundary
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
Group name
Description
not required.
CG_DOMISO_Encryption
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.
CG_SRVISO_ServerRole
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.
CG_DOMISO_WINDOWS2000
A universal group of computer accounts for all
computers in the organization that are running
Windows 2000. 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
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
NAG Member Users,
Description
Computers, or Groups
CG_NAG_ServerRole_Users
Svr1AdminA
Svr1AdminB
Group_AppUsers
AppSvcAccount
CG_NAG_ServerRole_Computers
Desktop1
Desktop2
AdminDT1
AppAdminDT1
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
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
•
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 http://go.microsoft.com/fwlink/?linkid=110826.
•
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 2008. 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
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
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.
Firewall rules
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
•
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 1551.
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
Disabled
Not configured
Protect all network
connections
Enabled
Enabled
Do not allow exceptions
Disabled
Disabled
Allow inbound file and
printer sharing exception
Enabled, with address set to
192.168.0.0/16
Not configured
Allow ICMP exceptions
Enabled, all check boxes
selected
Not configured
Prohibit notifications
Enabled
Not configured
Allow local port exceptions
Disabled
Not configured
Allow inbound remote
administration exception
Enabled, with address set to
192.168.0.0/16
Not configured
Allow inbound Remote
Desktop exceptions
Enabled, with address set to
192.168.0.0/16
Not configured
Allow inbound UPnP
framework exceptions
Enabled, with address set to
192.168.0.0/16
Not configured
90
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:192.168.0.0\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
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
Encryption
Secure Hash Algorithm (SHA-1)
Advanced Encryption Standard (AES-128)
SHA-1
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
Protocol
Integrity
Encryption
Key Lifetime
(minutes/KB)
ESP
SHA-1
AES-128
60/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 2008.
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
piece of the GPO for Windows Vista, and importing it to the GPO for Windows Server 2008. 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
Name
Request Security
Method
Algorithms
Key lifetime
AH|ESP:{integrity/encryption}
(KB/seconds)
Negotiate
ESP:SHA1/none
100,000/3600
Selected
ESP:SHA1/3DES
Selected
Allow Traffic
Permit
n/a
Not applicable
Negotiate
ESP:SHA1/none
100,000/3600
Cleared
ESP:SHA1/3DES
Not applicable
Not applicable
Require Security
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
ICMP traffic
Allow Traffic
Not applicable
Exemption List
Allow Traffic
Not applicable
Certificate from internal CA
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
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 2000. 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 2003.
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 2003. 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
•
The Woodgrove Bank GPO for Windows 2000 Server is currently identical to the GPO for
Windows Server 2003. 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 2000.
•
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
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 2008.
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 2003.
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
•
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
•
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 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
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 2008.
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_WS2003
100
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 2003.
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
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 2003.
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
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 2008.
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
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
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
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 2008.
•
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 2008.
•
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 2008.
•
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
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 2008.
•
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 2008.
107
•
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 2008.
•
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 2008.
•
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 2008.
•
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
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="2008-05-30 20:37:31"
uid="{49FD6551-80DA-4876-9335-623F2575E27B}"
desc="&lt;b&gt;Enable IPsec over NAT-T&lt;/b&gt;&lt;p&gt;
109
This setting configures whether computers running Windows 2003 and Windows XP
can make IPsec connections to servers behind NAT-enabled routers.&lt;p&gt;
&lt;b&gt;0&lt;/b&gt;: (default) No IPsec SAs to servers behind NAT&lt;br&gt;
&lt;b&gt;1&lt;/b&gt;: IPsec SAs can be made to servers behind NAT&lt;br&gt;
&lt;b&gt;2&lt;/b&gt;: 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="00000000"/>
<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="2008-05-30 20:37:37"
110
uid="{52C38FD7-A081-404C-A8EA-B24A9614D0B5}"
desc="&lt;b&gt;Enable PMTU Discovery&lt;/b&gt;&lt;p&gt;
This setting configures whether computers can use PMTU
discovery on the network.&lt;p&gt;
&lt;b&gt;1&lt;/b&gt; --
Enable&lt;br&gt;
&lt;b&gt;0&lt;/b&gt; --
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="00000001"/>
</Registry>
<Registry
clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}"
name="Simplified IPsec Policy (W2K, XP, W2K3)"
status="IKEFlags"
image="12"
changed="2008-05-30 20:43:31"
uid="{B9A34EFB-CDF7-4603-BBED-6BB85080C96F}"
desc="&lt;b&gt;Simplified IPsec Policy&lt;/b&gt;&lt;p&gt;
This setting configures two aspects of IPsec fallback-to-clear
in Windows 2003, Windows XP, and Windows 2000.&lt;p&gt;
&lt;b&gt;0x00&lt;/b&gt;: Original 3 second fallback-to-clear&lt;br&gt;
&lt;b&gt;0x04&lt;/b&gt;: Enables 500ms fallback-to-clear&lt;br&gt;
&lt;b&gt;0x10&lt;/b&gt;: Improve fallback-to-clear in S&amp;amp;D
Iso&lt;br&gt;
&lt;b&gt;0x14&lt;/b&gt;: Both 0x4 and 0x10 settings enabled (recommended)"
bypassErrors="1">
<Properties
action="U"
111
displayDecimal="0"
default="0"
hive="HKEY_LOCAL_MACHINE"
key="System\CurrentControlSet\Services\PolicyAgent\Oakley"
name="IKEFlags"
type="REG_DWORD"
value="00000014"/>
<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="2008-05-30 20:35:43"
uid="{60F64C68-EF12-4FAC-ACC9-00B4F21724FA}"
desc="&lt;b&gt;IPsec Default Exemptions for Windows 2000 SP4
and Windows XP SP2&lt;/b&gt;&lt;p&gt;
This setting determines which network traffic type is exempt
from any IPsec authentication requirements.&lt;p&gt;
&lt;b&gt;0&lt;/b&gt;: Exempts multicast, broadcast, RSVP, Kerberos,
ISAKMP&lt;br&gt;
&lt;b&gt;1&lt;/b&gt;: Exempts multicast, broadcast, ISAKMP"
bypassErrors="1">
112
<Properties
action="U"
displayDecimal="1"
default="0"
hive="HKEY_LOCAL_MACHINE"
key="SYSTEM\CurrentControlSet\Services\IPsec"
name="NoDefaultExempt"
type="REG_DWORD"
value="00000001"/>
<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
changed="2008-05-30 20:34:03"
uid="{7023764D-5E8A-4E16-BEA3-EA0743024EFA}"
desc="&lt;b&gt;IPsec Default Exemptions for Windows Server 2008
and later&lt;/b&gt;&lt;p&gt;
This setting determines which network traffic type is exempt
from any IPsec authentication requirements.&lt;p&gt;
&lt;b&gt;0&lt;/b&gt;: Exempts multicast, broadcast, RSVP, Kerberos,
ISAKMP&lt;br&gt;
&lt;b&gt;1&lt;/b&gt;: Exempts multicast, broadcast, ISAKMP&lt;br&gt;
&lt;b&gt;2&lt;/b&gt;: Exempts RSVP, Kerberos, ISAKMP&lt;br&gt;
&lt;b&gt;3&lt;/b&gt;: 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="00000003"/>
<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
clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}"
name="IPsec Default Exemptions (Vista and W2K8)"
status="NoDefaultExempt"
image="12"
changed="2008-05-30 20:33:32"
uid="{AE5C505D-283E-4060-9A55-70659DFD56B6}"
desc="&lt;b&gt;IPsec Default Exemptions for Windows Server 2008
and later&lt;/b&gt;&lt;p&gt;
This setting determines which network traffic type is exempt
from any IPsec authentication requirements.&lt;p&gt;
&lt;b&gt;0&lt;/b&gt;: Exempts multicast, broadcast, RSVP, Kerberos,
ISAKMP&lt;br&gt;
&lt;b&gt;1&lt;/b&gt;: Exempts multicast, broadcast, ISAKMP&lt;br&gt;
&lt;b&gt;2&lt;/b&gt;: Exempts RSVP, Kerberos, ISAKMP&lt;br&gt;
&lt;b&gt;3&lt;/b&gt;: 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="00000003"/>
<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
</Filters>
</Registry>
<Registry
clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}"
name="Enable IPsec over NAT (Vista and W2K8)"
status="AssumeUDPEncapsulationContextOnSendRule"
image="12"
changed="2008-05-30 20:32:56"
uid="{61C18AA8-F78E-453B-809A-98354D407035}"
desc="&lt;b&gt;Enable IPsec over NAT-T&lt;/b&gt;&lt;p&gt;
This setting configures whether computers running Windows 2003
and Windows XP can make IPsec connections to servers behind
NAT-enabled routers.&lt;p&gt;
&lt;b&gt;0&lt;/b&gt;: (default) No IPsec SAs to servers behind NAT&lt;br&gt;
&lt;b&gt;1&lt;/b&gt;: IPsec SAs can be made to servers behind NAT&lt;br&gt;
&lt;b&gt;2&lt;/b&gt;: 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="00000000"/>
<Filters>
<FilterOs
bool="AND" not="0"
class="NT" version="VISTA"
type="NE" edition="NE" sp="NE"/>
<FilterOs
116
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 (http://go.microsoft.com/fwlink/?linkid=95393)
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 2008.
•
Windows Firewall with Advanced Security Content Roadmap
(http://go.microsoft.com/fwlink/?linkid=96525)
This topic describes the documents currently available in the Windows Technical Library for
Windows Firewall with Advanced Security in Windows Vista and Windows Server 2008.
•
Windows Firewall with Advanced Security - Diagnostics and Troubleshooting
(http://go.microsoft.com/fwlink/?linkid=95372)
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 (http://go.microsoft.com/fwlink/?linkid=95394)
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 2008.
•
Simplifying IPsec Policy with the Simple Policy Update
(http://go.microsoft.com/fwlink/?linkid=94767)
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
Server and Domain Isolation
•
Server and Domain Isolation (http://go.microsoft.com/fwlink/?linkid=95395)
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 2008.
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 (http://go.microsoft.com/fwlink/?linkid=93542)
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 2008.
•
WMI Filtering Using GPMC (http://go.microsoft.com/fwlink/?linkid=93188)
•
HOWTO: Leverage Group Policies with WMI Filters
(http://go.microsoft.com/fwlink/?linkid=93760)
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 (http://go.microsoft.com/fwlink/?linkid=102573)
118
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
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
(http://go.microsoft.com/fwlink/?linkid=102573) and Group Policy
(http://go.microsoft.com/fwlink/?linkid=93542).
•
Guidance for setting up certification authorities (CAs) to create certificates for certificatebased authentication. For this information, see Active Directory Certificate Services
(http://go.microsoft.com/fwlink/?linkid=110820).
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
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
(http://go.microsoft.com/fwlink/?linkid=96525).
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
•
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
(http://go.microsoft.com/fwlink/?linkid=93369) 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
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
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 2003. 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
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
Reference
Review important concepts and
examples for deploying GPOs in
a way that best meets the needs
of your organization.
Identifying Your Windows
Firewall with Advanced Security
Deployment Goals
Create the membership group in
AD DS that will be used to
contain computer accounts that
must receive the GPO.
Create a Group Account in
Active Directory
Planning Group Policy
Deployment for Your Isolation
Zones
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.
125
Task
Create a GPO for each version
of Windows that has different
implementation requirements.
Reference
Create a Group Policy Object
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.
Assign Security Group Filters
to the GPO
Create WMI filters to limit each
GPO to only the computers that
match the criteria in the filter.
Create WMI Filters for the
GPO
If you are working on a GPO that
Modify GPO Filters to Apply
was copied from another, modify to a Different Zone or Version of
the group memberships and WMI Windows
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.
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
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
Reference
Review important concepts and
examples for the basic firewall
policy design to determine if this
design meets the needs of your
organization.
Identifying Your Windows
Firewall with Advanced Security
Deployment Goals
Basic Firewall Policy Design
Firewall Policy Design
Example
Planning Settings for a Basic
Firewall Policy
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.
Checklist: Creating Group
Policy Objects
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
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
Copy a GPO to Create a
New GPO
127
Task
Reference
the computers for which this
GPO is intended.
Configure the GPO with firewall
default settings appropriate for
your design.
Checklist: Configuring Basic
Firewall Settings
Create one or more inbound
firewall rules to allow unsolicited
inbound network traffic.
Checklist: Creating Inbound
Firewall Rules
Create one or more outbound
firewall rules to block unwanted
outbound network traffic.
Checklist: Creating Outbound
Firewall Rules
Link the GPO to the domain level
of the Active Directory
organizational unit hierarchy.
Link the GPO to the Domain
Add test computers to the
membership group, and then
confirm that the computers
receive the firewall rules from the
GPOs as expected.
Add Test Computers to the
Membership Group for a Zone
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.
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
Task
Reference
Turn the firewall on and set the
default inbound and outbound
behavior.
Turn on Windows Firewall
and Configure Default 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 Windows Firewall
to Suppress Notifications When
a Program Is Blocked
Configure the firewall to record
a log file.
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
Reference
Create a rule that allows a
program to listen for and accept
inbound network traffic on any
ports it requires.
Create an Inbound Program
or Service Rule on Windows
Vista or Windows Server 2008
Create a rule that allows
inbound network traffic on a
specified port number.
Create an Inbound Port Rule
on Windows Vista or Windows
Server 2008
Create a rule that allows
Create an Inbound ICMP
129
Task
Reference
inbound ICMP network traffic.
Rule on Windows Vista or
Windows Server 2008
Create rules that allow inbound
RPC network traffic.
Create Inbound Rules to
Support RPC on Windows Vista
or Windows Server 2008
Enable a predefined rule or a
Enable Predefined Inbound
group of predefined rules. Some Rules on Windows Vista or
predefined rules for basic
Windows Server 2008
network services are included
as part of the installation of
Windows; others can be created
when you install a new
application or network service.
Checklist: Creating inbound firewall rules for Windows XP or Windows Server 2003
Task
Reference
Create a rule that allows a
program to listen for and accept
inbound network traffic on any
ports it requires.
Create an Inbound Program
Rule on Windows XP or
Windows Server 2003
Create a rule that allows inbound
network traffic on a specified port
number.
Create an Inbound Port Rule
on Windows XP or Windows
Server 2003
Enable predefined rules for file
and printer sharing, ICMP,
remote administration, remote
desktop, or network Plug and
Play.
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
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
Reference
Create a rule that allows a
program to send any outbound
network traffic on any port it
requires.
Create an Outbound
Program or Service Rule on
Windows Vista or Windows
Server 2008
Create a rule that allows
outbound network traffic on a
specified port number.
Create an Outbound Port
Rule on Windows Vista or
Windows Server 2008
Enable a predefined rule or a
Enable Predefined Outbound
group of predefined rules. Some Rules on Windows Vista or
Windows Server 2008
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.
131
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
(http://go.microsoft.com/fwlink/?linkid=129230.
Checklist: Implementing a domain isolation policy design
Task
Reference
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.
Identifying Your Windows
Firewall with Advanced Security
Deployment Goals
Create the GPOs and
connection security rules for the
isolated domain.
Checklist: Configuring Rules
for the Isolated Domain
Create the GPOs and
connection security rules for the
boundary zone.
Checklist: Configuring Rules
for the Boundary Zone
Create the GPOs and
connection security rules for the
encryption zone.
Checklist: Configuring Rules
for the Encryption Zone
Create the GPOs and
Domain Isolation Policy
Design
Domain Isolation Policy
Design Example
Planning Domain Isolation
Zones
Checklist: Configuring Rules
132
Task
Reference
connection security rules for the
isolated server zone.
for an Isolated Server Zone
According to the testing and rollAdd Production Computers to
out schedule in your design plan, the Membership Group for a
add computer accounts to the
Zone
membership group to deploy
rules and settings to your
computers.
After you confirm that network
Change Rules from Request
traffic is authenticated by IPsec, to Require Mode
you can change authentication
rules for the isolated domain and
encryption zone 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
Task
Reference
Create a GPO for the computers
Checklist: Creating Group
in the isolated domain running
Policy Objects
one of the operating systems.
Copy a GPO to Create a New
After you have finished the tasks GPO
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.
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
Configure IPsec to exempt all
ICMP network traffic from IPsec
protection.
Exempt ICMP from
Authentication on Windows Vista
and Windows Server 2008
Create a rule that exempts all
network traffic to and from
computers on the exemption list
from IPsec.
Create an Authentication
Exemption List Rule on
Windows Vista and Windows
Server 2008
Configure the key exchange
(main mode) security methods
and algorithms to be used.
Configure Key Exchange
(Main Mode) Settings on
Windows Vista and Windows
Server 2008
Configure the data protection
(quick mode) algorithm
combinations to be used.
Configure Data Protection
(Quick Mode) Settings on
Windows Vista and Windows
Server 2008
Configure the authentication
methods to be used.
Configure Authentication
Methods on Windows Vista and
Windows Server 2008
Create the rule that requests
authentication for all inbound
network traffic.
Create an Authentication
Request Rule on Windows Vista
and Windows Server 2008
134
Task
Link the GPO to the domain
level of the AD DS
organizational unit hierarchy.
Reference
Link the GPO to the Domain
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.
Add Test Computers to the
Membership Group for a Zone
Verify that the connection
security rules are protecting
network traffic to and from the
test computers.
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
Task
Reference
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.
to a Different Zone or Version of
Windows
Add registry settings that
optimize IPsec behavior to the
GPO.
Configure Settings to
Optimize IPsec Behavior on
Earlier Versions of Windows
Create a new IP Security policy
in the GPO.
Create a New IP Security
Policy in a GPO for Earlier
Versions of Windows
Configure the key exchange
(main mode) security methods
and algorithms to be used.
Configure Key Exchange
(Main Mode) Settings on Earlier
Versions of Windows
Create IP filter lists for ICMP
traffic, the exemption list, and all
inbound IP traffic.
Create Filter Lists for Isolated
Domain Computers and Isolated
Servers Running Earlier
Versions of Windows
Create filter actions to allow
traffic, request authentication,
require authentication, and
require both authentication and
encryption.
Create Filter Actions on
Earlier Versions of Windows
Create the IPsec rules that
Create IPsec Rules for an
combine the filter lists and filter
Isolated Domain on Earlier
actions. For the main zone in the Versions of Windows
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.
Assign an IPsec Policy to a
GPO for Earlier Versions of
Windows
136
Task
Link the GPO to the domain level
of the AD DS organizational unit
hierarchy.
Reference
Link the GPO to the Domain
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.
Add Test Computers to the
Membership Group for a Zone
Verify that the connection
security rules are correctly
protecting your network traffic.
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
Task
Reference
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.
Copy a GPO to Create a New
GPO
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.
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
Link the GPO to the domain level
of the Active Directory
organizational unit hierarchy.
Link the GPO to the Domain
Add your test computers to the
Add Test Computers to the
Membership Group for a Zone
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.
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
settings, filter lists, and filter actions that you defined in that section can be reused in the GPO for
the boundary zone.
Task
Reference
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.
Copy a GPO to Create a New
GPO
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.
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
Create a new IP Security policy
in the GPO to contain the
boundary zone settings.
Create a New IP Security
Policy in a GPO for Earlier
Versions of Windows
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.
Create IPsec Rules for an
Isolated Domain on Earlier
Versions of Windows
Assign the boundary zone IPsec
policy to your GPO.
Assign an IPsec Policy to a
GPO for Earlier Versions of
Windows
Link the GPO to the domain level
of the Active Directory
organizational unit hierarchy.
Link the GPO to the Domain
Add your test computers to the
Add Test Computers to the
membership group for the
Membership Group for a Zone
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
Verify That Network Traffic Is
Authenticated
139
Task
Reference
authentication when it can, and
that unauthenticated traffic is
accepted.
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
Reference
Make a copy of the domain
isolation GPOs to serve as a
starting point for the GPOs for
the encryption zone.
Copy a GPO to Create a New
GPO
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.
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
Add the encryption requirements
Configure the Rules to
Require Encryption on Windows
for the zone.
Vista and Windows Server 2008
Link the GPO to the domain
level of the Active Directory
Link the GPO to the Domain
140
Task
Reference
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.
Add Test Computers to the
Membership Group for a Zone
Verify that the connection
security rules are protecting
network traffic.
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
Reference
Make a copy of the domain
isolation GPOs to serve as a
starting point for the GPOs for
the encryption zone.
Copy a GPO to Create a New
GPO
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.
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
Create a new IP Security policy
that can be assigned to the
encryption zone GPO.
Create a New IP Security
Policy in a GPO for Earlier
Versions of Windows
Create the IPsec rules that
Create IPsec Rules for an
combine the filter lists and filter
Isolated Domain on Earlier
actions. For the encryption zone, Versions of Windows
you reuse the filters and filter
lists you created earlier for the
141
Task
Reference
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.
Assign an IPsec Policy to a
GPO for Earlier Versions of
Windows
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.
Add Test Computers to the
Membership Group for a Zone
Verify that the connection
security rules are protecting
network traffic.
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” (http://go.microsoft.com/fwlink/?linkid=69843).
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
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
Reference
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 a GPO to Create a
New GPO
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
143
Task
Reference
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.
Modify GPO Filters to Apply
to a Different Zone or Version
of Windows
Configure IPsec to exempt all ICMP
network traffic from IPsec
protection.
Exempt ICMP from
Authentication on Windows
Vista and Windows Server
2008
Configure the key exchange (main
mode) security methods and
algorithms to be used.
Configure Key Exchange
(Main Mode) Settings on
Windows Vista and Windows
Server 2008
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 Data Protection
(Quick Mode) Settings on
Windows Vista and Windows
Server 2008
Configure the authentication
methods to be used.
Configure Authentication
Methods on Windows Vista
and Windows Server 2008
Create a rule that exempts all
network traffic to and from
computers on the exemption list
from IPsec.
Create an Authentication
Exemption List Rule on
Windows Vista and Windows
Server 2008
Create a rule that requests
authentication for all network traffic.
Create an Authentication
Request Rule on Windows
Vista and Windows Server
2008
Important
Just as in an isolated
domain, do not set the rules
to require authentication for
inbound traffic until you
144
Task
Reference
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 Group Account in
Active Directory
Create a firewall rule that permits
inbound network traffic only if
authenticated as a member of the
NAG.
Restrict Server Access to
Members of a Group Only
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.
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
Task
Reference
Create a GPO for the computers
Copy a GPO to Create a
that need to have access
New GPO
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.
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
Add registry settings that optimize
Configure Settings to
IPsec behavior to the GPO.
Optimize IPsec Behavior on
Earlier Versions of Windows
Create a new IP Security policy in
Create a New IP Security
the GPO.
Policy in a GPO for Earlier
Versions of Windows
Important
If IPsec policies exist, do
146
Task
Reference
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.
Configure Key Exchange
(Main Mode) Settings on Earlier
Versions of Windows
Create IP filter lists for ICMP
traffic, the exemption list, and all
other inbound IP traffic.
Create Filter Lists for Isolated
Domain Computers and Isolated
Servers Running Earlier
Versions of Windows
Create filter actions to allow
traffic, request authentication,
and require authentication and,
optionally, encryption.
Create Filter Actions on
Earlier Versions of Windows
Combine the filter lists and filter
actions into the rules required for
an isolated server zone.
Create IPsec Rules for an
Isolated Domain on Earlier
Versions of Windows
Assign the IPsec policy to your
GPO.
Assign an IPsec Policy to a
GPO for Earlier Versions of
Windows
Grant the Access this computer
from the network user right to
only computers or users who are
authenticated members of the
NAG.
Restrict Server Access to
Members of a Group Only
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.
Add Test Computers to the
Membership Group for a Zone
Verify that the IPsec rules are
protecting your network traffic.
Verify That Network Traffic Is
Authenticated
147
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
Reference
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.
Identifying Your Windows
Firewall with Advanced Security
Deployment Goals
Server Isolation Policy Design
Server Isolation Policy Design
Example
Planning Server Isolation
Zones
Create the GPOs and
connection security rules for
isolated servers.
Checklist: Configuring Rules
for Servers in a Standalone
Isolated Server Zone
Create the GPOs and
connection security rules for the
Checklist: Creating Rules for
Clients of a Standalone Isolated
148
Task
Reference
client computers that must
connect to the isolated servers.
Server Zone
Verify that the connection
security rules are protecting
network traffic on your test
computers.
Verify That Network Traffic Is
Authenticated
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.
Change Rules from Request
to Require Mode
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.
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
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
Reference
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.
Checklist: Creating Group
Policy Objects
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.
Modify GPO Filters to Apply
to a Different Zone or Version
of Windows
Configure IPsec to exempt all ICMP
network traffic from IPsec
Exempt ICMP from
Authentication on Windows
Copy a GPO to Create a
New GPO
150
Task
Reference
protection.
Vista and Windows Server
2008
Create a rule that exempts all
network traffic to and from
computers on the exemption list
from IPsec.
Create an Authentication
Exemption List Rule on
Windows Vista and Windows
Server 2008
Configure the key exchange (main
mode) security methods and
algorithms to be used.
Configure Key Exchange
(Main Mode) Settings on
Windows Vista and Windows
Server 2008
Configure the data protection (quick
mode) algorithm combinations to be
used.
Configure Data Protection
(Quick Mode) Settings on
Windows Vista and Windows
Server 2008
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.
Configure Authentication
Methods on Windows Vista
and Windows Server 2008
Create a rule that requests
authentication for all inbound
network traffic.
Create an Authentication
Request Rule on Windows
Vista and Windows Server
2008
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.
Configure the Rules to
Require Encryption on
Windows Vista and Windows
Server 2008
151
Task
Reference
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 Group Account in
Active Directory
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.
Restrict Server Access to
Members of a Group Only
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.
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
Task
Reference
Create a GPO for the computers
Create a Group Policy Object
that need to have access
Copy a GPO to Create a
restricted to the same set of client New GPO
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.
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
Add registry settings that optimize
Configure Settings to
IPsec behavior to the GPO.
Optimize IPsec Behavior on
Earlier Versions of Windows
Create a new IP Security policy in
Create a New IP Security
the GPO.
Policy in a GPO for Earlier
Versions of Windows
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.
Configure Key Exchange
(Main Mode) Settings on Earlier
Versions of Windows
Create IP filter lists for ICMP
traffic, the exemption list, and all
inbound IP traffic.
Create Filter Lists for Isolated
Domain Computers and Isolated
Servers Running Earlier
Versions of Windows
Create filter actions to allow
Create Filter Actions on
153
Task
Reference
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.
Earlier Versions of Windows
Create the IPsec rules that
combine the filter lists and filter
actions.
Create IPsec Rules for an
Isolated Server Zone on Earlier
Versions of Windows
Assign the IPsec policy to your
GPO.
Assign an IPsec Policy to a
GPO for Earlier Versions of
Windows
If you have not already done so,
Create a Group Account in
create the NAG to contain the
Active Directory
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.
Restrict Server Access to
Members of a Group Only
Link the GPO to the Domain
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.
Add Test Computers to the
Membership Group for a Zone
Verify that the IPsec rules are
protecting your network traffic.
Verify That Network Traffic Is
Authenticated
154
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
Reference
Create a GPO for the client
Checklist: Creating Group
computers that must connect to
Policy Objects
servers in the isolated server
Copy a GPO to Create a New
zone, and that are running one
GPO
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
Modify GPO Filters to Apply
to a Different Zone or Version of
155
Task
Reference
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.
Windows
Configure IPsec to exempt all
ICMP network traffic from IPsec
protection.
Exempt ICMP from
Authentication on Windows
Vista and Windows Server 2008
Create a rule that exempts all
network traffic to and from
computers on the exemption list
from IPsec.
Create an Authentication
Exemption List Rule on
Windows Vista and Windows
Server 2008
Configure the key exchange
(main mode) security methods
and algorithms to be used.
Configure Key Exchange
(Main Mode) Settings on
Windows Vista and Windows
Server 2008
Configure the data protection
(quick mode) algorithm
combinations to be used.
Configure Data Protection
(Quick Mode) Settings on
Windows Vista and Windows
Server 2008
Configure the authentication
methods to be used.
Configure Authentication
Methods on Windows Vista and
Windows Server 2008
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.
Create an Authentication
Request Rule on Windows Vista
and Windows Server 2008
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
Link the GPO to the Domain
Add Test Computers to the
Membership Group for a Zone
156
Task
Reference
zone. Be sure to add at least one
for each operating system
supported by a different GPO in
the group.
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
Reference
Create a GPO for the client
Create a Group Policy Object
computers that must connect to
Copy a GPO to Create a New
servers in the isolated server
GPO
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.
Modify GPO Filters to Apply
to a Different Zone or Version of
Windows
157
Task
Reference
Add registry settings that
optimize IPsec behavior to the
GPO.
Configure Settings to
Optimize IPsec Behavior on
Earlier Versions of Windows
Create a new IP Security policy
in the GPO.
Create a New IP Security
Policy in a GPO for Earlier
Versions of Windows
Configure the key exchange
(main mode) security methods
and algorithms to be used.
Configure Key Exchange
(Main Mode) Settings on Earlier
Versions of Windows
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 Lists for Clients
of Isolated Server Running
Earlier Versions of Windows
Create filter actions to allow
Create Filter Actions on
traffic and request
Earlier Versions of Windows
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.
Create IPsec Rules for an
Isolated Domain on Earlier
Versions of Windows
Assign the IPsec policy for the
isolated domain to your GPO.
Assign an IPsec Policy to a
GPO for Earlier Versions of
Windows
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
Link the GPO to the Domain
Add Test Computers to the
Membership Group for a Zone
158
Task
Reference
GPO in the group.
Verify that the connection
security rules are protecting your
network traffic.
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
Reference
Review important concepts and
Identifying Your Windows
examples for certificate-based
Firewall with Advanced Security
Deployment Goals
authentication to determine if
this design meets your
Certificate-based Isolation
deployment goals and the needs Policy Design
of your organization.
Certificate-based Isolation
Policy Design Example
Planning Certificate-based
Authentication
Install the Active Directory
Install Active Directory
Certificate Services (AD CS) role Certificate Services
as an enterprise root issuing
certification authority (CA). This
step is required only if you have
159
Task
Reference
not already deployed a CA on
your network.
Configure the certificate
template for workstation
authentication certificates.
Configure the Workstation
Authentication Certificate
Template
Configure Group Policy to
automatically deploy certificates
based on your template to
workstation computers.
Configure Group Policy to
Autoenroll and Deploy
Certificates
On a test computer, refresh
Group Policy and confirm that
the certificate is installed.
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
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
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
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
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
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
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
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 (http://go.microsoft.com/fwlink/?linkid=127725).
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
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
You must remove the default permission granted to all authenticated users and
computers to restrict the GPO to only the groups you specify.
5. 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 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
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 2008
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 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 2000
1. 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
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
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 2008. 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 2008. 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
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 2008. 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 2008. 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 2008. 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
•
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
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
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
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
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
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 810207 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?linkid=110516). 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
914841 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?linkid=110514). We
178
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 914841 in the Microsoft Knowledge Base to enable simplified IPsec policy
(http://go.microsoft.com/fwlink/?linkid=110514). 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 885407 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?linkid=119888). 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
(http://go.microsoft.com/fwlink/?linkid=119891).
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
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 2003.
•
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
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 2008.
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
(http://go.microsoft.com/fwlink/?LinkID=111236).
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 2003
181
To configure Windows Firewall logging for Windows Vista or Windows Server 2008
1. 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 2003
1. 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
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 2048.
9. Click the Security tab. In Group or user names, click Domain Computers, under
Allow, select Enroll and Autoenroll, and then click OK.
183
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 2008
1. Open the Group Policy Management Console to Windows Firewall with Advanced
Security.
184
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 2003
1. 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
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
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
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
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
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, 10.50.0.0/16 represents the class B
subnet that begins with address 10.50.0.1, and ends with address 10.50.255.254.
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
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
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 2008.
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 2008.
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 2008. User-based authentication using Kerberos V5 is not
supported by IKE v1.
192
•
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 2008. 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 2008. 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
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
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
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
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 2003.
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
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
Meaning
Port
The decimal port number to which inbound
network traffic is allowed.
Transport
The protocol for the port number. Either
TCP or UDP.
Scope
Select one of the following options:
Status
•
An asterisk (*) to represent all
networks.
•
A comma-separated list of IP
address or subnets, such as:
10.0.0.1, 10.2.3.0/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.
Name
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
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
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 2008. 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 2003.
200
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
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
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
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 2008. 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
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
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
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
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
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
(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
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 914841 in the
Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?linkid=110514), 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
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
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 10.1.2.0/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,
192.168.0.0/24 indicates all IP addresses from 192.168.0.1 to 192.168.0.254.
•
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
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
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
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 914841 in the
Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?linkid=110514), 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
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
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 10.1.2.0/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,
192.168.0.0/24 indicates all IP addresses from 192.168.0.1 to 192.168.0.254.
•
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
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
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
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 2003.
•
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 2003.
221
•
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
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 certificate223
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
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
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 2003.
•
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 2003.
•
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
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
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
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 2003.
•
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 2003.
•
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
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
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
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 2008. 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
... 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
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
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 2008.
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
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
Meaning
An IP address, such as 10.0.0.1
Network traffic from that IP address is
allowed.
A subnet description, such as 10.2.3.0/24
Network traffic from any IP address on the
specified subnet is allowed.
localsubnet
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
10.0.0.1, from any computer on your local subnet or network 10.2.3.0/24, then type
10.0.0.1,10.2.3.0/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
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 1034.
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
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
Meaning
An IP address, such as 10.0.0.1
Network traffic from that IP address is
allowed.
A subnet description, such as 10.2.3.0/24
Network traffic from any IP address on the
specified subnet is allowed.
localsubnet
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
10.0.0.1, from any computer on your local subnet or network 10.2.3.0/24, then type
10.0.0.1,10.2.3.0/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
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
Meaning
An IP address, such as 10.0.0.1
Network traffic from that IP address is
allowed.
A subnet description, such as 10.2.3.0/24
Network traffic from any IP address on the
specified subnet is allowed.
localsubnet
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
10.0.0.1, from any computer on your local subnet or network 10.2.3.0/24, then type
10.0.0.1,10.2.3.0/24,localsubnet in the Allow unsolicited incoming messages from
these IP addresses text box.
9. Click OK to save your changes.
239
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
Meaning
An IP address, such as 10.0.0.1
Network traffic from that IP address is
allowed.
A subnet description, such as 10.2.3.0/24
Network traffic from any IP address on the
specified subnet is allowed.
localsubnet
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
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
10.0.0.1, from any computer on your local subnet or network 10.2.3.0/24, then type
10.0.0.1,10.2.3.0/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
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
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 (http://go.microsoft.com/fwlink/?LinkId=110923).
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 1024. 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
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
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
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
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
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
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 2008
1. 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
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 2008. 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
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
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 2008
1. 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 2003
1. 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
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 2008. 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
(http://go.microsoft.com/fwlink/?linkid=111237).
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
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
http://go.microsoft.com/fwlink/?linkid=94770. 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
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.
The details pane displays the rules currently in effect on the computer.
4.
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
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
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 (http://go.microsoft.com/fwlink/?linkid=95393)
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 2008.
•
Windows Firewall with Advanced Security Content Roadmap
(http://go.microsoft.com/fwlink/?linkid=96525)
This topic describes the documents currently available in the Windows Technical Library for
Windows Firewall with Advanced Security in Windows Vista and Windows Server 2008.
•
Windows Firewall with Advanced Security - Diagnostics and Troubleshooting
(http://go.microsoft.com/fwlink/?linkid=95372)
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 (http://go.microsoft.com/fwlink/?linkid=95394)
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 2008.
•
Simplifying IPsec Policy with the Simple Policy Update
(http://go.microsoft.com/fwlink/?linkid=94767)
257
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 (http://go.microsoft.com/fwlink/?linkid=95395)
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 2008.
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 (http://go.microsoft.com/fwlink/?linkid=93542)
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 2008.
•
WMI Filtering Using GPMC (http://go.microsoft.com/fwlink/?linkid=93188)
•
HOWTO: Leverage Group Policies with WMI Filters
(http://go.microsoft.com/fwlink/?linkid=93760)
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 (http://go.microsoft.com/fwlink/?linkid=102573)
258