deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

batch1

Browse Source
This commit is contained in:
Paolo Matarazzo 2023-11-10 16:13:50 -05:00
parent 90dcf6aa29
commit ec8bcd2224
36 changed files with 0 additions and 1708 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

87
windows/security/operating-system-security/network-security/windows-firewall/TOC.yml
View File

@ -19,93 +19,6 @@ items:
href: require-encryption-when-accessing-sensitive-network-resources.md
- name: Restrict access
href: restrict-access-to-only-specified-users-or-devices.md
- name: Implementation designs
items:
- name: Map goals to a design
href: mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md
- name: Basic firewall design
href: basic-firewall-policy-design.md
items:
- name: Basic firewall design example
href: firewall-policy-design-example.md
- name: Domain isolation design
href: domain-isolation-policy-design.md
items:
- name: Domain isolation design example
href: domain-isolation-policy-design-example.md
- name: Server isolation design
href: server-isolation-policy-design.md
items:
- name: Server Isolation design example
href: server-isolation-policy-design-example.md
- name: Certificate-based isolation design
href: certificate-based-isolation-policy-design.md
items:
- name: Certificate-based Isolation design example
href: certificate-based-isolation-policy-design-example.md
- name: Design planning
items:
- name: Plan your design
href: planning-your-windows-firewall-with-advanced-security-design.md
- name: Plan settings for a basic firewall policy
href: planning-settings-for-a-basic-firewall-policy.md
- name: Plan domain isolation zones
items:
- name: Domain isolation zones
href: planning-domain-isolation-zones.md
- name: Exemption list
href: exemption-list.md
- name: Isolated domain
href: isolated-domain.md
- name: Boundary zone
href: boundary-zone.md
- name: Encryption zone
href: encryption-zone.md
- name: Plan server isolation zones
href: planning-server-isolation-zones.md
- name: Plan certificate-based authentication
href: planning-certificate-based-authentication.md
items:
- name: Document the Zones
href: documenting-the-zones.md
- name: Plan group policy deployment for your isolation zones
href: planning-group-policy-deployment-for-your-isolation-zones.md
items:
- name: Plan isolation groups for the zones
href: planning-isolation-groups-for-the-zones.md
- name: Plan network access groups
href: planning-network-access-groups.md
- name: Plan the GPOs
href: planning-the-gpos.md
items:
- name: Firewall GPOs
href: firewall-gpos.md
items:
- name: GPO_DOMISO_Firewall
href: gpo-domiso-firewall.md
- name: Isolated domain GPOs
href: isolated-domain-gpos.md
items:
- name: GPO_DOMISO_IsolatedDomain_Clients
href: gpo-domiso-isolateddomain-clients.md
- name: GPO_DOMISO_IsolatedDomain_Servers
href: gpo-domiso-isolateddomain-servers.md
- name: Boundary zone GPOs
href: boundary-zone-gpos.md
items:
- name: GPO_DOMISO_Boundary
href: gpo-domiso-boundary.md
- name: Encryption zone GPOs
href: encryption-zone-gpos.md
items:
- name: GPO_DOMISO_Encryption
href: gpo-domiso-encryption.md
- name: Server isolation GPOs
href: server-isolation-gpos.md
- name: Plan GPO deployment
href: planning-gpo-deployment.md
- name: Plan to deploy
href: planning-to-deploy-windows-firewall-with-advanced-security.md
- name: Deployment guide
items:
- name: Deployment overview

51
windows/security/operating-system-security/network-security/windows-firewall/basic-firewall-policy-design.md
View File

@ -1,51 +0,0 @@
---
title: Basic Firewall Policy Design
description: Protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses by using basic firewall policy design.
ms.topic: conceptual
ms.date: 11/07/2023
---
# 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 don't have a host-based firewall enabled on each device in the organization.
The Basic Firewall Policy Design helps you to protect the devices 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 device in your organization to allow traffic that is required by the programs that are used. Traffic that doesn't 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 device 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 don't 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 don't require specific firewall rules. The default behavior of Windows and most contemporary applications makes this task easy:
- On client devices, the default firewall behavior already supports typical client programs. Programs 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 device
- 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, the appropriate firewall rules are created and enabled automatically
- For other standard network behavior, the predefined rules that are built into Windows can be configured in a GPO and deployed to the devices 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 a few exceptions, the firewall can be enabled on all configurations. Therefore, we recommend that you enable the firewall on every device in your organization. The term "device" 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 Defender Firewall with Advanced Security is not supported by Microsoft.
Windows Defender Firewall with Advanced Security is turned on by default.
If you turn off the Windows Defender Firewall 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.
Compatible third-party firewall software can programmatically disable only the parts of Windows Defender Firewall that might need to be disabled for compatibility. This approach is the recommended one for third-party firewalls to coexist with the Windows Defender Firewall; third-party firewalls that comply with this recommendation have the certified logo from Microsoft.
An organization typically uses this design as a first step toward a more comprehensive Windows Defender Firewall design that adds server isolation and domain isolation.
After implementing this design, you'll have centralized management of the firewall rules applied to all devices that are running Windows in your organization.
> [!IMPORTANT]
> If you also intend to deploy the [Domain Isolation Policy Design](domain-isolation-policy-design.md), or the [Server Isolation Policy Design](server-isolation-policy-design.md), 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 devices 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 Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md)
- To learn more about this design, see [Firewall Policy Design Example](firewall-policy-design-example.md)
- Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md)
- To help you make the decisions required in this design, see [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md)
- 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](checklist-implementing-a-basic-firewall-policy-design.md)
> [!div class="nextstepaction"]
> [Domain Isolation Policy Design](domain-isolation-policy-design.md)

22
windows/security/operating-system-security/network-security/windows-firewall/boundary-zone-gpos.md
View File

@ -1,22 +0,0 @@
---
title: Boundary Zone GPOs
description: Learn about GPOs to create that must align with the group you create for the boundary zone in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Boundary Zone GPOs
All the devices 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 at least Windows Vista or 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. 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 devices that are incorrectly assigned to more than one group.
This recommendation 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 devices aren't 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 at least Windows Server 2008 are discussed.
- [GPO\_DOMISO\_Boundary\_WS2008](gpo-domiso-boundary.md)

57
windows/security/operating-system-security/network-security/windows-firewall/boundary-zone.md
View File

@ -1,57 +0,0 @@
---
title: Boundary Zone
description: Learn how a boundary zone supports devices that must receive traffic from beyond an isolated domain in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Boundary Zone
In most organizations, some devices can receive network traffic from devices that aren't part of the isolated domain, and therefore can't authenticate. To accept communications from untrusted devices, create a boundary zone within your isolated domain.
Devices in the boundary zone are trusted devices that can accept communication requests both from other isolated domain member devices and from untrusted devices. Boundary zone devices try to authenticate any incoming request by using IPsec, initiating an IKE negotiation with the originating device.
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 don't require it.
These boundary zone devices might receive unsolicited inbound communications from untrusted devices that use plaintext and must be carefully managed and secured in other ways. Mitigating this extra risk is an important part of deciding whether to add a device to the boundary zone. For example, completing a formal business justification process before adding each device to the boundary zone minimizes the extra risk. The following illustration shows a sample process that can help make such a decision.
![design flowchart.](images/wfas-designflowchart1.gif)
The goal of this process is to determine whether the risk of adding a device to a boundary zone can be mitigated to a level that makes it acceptable to the organization. Ultimately, if the risk can't be mitigated, membership must be denied.
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 similar to those settings and rules 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.
[Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) section discusses creation of the group and how to link it to the GPOs that apply the rules to members of the group.
## GPO settings for boundary zone servers running at least Windows Server 2008
The boundary zone GPO for devices running at least Windows Server 2008 should include the following components:
- IPsec default settings that specify the following options:
1. Exempt all ICMP traffic from IPsec.
2. Key exchange (main mode) security methods and algorithm. We recommend that you use at least DH4, AES, and SHA2 in your settings. Use the strongest algorithm combinations that are common to all your supported operating systems.
3. Data protection (quick mode) algorithm combinations. We recommend that you don't include DES or MD5 in any setting. They're 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, use ESP encapsulation. 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.
4. Authentication methods. Include at least device-based Kerberos V5 authentication. If you want to use user-based access to isolated servers, then you must also include user-based Kerberos V5 authentication as an optional authentication method. Likewise, if any of your domain isolation members can't use Kerberos V5, you must include certificate-based authentication as an optional authentication method.
- The following connection security rules:
- A connection security rule that exempts all devices 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.
- A registry policy that includes the following values:
- 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](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md) sets the value to **1**.
>**Note:**  For a sample template for these registry settings, see [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md)
**Next:**[Encryption Zone](encryption-zone.md)

47
windows/security/operating-system-security/network-security/windows-firewall/certificate-based-isolation-policy-design-example.md
View File

@ -1,47 +0,0 @@
---
title: Certificate-based Isolation Policy Design Example
description: This example uses a fictitious company to illustrate certificate-based isolation policy design in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 11/10/2023
---
# 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](firewall-policy-design-example.md), [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md), and [Server Isolation Policy Design Example](server-isolation-policy-design-example.md).
One of the servers that must be included in the domain isolation environment is a device running UNIX that supplies other information to the WGBank dashboard program running on the client devices. This device sends updated information to the WGBank front-end servers as it becomes available, so it's considered unsolicited inbound traffic to the devices that receive this information.
## Design requirements
One possible solution to this design example 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 device even though it can't authenticate.
A more secure solution, and the one selected by Woodgrove Bank, is to include the non-Windows device in the domain isolation design. Because it can't join an Active Directory domain, 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 Active Directory Certificate Services 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 device is beyond the scope of this document, but support for a certificate that can be used to authenticate such a non-Windows device by using the standard IPsec protocols is the subject of this design.
The non-Windows device can be effectively made a member of the boundary zone or the encryption zone based on the IPsec rules applied to the device. The only constraint is that the main mode and quick mode encryption algorithms supported by the UNIX device must also be supported by the Windows-based devices 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 device.
## Design details
Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the devices in their organization.
The inclusion of one or more non-Windows devices to the network requires only a simple addition to the GPOs for devices that must communicate with the non-Windows device. The addition is allowing certificate-based authentication in addition to the Active Directory-supported Kerberos V5 authentication. This certificate-based authoring doesn't require including new rules, just adding certificate-based authentication as an option to the existing rules.
When multiple authentication methods are available, two negotiating devices agree on the first one in their lists that match. Because most of the devices in Woodgrove Bank's network run Windows, Kerberos V5 is listed as the first authentication method in the rules. Certificate-based authentication is added as an alternate authentication type.
With the help of the Active Directory Users and Computers snap-in, Woodgrove Bank created a group named NAG_COMPUTER_WGBUNIX. They then added the device accounts to this group for Windows devices that need to communicate with the non-Windows devices. If all the devices in the isolated domain need to be able to access the non-Windows devices, 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 device.
> [!div class="nextstepaction"]
>
> [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md)

27
windows/security/operating-system-security/network-security/windows-firewall/certificate-based-isolation-policy-design.md
View File

@ -1,27 +0,0 @@
---
title: Certificate-based Isolation Policy Design
description: Explore the methodology behind Certificate-based Isolation Policy Design and how it defers from Domain Isolation and Server Isolation Policy Design.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 11/10/2023
---
# 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](domain-isolation-policy-design.md) and [Server Isolation Policy Design](server-isolation-policy-design.md) 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 devices 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 devices that must run another operating system. These devices can't join an Active Directory domain, without a third-party package being installed. Also, some devices that do run Windows can't join a domain for various reasons. To rely on Kerberos V5 as the authentication protocol, the device needs to be joined to the Active Directory and (for non-Windows devices) support Kerberos as an authentication protocol.
To authenticate with non-domain member devices, IPsec supports using standards-based cryptographic certificates. Because this authentication method is also supported by many third-party operating systems, it can be used as a way to extend your isolated domain to devices that don't run Windows.
The same principles of the domain and server isolation designs apply to this design. Only devices that can authenticate (in this case, by providing a specified certificate) can communicate with the devices in your isolated domain.
For Windows devices that are part of an Active Directory domain, you can use Group Policy to deploy the certificates required to communicate with the devices that are trusted but aren't part of the Active Directory domain. For other devices, you'll 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 info about this design:
- This design coincides with the implementation goals to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md), and optionally [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
- To learn more about this design, see [Certificate-based Isolation Policy Design Example](certificate-based-isolation-policy-design-example.md).
- Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
- To help you make the decisions required in this design, see [Planning Certificate-based Authentication](planning-certificate-based-authentication.md).
- 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](checklist-implementing-a-certificate-based-isolation-policy-design.md).

21
windows/security/operating-system-security/network-security/windows-firewall/documenting-the-zones.md
View File

@ -1,21 +0,0 @@
---
title: Documenting the Zones
description: Learn how to document the zone placement of devices in your design for Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Documenting the Zones
Generally, the task of determining zone membership isn't complex, but it can be time-consuming. Use the information generated during the [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md) 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 Defender Firewall with Advanced Security Strategy section. A sample is shown here:
| Host name | Hardware reqs met | Software reqs met | Configuration required | Details | Projected cost | Group |
| - | - | - | - | - | - |
| CLIENT001 | No| No| Upgrade hardware and software.| Current operating system is Windows XP. Old hardware not compatible with newer versions of Windows.| $??| Isolated domain|
| SERVER002 | Yes| No| Join trusted domain, upgrade from Windows Server 2008 to at least Windows Server 2012| No antivirus software present.| $??| Encryption|
| SENSITIVE001 | Yes| Yes| Not required.| Running Windows Server 2012. Ready for inclusion.| $0| Isolated server (in zone by itself)|
| PRINTSVR1 | Yes| Yes| Not required.| Running Windows Server 2008 R2. Ready for inclusion.| $0| Boundary|
**Next:** [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md)

52
windows/security/operating-system-security/network-security/windows-firewall/domain-isolation-policy-design-example.md
View File

@ -1,52 +0,0 @@
---
title: Domain Isolation Policy Design Example
description: This example uses a fictitious company to illustrate domain isolation policy design in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# 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](firewall-policy-design-example.md) 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, you might want to implement domain isolation to provide another layer of security to their networked devices. You can create firewall and connection security rules that use authentication to reduce the risk of communicating with untrusted and potentially hostile devices.
The following illustration shows the traffic protection needed for this design example.
![domain isolation policy design.](images/wfas-design2example1.gif)
1. All devices 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 devices reject all unsolicited inbound network traffic that isn't 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 devices owned by its partners, which aren't members of Woodgrove Bank's domain.
3. Client devices can initiate non-authenticated outbound communications with devices that aren't members of the domain, such as browsing external Web sites. Unsolicited inbound traffic from non-domain members is blocked.
4. Devices 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](firewall-policy-design-example.md) section are still enforced.
## Design Details
Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the devices 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 devices that run Windows were added to the correct groups, and then the appropriate GPO are applied to the group. To include a device in the isolated domain or any one of its subordinate zones, add the device'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 devices in the domain participate by default. The WMI filters ensure that the GPO doesn't apply to domain controllers. GPOs with connection security rules to enforce domain isolation behavior are linked to the domain container and applied to the devices 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 can't 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 devices that are part of the boundary group able to receive unsolicited inbound traffic from untrusted devices. 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 devices 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 firewall rules to require both authentication and encryption on all inbound and outbound traffic.
>**Note:**  If you are designing GPOs for only Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2, 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, devices 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 devices that are incorrectly assigned to more than one group.
**Next:** [Server Isolation Policy Design Example](server-isolation-policy-design-example.md)

58
windows/security/operating-system-security/network-security/windows-firewall/domain-isolation-policy-design.md
View File

@ -1,58 +0,0 @@
---
title: Domain Isolation Policy Design
description: Learn how to design a domain isolation policy, based on which devices accept only connections from authenticated members of the same isolated domain.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Domain Isolation Policy Design
In the domain isolation policy design, you configure the devices on your network to accept only connections coming from devices 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](basic-firewall-policy-design.md) section. For this design, you then add connection security and IPsec rules to configure devices in the isolated domain to accept only network traffic from other devices that can authenticate as a member of the isolated domain. After the new rules are implemented, your devices reject unsolicited network traffic from devices that aren't 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 devices even if they're connected to the same physical network segment.
The design is shown in the following illustration, with the arrows that show the permitted communication paths.
![isolated domain boundary zone.](images/wfasdomainisoboundary.gif)
Characteristics of this design, as shown in the diagram, include:
- Isolated domain (area A) - Devices in the isolated domain receive unsolicited inbound traffic only from other members of the isolated domain or from devices referenced in authentication exemption rules. Devices in the isolated domain can send traffic to any device. This traffic includes unauthenticated traffic to devices that aren't in the isolated domain. Devices that can't join an Active Directory domain, but that can use certificates for authentication, can be part of the isolated domain. For more info, see the [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md).
- Boundary zone (area B) - Devices in the boundary zone are part of the isolated domain but are allowed to accept inbound connections from untrusted devices, such as clients on the Internet.
Devices in the boundary zone request but don't require authentication to communicate. When a member of the isolated domain communicates with a boundary zone member, the traffic is authenticated. When a device that isn't part of the isolated domain communicates with a boundary zone member the traffic isn't authenticated.
Because boundary zone devices are exposed to network traffic from untrusted and potentially hostile devices, they must be carefully managed and secured. Put only the devices that must be accessed by external devices in this zone. Use firewall rules to ensure that network traffic is accepted only for services that you want exposed to non-domain member devices.
- Trusted non-domain members (area C) - Devices on the network that aren't domain members or that can't use IPsec authentication are allowed to communicate by configuring authentication exemption rules. These rules enable devices in the isolated domain to accept inbound connections from these trusted non-domain member devices.
- Untrusted non-domain members (area D) - Devices that aren't managed by your organization and have an unknown security configuration must have access only to those devices required for your organization to correctly conduct its business. Domain isolation exists to put a logical barrier between these untrusted Devices and your organization's devices.
After this design is implemented, your administrative team will have centralized management of the firewall and connection security rules applied to the devices in your organization.
> [!IMPORTANT]
> This design builds on the [Basic Firewall Policy Design](basic-firewall-policy-design.md), and in turn serves as the foundation for the [Server Isolation Policy Design](server-isolation-policy-design.md). 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 Devices 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 Devices that can't be part of an Active Directory domain, see the [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md).
For more info about this design:
- This design coincides with the implementation goals to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md), and optionally [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
- To learn more about this design, see the [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md).
- Before completing the design, gather the info described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
- To help you make the decisions required in this design, see [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) and [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md).
- For a list of tasks that you can use to deploy your domain isolation policy design, see [Checklist: Implementing a Domain Isolation Policy Design](checklist-implementing-a-domain-isolation-policy-design.md).
**Next:** [Server Isolation Policy Design](server-isolation-policy-design.md)

16
windows/security/operating-system-security/network-security/windows-firewall/encryption-zone-gpos.md
View File

@ -1,16 +0,0 @@
---
title: Encryption Zone GPOs
description: Learn how to add a device to an encryption zone by adding the device account to the encryption zone group in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Encryption Zone GPOs
Handle encryption zones in a similar manner to the boundary zones. A device is added to an encryption zone by adding the device account to the encryption zone group. Woodgrove Bank has a single service that must be protected, and the devices 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 GPO described in this section.
The GPO is only for server versions of Windows. Client devices aren't 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](gpo-domiso-encryption.md)

56
windows/security/operating-system-security/network-security/windows-firewall/encryption-zone.md
View File

@ -1,56 +0,0 @@
---
title: Encryption Zone
description: Learn how to create an encryption zone to contain devices that host sensitive data and require that the sensitive network traffic be encrypted.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Encryption Zone
Some servers in the organization host data that's sensitive, including medical, financial, or other personal data. Government or industry regulations might require that this sensitive information must be encrypted when it's transferred between devices.
To support the other security requirements of these servers, we recommend that you create an encryption zone to contain the devices and that requires that the sensitive inbound and outbound network traffic is 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 settings and rules 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](planning-group-policy-deployment-for-your-isolation-zones.md) section.
## GPO settings for encryption zone servers running at least Windows Server 2008
The GPO for devices that are running at least Windows Server 2008 should include:
- IPsec default settings that specify the following options:
1. Exempt all ICMP traffic from IPsec.
2. Key exchange (main mode) security methods and algorithm. We recommend that you use at least DH4, AES and SHA2 in your settings. Use the strongest algorithm combinations that are common to all your supported operating systems.
3. 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 don't include DES or MD5 in any setting. They're 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, use ESP encapsulation..
4. Authentication methods. Include at least device-based Kerberos V5 authentication. If you want to use user-based access to isolated servers, then you must also include user-based Kerberos V5 authentication as an optional authentication method. Likewise, if any of your domain isolation members can't 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 devices 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're sure that all the devices 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:
- 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](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md) sets the value to **1**.
>**Note:**  For a sample template for these registry settings, see [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md).
- If domain member devices must communicate with devices 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.
**Next:** [Planning Server Isolation Zones](planning-server-isolation-zones.md)

46
windows/security/operating-system-security/network-security/windows-firewall/exemption-list.md
View File

@ -1,46 +0,0 @@
---
title: Exemption List
description: Learn about reasons to add devices to an exemption list in Windows Defender Firewall with Advanced Security and the trade-offs of having too many exemptions.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Exemption List
When you implement a server and domain isolation security model in your organization, you're likely to find more challenges. Key infrastructure servers such as DNS servers and DHCP servers typically must be available to all devices on the internal network, yet secured from network attacks. However, if they must remain available to all devices on the network, not just to isolated domain members, then these servers can't require IPsec for inbound access, nor can they use IPsec transport mode for outbound traffic.
In addition to the infrastructure servers mentioned earlier, there might also be other servers on the network that trusted devices can't use IPsec to access, which would be added to the exemption list.
Generally, the following conditions are reasons to consider adding a device to the exemption list:
- If the device must be accessed by trusted devices but it doesn't have a compatible IPsec implementation.
- If the device must provide services to both trusted and untrusted devices, but doesn't meet the criteria for membership in the boundary zone.
- If the device must be accessed by trusted devices from different isolated domains that don't have an Active Directory trust relationship established with each other.
- If the device 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 device must support trusted and untrusted devices, but can't use IPsec to help secure communications to trusted devices.
For large organizations, the list of exemptions might grow 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 devices in your isolated domain to run at least Windows Vista or Windows Server 2008, you can greatly reduce the size of this list. A large exemption list has several unwanted effects on every device that receives the GPO, including the following effects:
- 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](boundary-zone.md) section.
**Next:** [Isolated Domain](isolated-domain.md)

14
windows/security/operating-system-security/network-security/windows-firewall/firewall-gpos.md
View File

@ -1,14 +0,0 @@
---
title: Firewall GPOs
description: In this example, a Group Policy Object is linked to the domain container because the domain controllers aren't part of the isolated domain.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Firewall GPOs
All the devices on Woodgrove Bank's network that run Windows are part of the isolated domain, except domain controllers. To configure firewall rules, the GPO described in this section is linked to the domain container in the Active Directory OU hierarchy, and then filtered by using security group filters and WMI filters.
The GPO created for the example Woodgrove Bank scenario includes [GPO\_DOMISO\_Firewall](gpo-domiso-firewall.md).

100
windows/security/operating-system-security/network-security/windows-firewall/firewall-policy-design-example.md
View File

@ -1,100 +0,0 @@
---
title: Basic Firewall Policy Design Example
description: This example features a fictitious company and illustrates firewall policy design for Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Basic 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 devices. The Active Directory domain controllers also host Domain Name System (DNS) for host name resolution. Separate devices host Windows Internet Name Service (WINS) for network basic input/output system (NetBIOS) name resolution. A set of devices that are running UNIX provide the Dynamic Host Configuration Protocol (DHCP) services for automatic IP addressing.
Woodgrove Bank is in the process of migrating their devices from Windows Vista and Windows Server 2008 to Windows 10 and Windows Server 2016. A significant number of the devices at Woodgrove Bank continue to run Windows Vista and Windows Server 2008. 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 devices in the organization. This program accesses several front-end server devices that run the server-side part of WGBank. These front-end servers only do the processing—they don't store the data. The data is stored in several back-end database devices that are running Microsoft SQL Server.
## Design requirements
The network administrators want to implement Windows Defender Firewall with Advanced Security throughout their organization to provide another 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 isn't wanted.
The following illustration shows the traffic protection needs for this design example.
![design example 1.](images/wfas-designexample1.gif)
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 devices and the WGBank partner servers. The WGBank client devices and partner servers can receive the response.
3. The WGBank front-end servers can send updated information to the client devices to support real-time display. The clients don't 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's no direct communications between the client devices and the WGBank back-end devices.
6. There's no unsolicited traffic from the WGBank back-end devices to the WGBank front-end 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 don't 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 devices through the Internet.
Other traffic notes:
- Devices aren't to receive any unsolicited traffic from any computer other than allowed above.
- Other outbound network traffic from the client devices not 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 devices on their network. They know that they must deploy policies to the following collections of devices:
- Client devices that run Windows 11, Windows 10, Windows 8, or Windows 7
- WGBank front-end servers that run Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 or Windows Server 2008 R2 (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 devices 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 R2 or Windows Server 2012
- DHCP servers that run the UNIX operating system
After the Woodgrove Bank network administrators evaluated these sets of devices, and compared them to the Active Directory organizational unit (OU) structure, they determined that there wasn't a good one-to-one match between the OUs and the sets. Therefore the firewall GPOs won't be linked directly to OUs that hold the relevant devices. 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's applied to the correct devices.
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. 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 devices 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 devices.
The two device types (client and server) are distinguished by using a WMI filters to ensure that only the policy intended for devices 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 devices that are running server versions of Windows can apply that GPO. Each of the GPOs also has security group filters to prevent members of the group FIREWALL\_NO\_DEFAULT from receiving either of these two GPOs.
- Client devices receive a GPO that configures Windows Defender Firewall to enforce the default Windows Defender 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 devices 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 aren't included, because it's not needed on server devices.
All rules are scoped to allow network traffic only from devices on Woodgrove Bank's corporate network.
- **CG\_FIREWALL\_NO\_DEFAULT**. Members of this group don't receive the default firewall GPO. Devices are added to this group if there's 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's a member of this group.
- **CG\_FIREWALL\_WGB\_FE**. This group contains the computer accounts for all the WGBank front-end server devices. Members of this group receive a GPO that configures Windows Defender Firewall with inbound firewall rules to allow unsolicited WGBank client traffic. Devices 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 devices that run SQL Server. Members of this group receive a GPO that configures Windows Defender Firewall with inbound firewall rules to allow the SQL Server program to receive unsolicited queries only from the WGBank front-end servers. Devices 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. Devices in this group also receive the default firewall GPO.
- **CG\_FIREWALL\_WINS**. This group contains the computer accounts for all the WINS server devices. Members of this group receive a GPO that configures Windows Defender Firewall with an inbound firewall rule to allow unsolicited inbound requests from WINS clients. Devices 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 devices. Members of this group receive a GPO that configures Windows Defender Firewall with inbound firewall rules to allow unsolicited Active Directory client and server-to-server traffic. Devices in this group also receive the default firewall GPO.
In your own design, create a group for each computer role in your organization that requires different or more firewall rules. For example, file servers and print servers require more rules to allow the incoming network traffic for those functions. If a function is ordinarily performed on most devices on the network, you might consider adding devices performing those roles to the common default firewall GPO set, unless there's a security reason not to include it there.
**Next:** [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md)

37
windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-boundary.md
View File

@ -1,37 +0,0 @@
---
title: GPO\_DOMISO\_Boundary
description: This example GPO supports devices that aren't part of the isolated domain to access specific servers that must be available to those untrusted devices.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# GPO\_DOMISO\_Boundary
This GPO is authored by using the Windows Defender 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 devices that aren't part of the isolated domain to access specific servers that must be available to those untrusted devices. It's intended to only apply to server devices that are running at least 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 device 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 device that isn't 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](isolated-domain.md).
## 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 devices. 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 doesn't also apply to the boundary zone to prevent overlapping, and possibly conflicting rules.
**Next:** [Encryption Zone GPOs](encryption-zone-gpos.md)

51
windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-encryption.md
View File

@ -1,51 +0,0 @@
---
title: GPO\_DOMISO\_Encryption\_WS2008
description: This example GPO supports the ability for servers that contain sensitive data to require encryption for all connection requests.
ms.topic: conceptual
ms.prod: windows-client
ms.date: 09/08/2021
---
# GPO\_DOMISO\_Encryption\_WS2008
This GPO is authored by using the Windows Defender 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's intended to only apply to server computers that are running Windows Server 2012, Windows Server 2008 R2, or 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 encryption, change the IPsec default settings for the GPO to enable the setting **Require encryption for all connection security rules that use these settings**. This setting 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](isolated-domain.md).
## 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 doesn't also apply to the boundary zone to prevent overlapping, and possibly conflicting rules.
**Next:** [Server Isolation GPOs](server-isolation-gpos.md)
 
 

59
windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-firewall.md
View File

@ -1,59 +0,0 @@
---
title: GPO\_DOMISO\_Firewall
description: Learn about the settings and rules in this example GPO, which is authored by using the Group Policy editing tools.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# GPO\_DOMISO\_Firewall
This GPO is authored by using the Windows Defender 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 devices that are running at least Windows 7 or Windows Server 2008.
## 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 devices 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 devices.
## 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 Defender Firewall Remote Management
- Windows Management Instrumentation (WMI)
- Windows Remote Management
- 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:** [Isolated Domain GPOs](isolated-domain-gpos.md)

77
windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-isolateddomain-clients.md
View File

@ -1,77 +0,0 @@
---
title: GPO\_DOMISO\_IsolatedDomain\_Clients
description: Author this GPO by using Windows Defender Firewall with Advanced Security interface in the Group Policy editing tools.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# GPO\_DOMISO\_IsolatedDomain\_Clients
This GPO is authored by using the Windows Defender Firewall with Advanced Security interface in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It's intended to only apply to client devices that are running Windows 8, Windows 7, or Windows Vista.
Because client devices can sometimes be portable, the settings and rules for this GPO are applied to only the domain profile.
## General settings
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](firewall-gpos.md) 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 algorithm 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, 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](isolated-domain.md).
| Setting | Value |
| - | - |
| Enable PMTU Discovery | 1 |
| IPsec Exemptions | 3 |
- 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.
| 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 devices 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 devices that can't run Windows or can't 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 devices that are in the exemption list from the requirement to authenticate:
- The IP addresses of all devices on the exemption list must be added individually under **Endpoint 2**.
- Authentication mode is set to **Do not authenticate**.
**Next:** [GPO\_DOMISO\_IsolatedDomain\_Servers](gpo-domiso-isolateddomain-servers.md)

20
windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-isolateddomain-servers.md
View File

@ -1,20 +0,0 @@
---
title: GPO\_DOMISO\_IsolatedDomain\_Servers
description: Author this GPO by using the Windows Defender Firewall with Advanced Security interface in the Group Policy editing tools.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# GPO\_DOMISO\_IsolatedDomain\_Servers
This GPO is authored by using the Windows Defender Firewall interface in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It's intended to only apply to server devices that are running at least Windows Server 2008.
Because so many of the settings and rules for this GPO are common to those settings and rules in the GPO for at least Windows Vista, you can save time by exporting the Windows Defender Firewall piece of the GPO for at least Windows Vista, and importing it to the GPO for at least 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 isn't 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 device to the Public profile with a different set of rules (the example of a server running Windows Server 2008).
>**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 device. If you attach a network adapter to a device that is not physically connected to a network, the public network location type is associated with the network adapter and applied to the device.
**Next:** [Boundary Zone GPOs](boundary-zone-gpos.md)

20
windows/security/operating-system-security/network-security/windows-firewall/isolated-domain-gpos.md
View File

@ -1,20 +0,0 @@
---
title: Isolated Domain GPOs
description: Learn about GPOs for isolated domains in this example configuration of Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Isolated Domain GPOs
All of the devices 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. For more information, see the [Planning GPO Deployment](planning-gpo-deployment.md) section.
The GPOs created for the Woodgrove Bank isolated domain include:
- [GPO\_DOMISO\_IsolatedDomain\_Clients](gpo-domiso-isolateddomain-clients.md)
- [GPO\_DOMISO\_IsolatedDomain\_Servers](gpo-domiso-isolateddomain-servers.md)

57
windows/security/operating-system-security/network-security/windows-firewall/isolated-domain.md
View File

@ -1,57 +0,0 @@
---
title: Isolated Domain
description: Learn about the isolated domain, which is the primary zone for trusted devices, which use connection security and firewall rules to control communication.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Isolated Domain
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and above
The isolated domain is the primary zone for trusted devices. The devices in this zone use connection security and firewall rules to control the communications that can be sent between devices 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 similar because Active Directory domain authentication (Kerberos V5) is required for accepting inbound connections from trusted devices. However, many Active Directory domains (or forests) can be linked with trust relationships to provide a single, logical, isolated domain. In addition, devices 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 devices. Other isolation zones can be created for the solution if their communication requirements differ from those requirements 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 link the GPOs that apply the rules to its members are discussed in the [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) section.
The GPOs for the isolated domain should contain the following connection security rules and settings.
## GPO settings for isolated domain members running at least Windows Vista and Windows Server 2008
GPOs for devices running at least Windows Vista and Windows Server 2008 should include:
- IPsec default settings that specify the following options:
1. Exempt all ICMP traffic from IPsec.
2. Key exchange (main mode) security methods and algorithm. We recommend that you use at least DH4, AES and SHA2 in your settings. Use the strongest algorithm combinations that are common to all your supported operating systems.
3. Data protection (quick mode) algorithm combinations. We recommend that you don't include DES, or MD5 in any setting. They're 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, use ESP encapsulation. 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.
4. Authentication methods. Include at least device-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 can't 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 devices 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 devices 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. 
- A registry policy that includes the following values:
- 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](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md) sets the value to **1**.
>**Note:**  For a sample template for these registry settings, see [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md).
**Next:** [Boundary Zone](boundary-zone.md)

27
windows/security/operating-system-security/network-security/windows-firewall/mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md
View File

@ -1,27 +0,0 @@
---
title: Mapping your implementation goals to a Windows Firewall with Advanced Security design
description: Mapping your implementation goals to a Windows Firewall with Advanced Security design
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Mapping your implementation goals to a Windows Firewall with Advanced Security design
After you finish reviewing the existing Windows Firewall with Advanced Security implementation 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 implementation 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 implementation goals to meet the needs of your organization.
| Deployment Goals | Basic Firewall Policy Design | Domain Isolation Policy Design | Server Isolation Policy Design | Certificate-based Isolation Policy Design |
| - |- | - | - | - |
| [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md)| Yes| Yes| Yes| Yes|
| [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md) | -| Yes| Yes| Yes|
| [Restrict Access to Only Specified Users or Devices](restrict-access-to-only-specified-users-or-devices.md)| -| -| Yes| Yes|
| [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)| -| 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](basic-firewall-policy-design.md)

48
windows/security/operating-system-security/network-security/windows-firewall/planning-certificate-based-authentication.md
View File

@ -1,48 +0,0 @@
---
title: Planning Certificate-based Authentication
description: Learn how a device unable to join an Active Directory domain can still participate in an isolated domain by using certificate-based authentication.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning Certificate-based Authentication
Sometimes a device can't join an Active Directory domain, and therefore can't use Kerberos V5 authentication with domain credentials. However, the device 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 device sends a copy of its certificate to the other device. Each device 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 device.
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 2012, Windows Server 2008 R2, and Windows Server 2008 Active Directory Certificate Services (AD CS).
## 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 device certificates in-house, then the servers designated as certification authorities (CAs) create the certificates based on administrator-designed templates. AD CS then uses Group Policy to deploy the certificates to domain member devices. Device certificates are deployed when a domain member device starts. User certificates are deployed when a user logs on.
If you want non-domain member devices 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 device or user includes enough identification information to enable IPsec to match the certificate to both user and device accounts.
AD CS automatically ensures that certificates issued by the CAs are trusted by the client devices by putting the CA certificates in the correct store on each domain member device.
### Using a commercially purchased certificate for devices running Windows
You can import the certificates manually onto each device if the number of devices is relatively small. For a deployment to more than a handful of devices, 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 device 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 device that applies the GPO.
### Using a commercially purchased certificate for devices running a non-Windows operating system
If you're 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 devices that are members of authorized groups in a server isolation solution.
Starting in Windows Server 2012, you can configure certificate selection criteria so the desired certificate is selected and/or validated. extended key usage (EKU) criteria can be configured, and name restrictions and certificate thumbprints. This EKU is configured using the **Advanced** button when choosing certificates for the authentication method in the user interface, or through Windows PowerShell.
**Next:** [Documenting the Zones](documenting-the-zones.md)

24
windows/security/operating-system-security/network-security/windows-firewall/planning-domain-isolation-zones.md
View File

@ -1,24 +0,0 @@
---
title: Planning Domain Isolation Zones
description: Learn how to use information you've gathered to make decisions about isolation zones for your environment in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning Domain Isolation Zones
After you have the required information about your network, Active Directory, and client and server devices, 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 devices to assign to each isolation zone. Correctly choosing the zone for each device is important to providing the correct level of security without compromising performance or the ability for a device to send or receive required network traffic.
The zones described in this guide include:
- [Exemption List](exemption-list.md)
- [Isolated Domain](isolated-domain.md)
- [Boundary Zone](boundary-zone.md)
- [Encryption Zone](encryption-zone.md)

110
windows/security/operating-system-security/network-security/windows-firewall/planning-gpo-deployment.md
View File

@ -1,110 +0,0 @@
---
title: Planning GPO Deployment
description: Learn how to use security group filtering and WMI filtering to provide the most flexible options for applying GPOs to devices in Active Directory.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning GPO Deployment
You can control which GPOs are applied to devices in Active Directory in a combination of three ways:
- **Active Directory organizational unit hierarchy**. This method involves linking the GPO to a specific OU in the Active Directory OU hierarchy. All devices 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 devices based on their location within Active Directory. If a device 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 method involves linking the GPOs to the domain level (or other parent OU) in the OU hierarchy, and then selecting which devices 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 devices 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 device is a member of the result set when the WMI filter query runs, the GPO is applied to the device.
A WMI filter consists of one or more conditions that are evaluated against the local device. You can check almost any characteristic of the device, its operating system, and its installed programs. If all of the specified conditions are true for the device, the GPO is applied; otherwise the GPO is ignored.
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
- Deploy your GPOs before you add any device accounts to the groups that receive the GPOs. That way you can add your devices to the groups in a controlled manner. Be sure to add only a few test devices at first. Before adding many group members, examine the results on the test devices 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've deployed your GPOs and added some test devices 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 device. Run the **gpresult** tool at a command prompt.
- Examine the rules deployed to the device. Open the Windows Defender Firewall MMC snap-in, expand the **Monitoring** node, and then expand the **Firewall** and **Connection Security** nodes.
- Verify that communications are authenticated. Open the Windows Defender Firewall MMC snap-in, expand the **Monitoring** node, expand the **Security Associations** node, and then click **Main Mode**.
- Verify that communications are encrypted when the devices require it. Open the Windows Defender Firewall MMC snap-in, expand the **Monitoring** node, expand the **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've confirmed that the GPOs have been correctly applied, and that the devices are now communicating by using IPsec network traffic in request mode, you can begin to add more devices to the group accounts, in manageable numbers at a time. Continue to monitor and confirm the correct application of the GPOs to the devices.
## Don't enable require mode until deployment is complete
If you deploy a GPO that requires authentication to a device before the other devices 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 devices 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, devices can continue to operate, because request mode enables any device to fall back to clear communications.
Only after you've added all of the devices to their zones, and you've confirmed that communications are working as expected, you can start changing the request mode rules to require mode rules where it's required in the zones. We recommend that you enable require mode in the zones one zone at a time, pausing to confirm that they're 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.
Don't 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 devices 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 devices. All of the GPOs have the User Configuration section disabled to improve performance.
### GPO\_DOMISO\_Firewall
- **WMI filter**. The WMI filter allows this GPO to apply only to devices that match the following WMI query:
`select * from Win32_OperatingSystem where Version like "6.%" 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 devices 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 devices that are members of the group CG\_DOMISO\_IsolatedDomain. The GPO also explicitly denies Read and Apply Group Policy permissions to members of the CG\_DOMISO\_NO\_IPSEC.
### GPO\_DOMISO\_IsolatedDomain\_Clients
- **WMI filter**. The WMI filter allows this GPO to apply only to devices that match the following WMI query:
`select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"`
- **Security filter**. This GPO grants Read and Apply Group Policy permissions only to devices 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\_NO\_IPSEC.
### GPO\_DOMISO\_IsolatedDomain\_Servers
- **WMI filter**. The WMI filter allows this GPO to apply only to devices that match the following WMI query:
`select * from Win32_OperatingSystem where Version like "6.%" 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 devices 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 devices 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\_NO\_IPSEC.
### GPO\_DOMISO\_Boundary
- **WMI filter**. The WMI filter allows this GPO to apply only to devices that match the following WMI query:
`select * from Win32_OperatingSystem where Version like "6.%" 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 devices 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 devices 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\_NO\_IPSEC.
### GPO\_DOMISO\_Encryption
- **WMI filter**. The WMI filter allows this GPO to apply only to devices that match the following WMI query:
`select * from Win32_OperatingSystem where Version like "6.%" 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 devices 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 devices 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\_NO\_IPSEC.

22
windows/security/operating-system-security/network-security/windows-firewall/planning-group-policy-deployment-for-your-isolation-zones.md
View File

@ -1,22 +0,0 @@
---
title: Planning Group Policy Deployment for Your Isolation Zones
description: Learn how to plan a group policy deployment for your isolation zones after you determine the best logical design for your isolation environment.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning Group Policy Deployment for Your Isolation Zones
After you've decided on the best logical design of your isolation environment for the network and device 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 device 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'll ensure that the policies will only apply to the correct devices within each group.
- [Planning Isolation Groups for the Zones](planning-isolation-groups-for-the-zones.md)
- [Planning Network Access Groups](planning-network-access-groups.md)
- [Planning the GPOs](planning-the-gpos.md)
- [Planning GPO Deployment](planning-gpo-deployment.md)

34
windows/security/operating-system-security/network-security/windows-firewall/planning-isolation-groups-for-the-zones.md
View File

@ -1,34 +0,0 @@
---
title: Planning Isolation Groups for the Zones
description: Learn about planning isolation groups for the zones in Microsoft Firewall, including information on universal groups and GPOs.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning Isolation Groups for the Zones
Isolation groups in Active Directory are how you implement the various domain and server isolation zones. A device is assigned to a zone by adding its device account to the group that represents that zone.
> [!CAUTION]
> Do not add devices to your groups yet. If a device is in a group when the GPO is activated then that GPO is applied to the device. If the GPO is one that requires authentication, and the other devices have not yet received their GPOs, the device 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 device accounts that don't participate in the IPsec environment. Typically consists of infrastructure device accounts that will also be included in exemption lists.<br/>This group is used in security group filters to ensure that GPOs with IPsec rules aren't applied to group members.|
| CG_DOMISO_IsolatedDomain | A universal group of device accounts that contains the members of the isolated domain.<br/>During the early days of testing, this group might contain only a small number of devices. During production, it might contain the built-in **Domain Computers** group to ensure that every device in the domain participates.<br/>Members of this group receive the domain isolation GPO that requires authentication for inbound connections.|
| CG_DOMISO_Boundary | A universal group of device accounts that contains the members of the boundary zone.<br/><p>Members of this group receive a GPO that specifies that authentication is requested, but not required.|
| CG_DOMISO_Encryption | A universal group of device accounts that contains the members of the encryption zone.<br/>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 device accounts that contains the members of the server isolation group.<br/>Members of this group receive the server isolation GPO that requires membership in a network access group in order to connect.<br/>There will be one group for each set of servers that have different user and device restriction requirements. |
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](planning-the-gpos.md).
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 device. 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's more specific.
**Next:** [Planning Network Access Groups](planning-network-access-groups.md)

27
windows/security/operating-system-security/network-security/windows-firewall/planning-network-access-groups.md
View File

@ -1,27 +0,0 @@
---
title: Planning Network Access Groups
description: Learn how to implement a network access group for users and devices that can access an isolated server in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning Network Access Groups
A network access group (NAG) is used to identify users and devices that have permission to access an isolated server. The server is configured with firewall rules that allow only network connections that are authenticated as originating from a device, 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 devices or users that are granted access. You can optionally split the NAG into two different groups: one for authorized devices 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 devices running SQL Server which support the WGBank application are restricted to the WGBank front-end servers and to approved administrative users logged on to specific authorized administrative devices. They're 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, Computers, or Groups | Description |
| - | - | - |
| CG_NAG_*ServerRole*_Users| Svr1AdminA<br/>Svr1AdminB<br/>Group_AppUsers<br/>AppSvcAccount| This group is for all users who are authorized to make inbound IPsec connections to the isolated servers in this zone.|
| CG_NAG_*ServerRole*_Computers| Desktop1<br/>Desktop2<br/>AdminDT1<br/>AppAdminDT1| This group contains all devices 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 device 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](planning-the-gpos.md)

68
windows/security/operating-system-security/network-security/windows-firewall/planning-server-isolation-zones.md
View File

@ -1,68 +0,0 @@
---
title: Planning Server Isolation Zones
description: Learn how to restrict access to a server to approved users by using a server isolation zone in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# 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 devices 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 devices 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 devices.
To grant access, you add the approved user and device 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 invocation causes IKE to use Kerberos V5 to exchange credentials with the server. The other firewall rule on the server causes Windows to check the provided device and user accounts for group membership in the NAGs. If either the user or device isn't a member of a required NAG, then the network connection is refused.
## Isolated domains and isolated servers
If you're using an isolated domain, the client devices 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 device or user.
If you aren't using an isolated domain, but still want to isolate a server that uses IPsec, you must configure the client devices that you want to access the server to use the appropriate IPsec rules. If the client devices 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](planning-group-policy-deployment-for-your-isolation-zones.md) 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 at least Windows Server 2008
GPOs for devices running at least Windows Server 2008 should include:
>**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:
1. Exempt all ICMP traffic from IPsec.
2. Key exchange (main mode) security methods and algorithm. We recommend that you don't include Diffie-Hellman Group 1, DES, or MD5 in any setting. They're included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems.
3. 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 don't include DES or MD5 in any setting. They're 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, don't use AH because it can't 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.
4. Authentication methods. Include at least device-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. Don't make the user-based authentication method mandatory, or else devices that can't use AuthIP instead of IKE, including Windows XP and Windows Server 2003, can't communicate. Likewise, if any of your domain isolation members can't use Kerberos V5, include certificate-based authentication as an optional authentication method.
- The following connection security and firewall rules:
s
- A connection security rule that exempts all devices 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 devices 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 device and user network access groups.
- A registry policy that includes the following values:
- 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](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md) sets the value to **1**.
>**Note:**  For a sample template for these registry settings, see [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md).
**Next:** [Planning Certificate-based Authentication](planning-certificate-based-authentication.md)

44
windows/security/operating-system-security/network-security/windows-firewall/planning-settings-for-a-basic-firewall-policy.md
View File

@ -1,44 +0,0 @@
---
title: Planning Settings for a Basic Firewall Policy
description: Learn how to design a basic policy for Windows Defender Firewall with Advanced Security, the settings and rules that enforce your requirements on devices.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning Settings for a Basic Firewall Policy
After you've identified your requirements, and have the information about the network layout and devices available, you can begin to design the GPO settings and rules that will enable you to enforce your requirements on the devices.
The following list is that 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**. 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 devices 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 aren't on the organization's network, you can't 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:**  We recommend that on server devices 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 devices, and only support different profiles on portable devices.
- **Firewall state: On**. We recommend that you prevent the user from turning it off.
- **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.
- **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 setting to **No**, then when a user clicks **Allow** on the notification message to allow traffic for a new program, Windows doesn't 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 Defender Firewall with Advanced Security service account has write permissions.
- **Inbound rules**. Create inbound rules for programs that must be able to receive unsolicited inbound network packets from another device on the network. Make the rules as specific 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 can't receive unexpected traffic on a different port.
Inbound rules are common on servers, because they host services to which client devices 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 don't 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.md)

51
windows/security/operating-system-security/network-security/windows-firewall/planning-the-gpos.md
View File

@ -1,51 +0,0 @@
---
title: Planning the GPOs
description: Learn about planning Group Policy Objects for your isolation zones in Windows Defender Firewall with Advanced Security, after you design the zone layout.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# 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 devices to the zones.
## General considerations
A few things to consider as you plan the GPOs:
- Don't allow a device to be a member of more than one isolation zone. A device in more than one zone receives multiple and possibly contradictory GPOs. This receipt of multiple GPOs 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.
- Ensure that the IPsec algorithms you specify in your GPOs are compatible across all the versions of Windows. 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 devices will negotiate down from the top of their lists, selecting one that is configured on both devices.
- 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 devices over time, applying a require policy to one device breaks its ability to communicate with another device that has not yet received its policy. Using request mode at the beginning enables devices to continue communicating by using plaintext connections if required. After you confirm that your devices 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.
- Windows Defender Firewall* 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 device. If your GPO specifies different firewall and connection security rules based on the current network location profile, the behavior of how the device handles network traffic will change accordingly. We recommend for stationary devices, such as desktops and servers, that you assign any rule for the device to all profiles. Apply GPOs that change rules per network location to devices that must move between networks, such as your portable devices. 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.
*Windows Defender Firewall is now called Windows Defender Firewall with Advanced Security in Windows 10 and Windows 11.
> [!NOTE]
> Devices running Windows 7, Windows Server 2008 R2, and later support different network location types, and therefore profiles, for each network adapter at the same time. Each network adapter is assigned the network location appropriate for the network to which it is connected. Windows Defender Firewall then enforces only those rules that apply to that network type’s profile. So certain types of traffic are blocked when coming from a network adapter connected to a public network, but those same types might be permitted when coming from a private or domain network.
After you consider 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 devices receive the GPO, such as security group filtering and WMI filtering, are discussed in the [Planning GPO Deployment](planning-gpo-deployment.md) section.
In this section you can find information about:
- [Firewall GPOs](firewall-gpos.md)
- [Isolated Domain GPOs](isolated-domain-gpos.md)
- [Boundary Zone GPOs](boundary-zone-gpos.md)
- [Encryption Zone GPOs](encryption-zone-gpos.md)
- [Server Isolation GPOs](server-isolation-gpos.md)

54
windows/security/operating-system-security/network-security/windows-firewall/planning-to-deploy-windows-firewall-with-advanced-security.md
View File

@ -1,54 +0,0 @@
---
title: Plan to Deploy Windows Defender Firewall with Advanced Security
description: Use the design information in this article to plan for the deployment of Windows Defender Firewall with Advanced Security in your organization.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning to Deploy Windows Defender Firewall with Advanced Security
After you collect information about your environment and decide on a design by following the guidance in the [Windows Defender Firewall with Advanced Security Design Guide](windows-firewall-with-advanced-security-design-guide.md), 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 Defender Firewall with Advanced Security in your organization.
## Reviewing your Windows Defender Firewall with Advanced Security Design
If the design team that created the Windows Defender Firewall design for your organization is different from the deployment team that will implement it, make sure the deployment team reviews the final design with the design team. Review the following information before starting your deployment.
### Decide which devices apply to which GPO
The design team's strategy for determining how WMI and security group filters attached to the GPOs will determine which devices apply to which GPO. The deployment team can refer to the following topics in the Windows Defender Firewall with Advanced Security Design Guide:
- [Planning Isolation Groups for the Zones](planning-isolation-groups-for-the-zones.md)
- [Planning the GPOs](planning-the-gpos.md)
- [Planning GPO Deployment](planning-gpo-deployment.md)
### Configure communication between members and devices
Decide what communication is to be allowed between members of each of the zones in the isolated domain and devices that aren't part of the isolated domain or members of the isolated domain's exemption list.
### Exempt domain controllers from IPsec authentication requirements
It's recommended that domain controllers are exempt from IPsec authentication requirements. If they aren't 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.
### Configure IPsec authentication rules
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 devices might fail. If the rules are set to request authentication only, then an IPsec authentication failure results in fall-back-to-clear behavior. Communications can continue while the authentication failures are investigated.
### Make sure all devices can communicate with each other
For all devices to communicate with each other, they must share a common set of:
- Authentication methods
- Main mode key exchange algorithms
- Quick mode data integrity algorithms
If at least one set of each doesn't match between two devices, then the devices can't successfully communicate.
## Deploy your Windows Firewall Design Plan
After the design and deployment teams agree on these issues, they can proceed with the deployment of the Windows Defender Firewall design. For more information, see [Implementing Your Windows Defender Firewall with Advanced Security Design Plan](implementing-your-windows-firewall-with-advanced-security-design-plan.md).

84
windows/security/operating-system-security/network-security/windows-firewall/planning-your-windows-firewall-with-advanced-security-design.md
View File

@ -1,84 +0,0 @@
---
title: Planning Your Windows Defender Firewall with Advanced Security Design
description: After you gather the relevant information, select the design or combination of designs for Windows Defender Firewall with Advanced Security in your environment.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Planning Your Windows Defender Firewall with Advanced Security Design
After you've gathered the relevant information in the previous sections, and understood 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 Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md) 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're ready to examine the options for firewall policy settings, see the [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md) 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, and their relative strengths.
## IPsec performance considerations
Although IPsec is critically important in securing network traffic going to and from your devices, there are costs associated with its use. The mathematically intensive cryptographic algorithms require a significant amount of computing power, which can prevent your device from making use of all of the available bandwidth. For example, an IPsec-enabled device using the AES encryption protocols on a 10 gigabits per second (Gbps) network link might see a throughput of 4.5 Gbps. This reduction 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 configuration frees up a device’s CPU and can dramatically increase network throughput. For the same network link as above, the throughput with IPsec task offload enabled improves to about 9.2 Gbps.
## Domain isolation design
Include this design in your plans:
- If you have an Active Directory domain of which most of the devices are members.
- If you want to prevent the devices in your organization from accepting any unsolicited network traffic from devices that aren't part of the domain.
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're sure that the devices are all correctly protecting network traffic with IPsec. If something is wrong, request mode still allows communications to continue while you're troubleshooting.
When you're ready to examine the options for creating an isolated domain, see the [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) 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 devices.
- You aren't 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 devices.
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 other server isolation elements.
When you're ready to examine the options for isolating servers, see the [Planning Server Isolation Zones](planning-server-isolation-zones.md) 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 devices that aren't joined to an Active Directory domain, or don't want to use domain membership as an authentication mechanism.
- You have an isolated domain and want to include a server that isn't a member of the Active Directory domain because the device isn't running Windows, or for any other reason.
- You must enable external devices that aren't managed by your organization to access information on one of your servers 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 devices that require it.
When you're ready to examine the options for using certificate-based authentication, see the [Planning Certificate-based Authentication](planning-certificate-based-authentication.md) section.
## Documenting your design
After you finish selecting the designs that you'll use, you must assign each of your devices to the appropriate isolation zone and document the assignment for use by the deployment team.
- [Documenting the Zones](documenting-the-zones.md)
## Designing groups and GPOs
After you've selected a design and assigned your devices 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'll use to apply the settings and rules to your devices.
When you're ready to examine the options for the groups, filters, and GPOs, see the [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) section.
**Next:** [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md)

27
windows/security/operating-system-security/network-security/windows-firewall/server-isolation-gpos.md
View File

@ -1,27 +0,0 @@
---
title: Server Isolation GPOs
description: Learn about required GPOs for isolation zones and how many server isolation zones you need in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 11/10/2023
---
# Server Isolation GPOs
Each set of devices that have different users or devices accessing them require a separate server isolation zone. Each zone requires one GPO for each version of Windows running on devices in the zone. The *Woodgrove Bank* example has an isolation zone for their devices 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 device accounts for devices 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 devices aren't 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
This GPO is identical to the *GPO_DOMISO_Encryption* 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 permissions include *CG_NAG_SQL_Users* and *CG_NAG_SQL_Computers*.
## Next steps
> [!div class="nextstepaction"]
> Learn how to use security group filtering and WMI filtering to provide the most flexible options for applying GPOs to devices in Active Directory.
>
>
> [Plan GPO Deployment >](planning-gpo-deployment.md)

69
windows/security/operating-system-security/network-security/windows-firewall/server-isolation-policy-design-example.md
View File

@ -1,69 +0,0 @@
---
title: Server Isolation Policy Design Example
description: Learn about server isolation policy design in Windows Defender Firewall with Advanced Security by referring to this example of a fictitious company.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 11/10/2023
---
# Server Isolation Policy Design Example
This design example continues to use the fictitious company *Woodgrove Bank*, as described in the [Firewall Policy Design Example](firewall-policy-design-example.md) section and the [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md) section.
In addition to the protections provided by the firewall and domain isolation, *Woodgrove Bank* wants to provide extra protection to the devices 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. These rules and regulations include 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 devices, and the information presented by the WGPartner servers to the remote partner devices, aren't considered sensitive for the purposes of the government regulations, because they're processed to remove sensitive elements before transmitting the data to the client devices.
In this guide, the examples show server isolation layered on top of a domain isolation design. If you have an isolated domain, the client devices are already equipped with GPOs that require authentication. You only have to add settings to the isolated server(s) to require authentication on 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 devices 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 devices 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 don't have an Active Directory domain, you can manually apply the connection security rules, use a netsh command-line script, or use a Windows PowerShell script to help automate the configuration of the rules on larger numbers of devices. If you don't have an Active Directory domain, you can't 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 devices that run SQL Server.
The following illustration shows the traffic protection needs for this design example.
![isolated server example.](images/wfas-design3example1.gif)
1. Access to the SQL Server devices must be restricted to only those computer or user accounts that have a business requirement to access the data. These accounts include the service accounts that are used by the WGBank front-end servers, and administrators of the SQL Server devices. In addition, access is only granted when it's sent from an authorized computer. Authorization is determined by membership in a network access group (NAG)
1. All network traffic to and from the SQL Server devices must be encrypted
1. Client devices or users whose accounts aren't members of the NAG can't access the isolated servers
### Other traffic notes
- All of the design requirements shown in the [Firewall Policy Design Example](firewall-policy-design-example.md) section are still enforced
- All of the design requirements shown in the [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md) section are still enforced
## Design details
*Woodgrove Bank* uses Active Directory groups and GPOs to deploy the server isolation settings and rules to the devices 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 devices that run Windows were added to the correct groups.
- **CG_SRVISO_WGBANK_SQL**. This group contains the computer accounts for the devices 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're using a computer that is a member of the group CG_NAG_SQL_COMPUTERS.
> [!NOTE]
> 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, devices 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 devices that are incorrectly assigned to more than one group.
Network access groups (NAGs) aren't used to determine which GPOs are applied to a computer. Instead, these groups determine which users and devices 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 devices running SQL Server hosting the WGBank data. Members of this group include the WGBank front-end servers, and some client devices 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 devices that host the WGBank data. Members of this group include the service account that the WGBank front-end program uses to run on its devices, 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 that apply connection security rules to the client devices. By doing this task, all the devices that are authorized to access the isolated server also have the required connection security rules.
You don't have to include the encryption-capable rules on all devices. Instead, you can create GPOs that are applied only to members of the NAG, in addition to the standard domain isolation GPO, that contains connection security rules to support encryption.
> [!div class="nextstepaction"]
>
> [Certificate-based Isolation Policy Design Example >](certificate-based-isolation-policy-design-example.md)

44
windows/security/operating-system-security/network-security/windows-firewall/server-isolation-policy-design.md
View File

@ -1,44 +0,0 @@
---
title: Server Isolation Policy Design
description: Learn about server isolation policy design, where you assign servers to a zone that allows access only to members of an approved network access group.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 11/10/2023
---
# Server Isolation Policy Design
In the server isolation policy design, you assign servers to a zone that allows access only to users and devices 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](domain-isolation-policy-design.md) section. For this design, you then create zones for servers that have more 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. These restrictions and requirements 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 implementation, you use the same principles as domain isolation, but instead of applying them to an Active Directory domain, you apply them only to the devices 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 devices can access the isolated server are also used to determine which devices receive the GPO.
The design is shown in the following illustration, with arrows that show the permitted communication paths.
![isolated domain with isolated server.](images/wfas-domainisohighsec.gif)
Characteristics of this design include:
- Isolated domain (area A) - The same isolated domain described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) section. If the isolated domain includes a boundary zone, then devices in the boundary zone behave just like other members of the isolated domain in the way that they interact with devices in server isolation zones.
- Isolated servers (area B) - Devices in the server isolation zones restrict access to devices, 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](domain-isolation-policy-design.md), which in turn builds on the [Basic Firewall Policy Design](basic-firewall-policy-design.md). If you plan to deploy all three designs, do the design work for all three together, and then deploy in the sequence presented.
This design can be applied to devices 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 info about this design:
- This design coincides with the implementation goals to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md), [Restrict Access to Only Specified Users or Devices](restrict-access-to-only-specified-users-or-devices.md), and [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
- To learn more about this design, see [Server Isolation Policy Design Example](server-isolation-policy-design-example.md).
- Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
- To help you make the decisions required in this design, see [Planning Server Isolation Zones](planning-server-isolation-zones.md) and [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md).
- 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](checklist-implementing-a-standalone-server-isolation-policy-design.md).
> [!div class="nextstepaction"]
>
> [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md)