This commit is contained in:
Paolo Matarazzo
2023-11-11 08:30:01 -05:00
parent 7711542e21
commit 0d442a31d6
38 changed files with 42 additions and 1846 deletions

View File

@ -7774,6 +7774,21 @@
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security-design-guide.md", "source_path": "windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security-design-guide.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc732024(v=ws.10)", "redirect_url": "/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc732024(v=ws.10)",
"redirect_document_id": false "redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/add-production-devices-to-the-membership-group-for-a-zone.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj717262(v=ws.11)",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/add-test-devices-to-the-membership-group-for-a-zone.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj717263(v=ws.11)",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/assign-security-group-filters-to-the-gpo.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj717260(v=ws.11)",
"redirect_document_id": false
} }
] ]
} }

View File

@ -1,97 +1,33 @@
items: items:
- name: Overview - name: Overview
href: windows-firewall-with-advanced-security.md href: windows-firewall-with-advanced-security.md
- name: Best practices - name: Configure Hyper-V firewall
items: href: hyper-v-firewall.md
- name: Configure the firewall - name: Configure the Windows Firewall log
href: best-practices-configuring.md href: configure-the-windows-firewall-log.md
- name: Secure IPsec - name: Create an inbound ICMP rule
href: securing-end-to-end-ipsec-connections-by-using-ikev2.md href: create-an-inbound-icmp-rule.md
- name: PowerShell - name: Create an inbound port rule
href: windows-firewall-with-advanced-security-administration-with-windows-powershell.md href: create-an-inbound-port-rule.md
- name: Isolate Microsoft Store Apps on Your Network - name: Create an inbound program or service rule
href: isolating-apps-on-your-network.md href: create-an-inbound-program-or-service-rule.md
- name: How-to - name: Create an outbound port rule
items: href: create-an-outbound-port-rule.md
- name: Add Production devices to the membership group for a zone - name: Create an outbound program or service rule
href: add-production-devices-to-the-membership-group-for-a-zone.md href: create-an-outbound-program-or-service-rule.md
- name: Add test devices to the membership group for a zone - name: Create inbound rules to support RPC
href: add-test-devices-to-the-membership-group-for-a-zone.md href: create-inbound-rules-to-support-rpc.md
- name: Assign security group filters to the GPO - name: Create Windows Firewall rules in Intune
href: assign-security-group-filters-to-the-gpo.md href: create-windows-firewall-rules-in-intune.md
- name: Change rules from request to require mode - name: Configure the firewall
href: Change-Rules-From-Request-To-Require-Mode.Md href: best-practices-configuring.md
- name: Configure authentication methods - name: Secure IPsec
href: Configure-authentication-methods.md href: securing-end-to-end-ipsec-connections-by-using-ikev2.md
- name: Configure data protection (Quick Mode) settings - name: PowerShell
href: configure-data-protection-quick-mode-settings.md href: windows-firewall-with-advanced-security-administration-with-windows-powershell.md
- name: Configure Group Policy to autoenroll and deploy certificates - name: Isolate Microsoft Store Apps on Your Network
href: configure-group-policy-to-autoenroll-and-deploy-certificates.md href: isolating-apps-on-your-network.md
- name: Configure Hyper-V firewall - name: Troubleshoot
href: hyper-v-firewall.md
- name: Configure key exchange (main mode) settings
href: configure-key-exchange-main-mode-settings.md
- name: Configure the rules to require encryption
href: configure-the-rules-to-require-encryption.md
- name: Configure the Windows Firewall log
href: configure-the-windows-firewall-log.md
- name: Configure the workstation authentication certificate template
href: configure-the-workstation-authentication-certificate-template.md
- name: Configure Windows Firewall to suppress notifications when a program is blocked
href: configure-windows-firewall-to-suppress-notifications-when-a-program-is-blocked.md
- name: Confirm that certificates are deployed correctly
href: confirm-that-certificates-are-deployed-correctly.md
- name: Copy a GPO to create a new GPO
href: copy-a-gpo-to-create-a-new-gpo.md
- name: Create a Group Account in Active Directory
href: create-a-group-account-in-active-directory.md
- name: Create a Group Policy Object
href: create-a-group-policy-object.md
- name: Create an authentication exemption list rule
href: create-an-authentication-exemption-list-rule.md
- name: Create an authentication request rule
href: create-an-authentication-request-rule.md
- name: Create an inbound ICMP rule
href: create-an-inbound-icmp-rule.md
- name: Create an inbound port rule
href: create-an-inbound-port-rule.md
- name: Create an inbound program or service rule
href: create-an-inbound-program-or-service-rule.md
- name: Create an outbound port rule
href: create-an-outbound-port-rule.md
- name: Create an outbound program or service rule
href: create-an-outbound-program-or-service-rule.md
- name: Create inbound rules to support RPC
href: create-inbound-rules-to-support-rpc.md
- name: Create WMI filters for the GPO
href: create-wmi-filters-for-the-gpo.md
- name: Create Windows Firewall rules in Intune
href: create-windows-firewall-rules-in-intune.md
- name: Enable predefined inbound rules
href: enable-predefined-inbound-rules.md
- name: Enable predefined outbound rules
href: enable-predefined-outbound-rules.md
- name: Exempt ICMP from authentication
href: exempt-icmp-from-authentication.md
- name: Link the GPO to the domain
href: link-the-gpo-to-the-domain.md
- name: Modify GPO filters
href: modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md
- name: Open IP security policies
href: open-the-group-policy-management-console-to-ip-security-policies.md
- name: Open Group Policy
href: open-the-group-policy-management-console-to-windows-firewall.md
- name: Open Group Policy
href: open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md
- name: Open Windows Firewall
href: open-windows-firewall-with-advanced-security.md
- name: Restrict server access
href: restrict-server-access-to-members-of-a-group-only.md
- name: Enable Windows Firewall
href: turn-on-windows-firewall-and-configure-default-behavior.md
- name: Verify Network Traffic
href: verify-that-network-traffic-is-authenticated.md
- name: Troubleshooting
items: items:
- name: Troubleshoot UWP app connectivity issues in Windows Firewall - name: Troubleshoot UWP app connectivity issues in Windows Firewall
href: troubleshooting-uwp-firewall.md href: troubleshooting-uwp-firewall.md

View File

@ -1,55 +0,0 @@
---
title: Add Production Devices to the Membership Group for a Zone
description: Learn how to add production devices to the membership group for a zone and refresh the group policy on the devices in the membership group.
ms.prod: windows-client
ms.topic: how-to
ms.date: 11/10/2023
---
# Add Production Devices to the Membership Group for a Zone
After you test the GPOs for your design on a small set of devices, you can deploy them to the production devices.
> [!CAUTION]
> For GPOs that contain connection security rules that prevent unauthenticated connections, ensure you set the rules to request, not require, authentication during testing. After you deploy the GPO and confirm that all of your devices are successfully communicating by using authenticated IPsec, then you can modify the GPO to require authentication. Don't change the boundary zone GPO to require mode.
The method discussed in this guide uses the *Domain Computers* built-in group. The advantage of this method is that all new devices that are joined to the domain automatically receive the isolated domain GPO. To define this setting successfully, you must make sure that the WMI filters and security group filters exclude devices that must not receive the GPOs. Use device groups that deny both read and apply Group Policy permissions to the GPOs, such as a group used in the *CG_DOMISO_NOIPSEC* example design. Devices that are members of some zones must also be excluded from applying the GPOs for the main isolated domain. For more information, see the "Prevent members of a group from applying a GPO" section in [Assign Security Group Filters to the GPO](assign-security-group-filters-to-the-gpo.md).
Without such a group (or groups), you must either add devices individually or use the groups containing device accounts that are available to you.
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the membership of the group for the GPO.
In this topic:
- [Add the group Domain Devices to the GPO membership group](#to-add-domain-devices-to-the-gpo-membership-group)
- [Refresh Group Policy on the devices in the membership group](#to-refresh-group-policy-on-a-device)
- [Check which GPOs apply to a device](#to-see-which-gpos-are-applied-to-a-device)
## To add domain devices to the GPO membership group
1. Open Active Directory Users and Computers
1. In the navigation pane, expand **Active Directory Users and Computers**, expand *YourDomainName*, and then the container in which you created the membership group
1. In the details pane, double-click the GPO membership group to which you want to add computers
1. Select the **Members** tab, and then click **Add**
1. Type **Domain Computers** in the text box, and then click **OK**
1. Click **OK** to close the group properties dialog box
After a computer is a member of the group, you can force a Group Policy refresh on the computer.
## To refresh Group Policy on a device
From an elevated command prompt, type the following command:
``` cmd
gpupdate.exe /target:computer /force
```
After Group Policy is refreshed, you can see which GPOs are currently applied to the computer.
## To see which GPOs are applied to a device
From an elevated command prompt, type the following command:
``` cmd
gpresult.exe /r /scope:computer
```

View File

@ -1,51 +0,0 @@
---
title: Add Test Devices to the Membership Group for a Zone
description: Learn how to add devices to the group for a zone to test whether your Windows Defender Firewall with Advanced Security implementation works as expected.
ms.prod: windows-client
ms.topic: how-to
ms.date: 11/10/2023
---
# Add Test Devices to the Membership Group for a Zone
Before you deploy your rules to large numbers of devices, you must thoroughly test the rules to make sure that communications are working as expected. A misplaced WMI filter or an incorrectly typed IP address in a filter list can easily block communications between devices. Although we recommend that you set your rules to request mode until testing and deployment is complete. We also recommend that you initially deploy the rules to a few devices only to be sure that the correct GPOs are being processed by each device.
Add at least one device of each supported operating system type to each membership group. Make sure every GPO for a specific version of Windows and membership group has a device among the test group. After Group Policy has been refreshed on each test device, check the output of the `gpresult.exe` command to confirm that each device is receiving only the GPOs it's supposed to receive.
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the membership of the group for the GPO.
In this topic:
- [Add the test devices to the GPO membership groups](#to-add-test-devices-to-the-gpo-membership-groups)
- [Refresh Group Policy on the devices in each membership group](#to-refresh-group-policy-on-a-device)
- [Check which GPOs apply to a device](#to-see-which-gpos-are-applied-to-a-device)
## To add test devices to the GPO membership groups
1. Open Active Directory Users and Computers
1. In the navigation pane, expand **Active Directory Users and Computers**, expand *YourDomainName*, and then expand the container that holds your membership group account
1. In the details pane, double-click the GPO membership group to which you want to add devices
1. Select the **Members** tab, and then click **Add**
1. Type the name of the device in the text box, and then click **OK**
1. Repeat steps 5 and 6 for each extra device account or group that you want to add
1. Click **OK** to close the group properties dialog box
After a device is a member of the group, you can force a Group Policy refresh on the device.
## To refresh Group Policy on a device
From an elevated command prompt, run the following command:
``` cmd
gpupdate /target:device /force
```
After Group Policy is refreshed, you can see which GPOs are currently applied to the device.
## To see which GPOs are applied to a device
From an elevated command prompt, run the following command:
``` cmd
gpresult /r /scope:computer
```

View File

@ -1,49 +0,0 @@
---
title: Assign Security Group Filters to the GPO
description: Learn how to use Group Policy Management MMC to assign security group filters to a GPO to make sure that the GPO is applied to the correct computers.
ms.prod: windows-client
ms.topic: how-to
ms.date: 11/10/2023
---
# Assign Security Group Filters to the GPO
To make sure that your GPO is applied to the correct computers, use the Group Policy Management MMC snap-in to assign security group filters to the GPO.
>[!IMPORTANT]
>This deployment guide uses the method of adding the Domain Computers group to the membership group for the main isolated domain after testing is complete and you are ready to go live in production. To make this method work, you must prevent any computer that is a member of either the boundary or encryption zone from applying the GPO for the main isolated domain. For example, on the GPOs for the main isolated domain, deny Read and Apply Group Policy permissions to the membership groups for the boundary and encryption zones.
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the relevant GPOs.
In this topic:
- [Allow members of a group to apply a GPO](#to-allow-members-of-a-group-to-apply-a-gpo)
- [Prevent members of a group from applying a GPO](#to-prevent-members-of-a-group-from-applying-a-gpo)
## To allow members of a group to apply a GPO
Use the following procedure to add a group to the security filter on the GPO that allows group members to apply the GPO.
1. Open the Group Policy Management console
1. In the navigation pane, find and then select the GPO that you want to modify
1. In the details pane, under **Security Filtering**, select **Authenticated Users**, and then select **Remove**
>[!NOTE]
>You must remove the default permission granted to all authenticated users and computers to restrict the GPO to only the groups you specify.
1. Select **Add**
1. In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to apply the GPO, and then select **OK**. If you do not know the name, you can select **Advanced** to browse the list of groups available in the domain
## To prevent members of a group from applying a GPO
Use the following procedure to add a group to the security filter on the GPO that prevents group members from applying the GPO. This is typically used to prevent members of the boundary and encryption zones from applying the GPOs for the isolated domain.
1. Open the Group Policy Management console
1. In the navigation pane, find and then select the GPO that you want to modify
1. In the details pane, select the **Delegation** tab
1. Select **Advanced**
1. Under the **Group or user names** list, select **Add**
1. In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to be prevented from applying the GPO, and then select **OK**. If you do not know the name, you can select **Advanced** to browse the list of groups available in the domain
1. Select the group in the **Group or user names** list, and then select the box in the **Deny** column for both **Read** and **Apply group policy**
1. Select **OK**, and then in the **Windows Security** dialog box, select **Yes**
1. The group appears in the list with **Custom** permissions

View File

@ -1,42 +0,0 @@
---
title: Change Rules from Request to Require Mode
description: Learn how to convert a rule from request to require mode and apply the modified GPOs to the client devices.
ms.prod: windows-client
ms.topic: how-to
ms.date: 11/10/2023
---
# Change Rules from Request to Require Mode
After you confirm that network traffic is being correctly protected by using IPsec, you can change the rules for the domain isolation and encryption zones to require, instead of request, authentication. Don't change the rules for the boundary zone; they must stay in request mode so that devices in the boundary zone can continue to accept connections from devices that aren't part of the isolated domain.
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
In this topic:
- [Convert a rule from request to require mode](#to-convert-a-rule-from-request-to-require-mode)
- [Apply the modified GPOs to the client devices](#to-apply-the-modified-gpos-to-the-client-devices)
## To convert a rule from request to require mode
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md)
1. In the right navigation pane, click **Connection Security Rules**
1. In the details pane, double-click the connection security rule that you want to modify
1. Click the **Authentication** tab
1. In the **Requirements** section, change **Authenticated mode** to **Require inbound and request outbound**, and then click **OK**
## To apply the modified GPOs to the client devices
1. The next time each device refreshes its Group Policy, it will receive the updated GPO and apply the modified rule. To force an immediate refresh, run the following command from an elevated command prompt:
``` cmd
gpupdate.exe /force
```
1. To verify that the modified GPO is correctly applied to the client devices, you can run the following command:
``` cmd
gpresult.exe /r /scope computer
```
1. Examine the command output for the list of GPOs that are applied to the device, and make sure that the list contains the GPOs you expect to see on that device.

View File

@ -1,58 +0,0 @@
---
title: Configure Authentication Methods
description: Learn how to configure authentication methods for devices in an isolated domain or standalone server zone in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Configure Authentication Methods
This procedure shows you how to configure the authentication methods that can be used by computers in an isolated domain or standalone isolated server zone.
>**Note:**  If you follow the steps in the procedure in this topic, you alter the system-wide default settings. Any connection security rule can use these settings by specifying **Default** on the **Authentication** tab.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
**To configure authentication methods**
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the details pane on the main Windows Defender Firewall with Advanced Security page, click **Windows Defender Firewall Properties**.
3. On the **IPsec Settings** tab, click **Customize**.
4. In the **Authentication Method** section, select the type of authentication that you want to use from among the following:
1. **Default**. Selecting this option tells the computer to use the authentication method currently defined by the local administrator in Windows Defender Firewall or by Group Policy as the default.
2. **Computer certificate from this certification authority**. Selecting this option and entering the identification of a certification authority (CA) tells the computer to use and require authentication by using a certificate that is issued by the selected CA. If you also select **Accept only health certificates**, then only certificates that include the system health authentication extended key usage (EKU) typically provided in a Network Access Protection (NAP) infrastructure can be used for this rule.
3. **Advanced**. Click **Customize** to specify a custom combination of authentication methods required for your scenario. You can specify both a **First authentication method** and a **Second authentication method**.
The first authentication method can be one of the following methods:
- **Computer (NTLMv2)**. Selecting this option tells the computer to use and require authentication of the computer by using its domain credentials. This option works only with other computers that can use AuthIP. User-based authentication using Kerberos V5 isn't supported by IKE v1.
- **Computer certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the computer to use and require authentication by using a certificate that is issued by that CA. If you also select **Accept only health certificates**, then only certificates issued by a NAP server can be used.
- **Preshared key (not recommended)**. Selecting this method and entering a preshared key tells the computer to authenticate by exchanging the preshared keys. If they match, then the authentication succeeds. This method isn't recommended, and is included only for backward compatibility and testing purposes.
If you select **First authentication is optional**, then the connection can succeed even if the authentication attempt specified in this column fails.
The second authentication method can be one of the following methods:
- **User (NTLMv2)**. Selecting this option tells the computer to use and require authentication of the currently signed-in user by using their domain credentials, and uses the NTLMv2 protocol instead of Kerberos V5. This authentication method works only with other computers that can use AuthIP. User-based authentication using Kerberos V5 isn't supported by IKE v1.
- **User health certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the computer to use and require user-based authentication by using a certificate that is issued by the specified CA. If you also select **Enable certificate to account mapping**, then the certificate can be associated with a user in Active Directory for purposes of granting or denying access to specified users or user groups.
- **Computer health certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the computer to use and require authentication by using a certificate that is issued by the specified CA. If you also select **Accept only health certificates**, then only certificates that include the system health authentication EKU typically provided in a NAP infrastructure can be used for this rule.
If you select **Second authentication is optional**, then the connection can succeed even if the authentication attempt specified in this column fails.
>**Important:** Make sure that you do not select the check boxes to make both first and second authentication optional. Doing so allows plaintext connections whenever authentication fails.
5. Click **OK** on each dialog box to save your changes and return to the Group Policy Management Editor.

View File

@ -1,56 +0,0 @@
---
title: Configure Data Protection (Quick Mode) Settings
description: Learn how to configure the data protection settings for connection security rules in an isolated domain or a standalone isolated server zone.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Configure Data Protection (Quick Mode) Settings
This procedure shows you how to configure the data protection (quick mode) settings for connection security rules in an isolated domain or a standalone isolated server zone.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
**To configure quick mode settings**
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the details pane on the main Windows Defender Firewall with Advanced Security page, click **Windows Defender Firewall Properties**.
3. On the **IPsec Settings** tab, click **Customize**.
4. In the **Data protection (Quick Mode)** section, click **Advanced**, and then click **Customize**.
5. If you require encryption for all network traffic in the specified zone, then check **Require encryption for all connection security rules that use these settings**. Selecting this option disables the **Data integrity** section, and forces you to select only integrity algorithms that are combined with an encryption algorithm. If you do not select this option, then you can use only data integrity algorithms. Before selecting this option, consider the performance impact and the increase in network traffic that will result. We recommend that you use this setting only on network traffic that truly requires it, such as to and from computers in the encryption zone.
6. If you did not select **Require encryption**, then select the data integrity algorithms that you want to use to help protect the data sessions between the two computers. If the data integrity algorithms displayed in the list are not what you want, then do the following:
1. From the left column, remove any of the data integrity algorithms that you do not want by selecting the algorithm and then clicking **Remove**.
2. Add any required data integrity algorithms by clicking **Add**, selecting the appropriate protocol (ESP or AH) and algorithm (SHA1 or MD5), selecting the key lifetime in minutes or sessions, and then clicking **OK**. We recommend that you do not include MD5 in any combination. It is included for backward compatibility only. We also recommend that you use ESP instead of AH if you have any devices on your network that use network address translation (NAT).
3. In **Key lifetime (in sessions)**, type the number of times that the quick mode session can be rekeyed. After this number is reached, the quick mode SA must be renegotiated. Be careful to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance because of the more frequent renegotiating of the quick mode SA. We recommend that you use the default value unless your risk analysis indicates the need for a different value.
4. Click **OK** to save your algorithm combination settings.
5. After the list contains only the combinations you want, use the up and down arrows to the right of the list to rearrange them in the correct order for your design. The algorithm combination that is first in the list is tried first, and so on.
7. Select the data integrity and encryption algorithms that you want to use to help protect the data sessions between the two computers. If the algorithm combinations displayed in the list are not what you want, then do the following:
1. From the second column, remove any of the data integrity and encryption algorithms that you do not want by selecting the algorithm combination and then clicking **Remove**.
2. Add any required integrity and encryption algorithm combinations by clicking **Add**, and then doing the following:
3. Select the appropriate protocol (ESP or AH). We recommend that you use ESP instead of AH if you have any devices on your network that use NAT.
4. Select the appropriate encryption algorithm. The choices include, in order of decreasing security: AES-256, AES-192, AES-128, 3DES, and DES. We recommend that you do not include DES in any combination. It is included for backward compatibility only.
5. Select the appropriate integrity algorithm (SHA1 or MD5). We recommend that you do not include MD5 in any combination. It is included for backward compatibility only.
6. In **Key lifetime (in minutes)**, type the number of minutes. When the specified number of minutes has elapsed, any IPsec operations between the two computers that negotiated this key will require a new key. Be careful to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance because of the more frequent rekeying. We recommend that you use the default value unless your risk analysis indicates the need for a different value.
8. Click **OK** three times to save your settings.

View File

@ -1,32 +0,0 @@
---
title: Configure Group Policy to Autoenroll and Deploy Certificates
description: Learn how to configure Group Policy to automatically enroll client computer certificates and deploy them to the workstations on your network.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Configure Group Policy to Autoenroll and Deploy Certificates
You can use this procedure to configure Group Policy to automatically enroll client computer certificates and deploy them to the workstations on your network. Follow this procedure for each GPO that contains IPsec connection security rules that require this certificate.
**Administrative credentials**
To complete these procedures, you must be a member of both the Domain Admins group in the root domain of your forest and a member of the Enterprise Admins group.
**To configure Group Policy to autoenroll certificates**
1. Open the Group Policy Management console.
2. In the navigation pane, expand **Forest:** *YourForestName*, expand **Domains**, expand *YourDomainName*, expand **Group Policy Objects**, right-click the GPO you want to modify, and then click **Edit**.
3. In the navigation pane, expand the following path: **Computer Configuration**, **Policies**, **Windows Settings**, **Security Settings**, **Public Key Policies**.
4. Double-click **Certificate Services Client - Auto-Enrollment**.
5. In the **Properties** dialog box, change **Configuration Model** to **Enabled**.
6. Select both **Renew expired certificates, update pending certificates, and remove revoked certificates** and **Update certificates that use certificate templates**.
7. Click **OK** to save your changes. Computers apply the GPO and download the certificate the next time Group Policy is refreshed.

View File

@ -1,56 +0,0 @@
---
title: Configure Key Exchange (Main Mode) Settings
description: Learn how to configure the main mode key exchange settings used to secure the IPsec authentication traffic in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Configure Key Exchange (Main Mode) Settings
This procedure shows you how to configure the main mode key exchange settings used to secure the IPsec authentication traffic.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
**To configure key exchange settings**
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the details pane on the main Windows Defender Firewall with Advanced Security page, click **Windows Defender Firewall Properties**.
3. On the **IPsec Settings** tab, click **Customize**.
4. In the **Key exchange (Main Mode)** section, click **Advanced**, and then click **Customize**.
5. Select the security methods to be used to help protect the main mode negotiations between the two devices. If the security methods displayed in the list aren't what you want, then do the following steps:
**Important**  
In Windows Vista, Windows Server 2008, or later, you can specify only one key exchange algorithm. This rule means that if you want to communicate by using IPsec with another device running Windows 8 or Windows Server 2012, then you must select the same key exchange algorithm on both devices.
Also, if you create a connection security rule that specifies an option that requires AuthIP instead of IKE, then only the one combination of the top integrity and encryption security method is used in the negotiation. Ensure that all of your devices that are running at least Windows Vista and Windows Server 2008 have the same methods at the top of the list and the same key exchange algorithm selected.
**Note**  
When AuthIP is used, no Diffie-Hellman key exchange protocol is used. Instead, when Kerberos V5 authentication is requested, the Kerberos V5 service ticket secret is used in place of a Diffie-Hellman value. When either certificate authentication or NTLM authentication is requested, a transport level security (TLS) session is established, and its secret is used in place of the Diffie-Hellman value. This event happens no matter which Diffie-Hellman key exchange protocol you select.
1. Remove any of the security methods that you don't want by selecting the method and then clicking **Remove**.
2. Add any required security method combinations by clicking **Add**, selecting the appropriate encryption algorithm and integrity algorithm from the lists, and then clicking **OK**.
>**Caution:**  We recommend that you do not include MD5 or DES in any combination. They are included for backward compatibility only.
3. After the list contains only the combinations you want, use the "up" and "down" arrows to the right of the list to arrange them in the order of preference. The combination that appears first in the list is tried first, and so on.
6. From the list on the right, select the key exchange algorithm that you want to use.
>**Caution:**  We recommend that you do not use Diffie-Hellman Group 1. It is included for backward compatibility only. 
7. In **Key lifetime (in minutes)**, type the number of minutes. When the specified number of minutes has elapsed, any IPsec operation between the two devices requires a new key.
>**Note:**  You need to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance.
8. In **Key lifetime (in sessions)**, type the number of sessions. After the specified number of quick mode sessions have been created within the security association protected by this key, IPsec requires a new key.
9. Click **OK** three times to save your settings.

View File

@ -1,50 +0,0 @@
---
title: Configure the Rules to Require Encryption
description: Learn how to configure rules to add encryption algorithms and delete the algorithm combinations that don't use encryption for zones that require encryption.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Configure the Rules to Require Encryption
If you're creating a zone that requires encryption, you must configure the rules to add the encryption algorithms and delete the algorithm combinations that don't use encryption.
**Administrative credentials**
To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
**To modify an authentication request rule to also require encryption**
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Connection Security Rules**.
3. In the details pane, double-click the connection security rule you want to modify.
4. On the **Name** page, rename the connection security rule, edit the description to reflect the new use for the rule, and then click **OK**.
5. In the navigation pane, right-click **Windows Defender Firewall LDAP://CN={**<em>guid</em>**}**, and then click **Properties**.
6. Click the **IPsec Settings** tab.
7. Under **IPsec defaults**, click **Customize**.
8. Under **Data protection (Quick Mode)**, click **Advanced**, and then click **Customize**.
9. Click **Require encryption for all connection security rules that use these settings**.
This setting disables the data integrity rules section. Ensure the **Data integrity and encryption** list contains all of the combinations that your client devices will use to connect to members of the encryption zone. The client devices receive their rules through the GPO for the zone to which they reside. You must make sure that those rules contain at least one of the data integrity and encryption algorithms that are configured in this rule, or the client devices in that zone won't be able to connect to devices in this zone.
10. If you need to add an algorithm combination, click **Add** and then select the combination of encryption and integrity algorithms. The options are described in [Configure Data Protection (Quick Mode) Settings](configure-data-protection-quick-mode-settings.md).
**Note**  
Not all of the algorithms available in Windows 8 or Windows Server 2012 and later can be selected in the Windows Defender Firewall with Advanced Security user interface. To select them, you can use Windows PowerShell.
Quick mode settings can also be configured on a per-rule basis, but not by using the Windows Defender Firewall user interface. Instead, you can create or modify the rules by using Windows PowerShell.
For more info, see [Windows Defender Firewall with Advanced Security Administration with Windows PowerShell](windows-firewall-with-advanced-security-administration-with-windows-powershell.md)
11. During negotiation, algorithm combinations are proposed in the order shown in the list. Ensure that the more secure combinations are at the top of the list so that the negotiating devices select the most secure combination that they can jointly support.
12. Click **OK** three times to save your changes.

View File

@ -1,42 +0,0 @@
---
title: Configure the Workstation Authentication Template
description: Learn how to configure a workstation authentication certificate template, which is used for device certificates that are enrolled and deployed to workstations.
ms.prod: windows-client
ms.date: 09/07/2021
ms.topic: conceptual
---
# Configure the Workstation Authentication Certificate Template
This procedure describes how to configure a certificate template that Active Directory Certification Services (AD CS) uses as the starting point for device certificates that are automatically enrolled and deployed to workstations in the domain. It shows how to create a copy of a template, and then configure the template according to your design requirements.
**Administrative credentials**
## To configure the workstation authentication certificate template and autoenrollment
To complete these procedures, you must be a member of both the Domain Admins group in the root domain of your forest, and a member of the Enterprise Admins group.
1. On the device where AD CS is installed, open the Certification Authority console.
2. In the navigation pane, right-click **Certificate Templates**, and then click **Manage**.
3. In the details pane, click the **Workstation Authentication** template.
4. On the **Action** menu, click **Duplicate Template**. In the **Duplicate Template** dialog box, select the template version that is appropriate for your deployment, and then click **OK**. For the resulting certificates to have maximum compatibility with the available versions of Windows, we recommended that you select **Windows Server 2003**.
5. On the **General** tab, in **Template display name**, type a new name for the certificate template, such as **Domain Isolation Workstation Authentication Template**.
6. Click the **Subject Name** tab. Make sure that **Build from this Active Directory information** is selected. In **Subject name format**, select **Fully distinguished name**.
7. Click the **Cryptography** tab. You must determine the best minimum key size for your environment. Large key sizes provide better security, but they can affect server performance. We recommended that you use the default setting of 2048.
8. Click the **Security** tab. In **Group or user names**, click **Domain Computers**, under **Allow**, select **Enroll** and **Autoenroll**, and then click **OK**.
>**Note:**  If you want do not want to deploy the certificate to every device in the domain, then specify a different group or groups that contain the device accounts that you want to receive the certificate.
9. Close the Certificate Templates Console.
10. In the Certification Authority MMC snap-in, in the left pane, right-click **Certificate Templates**, click **New**, and then click **Certificate Template to Issue**.
11. In the **Enable Certificate Templates** dialog box, click the name of the certificate template you configured, and then click **OK**.

View File

@ -1,40 +0,0 @@
---
title: Configure Windows Defender Firewall with Advanced Security to Suppress Notifications When a Program is Blocked
description: Configure Windows Defender Firewall with Advanced Security to suppress notifications when a program is Blocked
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Configure Windows Defender Firewall with Advanced Security to Suppress Notifications When a Program Is Blocked
To configure Windows Defender Firewall with Advanced Security to suppress the display of a notification when it blocks a program that tries to listen for network traffic and to prohibit locally defined rules, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console.
>**Caution:**  If you choose to disable alerts and prohibit locally defined rules, then you must create firewall rules that allow your users programs to send and receive the required network traffic. If a firewall rule is missing, then the user does not receive any kind of warning, the network traffic is silently blocked, and the program might fail.
We recommend that you don't enable these settings until you've created and tested the required rules.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
## To configure Windows Defender Firewall to suppress the display of a notification for a blocked program and to ignore locally defined rules
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the details pane, in the **Overview** section, click **Windows Defender Firewall Properties**.
3. For each network location type (Domain, Private, Public), perform the following steps.
1. Click the tab that corresponds to the network location type.
2. Under **Settings**, click **Customize**.
3. Under **Firewall settings**, change **Display a notification** to **No**.
4. Under **Rule merging**, change **Apply local firewall rules** to **No**.
5. Although a connection security rule isn't a firewall setting, you can also use this tab to prohibit locally defined connection security rules if you're planning to deploy IPsec rules as part of a server or domain isolation environment. Under **Rule merging**, change **Apply local connection security rules** to **No**.
6. Click **OK** twice.

View File

@ -1,39 +0,0 @@
---
title: Confirm That Certificates Are Deployed Correctly
description: Learn how to confirm that a Group Policy is being applied as expected and that the certificates are being properly installed on the workstations.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 01/24/2023
---
# Confirm That Certificates Are Deployed Correctly
After configuring your certificates and autoenrollment in Group Policy, you can confirm that the policy is being applied as expected, and that the certificates are being properly installed on the workstation devices.
In these procedures, you refresh Group Policy on a client device, and then confirm that the certificate is deployed correctly.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
In this topic:
- [Refresh Group Policy on a device](#to-refresh-group-policy-on-a-device)
- [Verify that a certificate is installed](#to-verify-that-a-certificate-is-installed)
## To refresh Group Policy on a device
From an elevated command prompt, run the following command:
``` cmd
gpupdate /target:computer /force
```
After Group Policy is refreshed, you can see which GPOs are currently applied to the device.
## To verify that a certificate is installed
1. Open the Certificates console
1. In the navigation pane, expand **Trusted Root Certification Authorities**, and then click **Certificates**
The CA that you created appears in the list.

View File

@ -1,46 +0,0 @@
---
title: Copy a GPO to Create a New GPO
description: Learn how to make a copy of a GPO by using the Active Directory Users and devices MMC snap-in to create a GPO for boundary zone devices.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Copy a GPO to Create a New GPO
To create the GPO for the boundary zone devices, make a copy of the main domain isolation GPO, and then change the settings to request, instead of require, authentication. To make a copy of a GPO, use the Active Directory Users and devices MMC snap-in.
**Administrative credentials**
To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new GPOs.
**To make a copy of a GPO**
1. Open the Group Policy Management console.
2. In the navigation pane, expand **Forest:**<em>YourForestName</em>, expand **Domains**, expand *YourDomainName*, and then click **Group Policy Objects**.
3. In the details pane, right-click the GPO you want to copy, and then click **Copy**.
4. In the navigation pane, right-click **Group Policy Objects** again, and then click **Paste**.
:::image type="content" alt-text="Screenshot that shows Copy Paste GPO." source="images/grouppolicy-paste.png":::
5. In the **Copy GPO** dialog box, click **Preserve the existing permissions**, and then click **OK**. Selecting this option preserves any exception groups to which you denied Read and Apply GPO permissions, making the change simpler.
6. After the copy is complete, click **OK**. The new GPO is named **Copy of** *original GPO name*.
7. To rename it, right-click the GPO, and then click **Rename**.
8. Type the new name, and then press ENTER.
9. You must change the security filters to apply the policy to the correct group of devices. To change the security filters, click the **Scope** tab, and in the **Security Filtering** section, select the group that grants permissions to all members of the isolated domain, for example **CG\_DOMISO\_IsolatedDomain**, and then click **Remove**.
10. In the confirmation dialog box, click **OK**.
11. Click **Add**.
12. Type the name of the group that contains members of the boundary zone, for example **CG\_DOMISO\_Boundary**, and then click **OK**.
13. If necessary, change the WMI filter to one appropriate for the new GPO. For example, if the original GPO is for client devices running Windows 10 or Windows 11, and the new boundary zone GPO is for devices running Windows Server 2016, then select a WMI filter that allows only those devices to read and apply the GPO.

View File

@ -1,36 +0,0 @@
---
title: Create a Group Account in Active Directory
description: Learn how to create a security group for the computers that are to receive Group Policy settings by using the Active Directory Users and Computers console.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create a Group Account in Active Directory
To create a security group to contain the computer accounts for the computers that are to receive a set of Group Policy settings, use the Active Directory Users and Computers console.
**Administrative credentials**
To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new group accounts.
**To add a new membership group in Active Directory**
1. Open the Active Directory Users and Computers console.
2. In the navigation pane, select the container in which you want to store your group. This is typically the **Users** container under the domain.
3. Click **Action**, click **New**, and then click **Group**.
4. In the **Group name** text box, type the name for your new group.
>**Note:**  Be sure to use a name that clearly indicates its purpose. Check to see if your organization has a naming convention for groups.
5. In the **Description** text box, enter a description of the purpose of this group.
6. In the **Group scope** section, select either **Global** or **Universal**, depending on your Active Directory forest structure. If your group must include computers from multiple domains, then select **Universal**. If all of the members are from the same domain, then select **Global**.
7. In the **Group type** section, click **Security**.
8. Click **OK** to save your group.

View File

@ -1,43 +0,0 @@
---
title: Create a Group Policy Object
description: Learn how to use the Active Directory Users and Computers MMC snap-in to create a GPO. You must be a member of the Domain Administrators group.
ms.prod: windows-client
ms.collection:
- highpri
- tier3
- must-keep
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create a Group Policy Object
To create a new GPO, use the Active Directory Users and Computers MMC snap-in.
**Administrative credentials**
To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new GPOs.
To create a new GPO
1. Open the Group Policy Management console.
2. In the navigation pane, expand **Forest:**<em>YourForestName</em>, expand **Domains**, expand *YourDomainName*, and then click **Group Policy Objects**.
3. Click **Action**, and then click **New**.
4. In the **Name** text box, type the name for your new GPO.
> [!NOTE]
> Be sure to use a name that clearly indicates the purpose of the GPO. Check to see if your organization has a naming convention for GPOs.
5. Leave **Source Starter GPO** set to **(none)**, and then click **OK**.
6. If your GPO will not contain any user settings, then you can improve performance by disabling the **User Configuration** section of the GPO. To do this, perform these steps:
1. In the navigation pane, click the new GPO.
2. In the details pane, click the **Details** tab.
3. Change the **GPO Status** to **User configuration settings disabled**.

View File

@ -1,56 +0,0 @@
---
title: Create an Authentication Exemption List Rule
description: Learn how to create rules that exempt devices that cannot communicate by using IPSec from the authentication requirements of your isolation policies.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Authentication Exemption List Rule
In almost any isolated server or isolated domain scenario, there are some devices or devices that cannot communicate by using IPsec. This procedure shows you how to create rules that exempt those devices from the authentication requirements of your isolation policies.
**Important**  
Adding devices to the exemption list for a zone reduces security because it permits devices in the zone to send network traffic that is unprotected by IPsec to the devices on the list. As discussed in the Windows Defender Firewall with Advanced Security Design Guide, you must add only managed and trusted devices to the exemption list.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
**To create a rule that exempts specified hosts from authentication**
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Connection Security Rules**.
3. Click **Action**, and then click **New Rule**.
4. On the **Rule Type** page of the New Connection Security Rule Wizard, click **Authentication exemption**, and then click **Next**.
5. On the **Exempt Computers** page, to create a new exemption, click **Add**. To modify an existing exemption, click it, and then click **Edit**.
6. In the **IP Address** dialog box, do one of the following:
- To add a single IP address, click **This IP address or subnet**, type the IP address of the host in the text box, and then click **OK**.
- To add an entire subnet by address, click **This IP address or subnet**, and then type the IP address of the subnet, followed by a forward slash (/) and the number of bits in the corresponding subnet mask. For example, **10.50.0.0/16** represents the class B subnet that begins with address 10.50.0.1, and ends with address **10.50.255.254**. Click **OK** when you are finished.
- To add the local devices subnet, click **Predefined set of computers**, select **Local subnet** from the list, and then click **OK**.
>**Note:**  If you select the local subnet from the list rather than typing the subnet address in manually, the device automatically adjusts the active local subnet to match the devices current IP address.
- To add a discrete range of addresses that do not correspond to a subnet, click **This IP address range**, type the beginning and ending IP addresses in the **From** and **To** text boxes, and then click **OK**.
- To exempt all of the remote hosts that the local device uses for a specified network service, click **Predefined set of computers**, select the network service from the list, and then click **OK**.
7. Repeat steps 5 and 6 for each exemption that you need to create.
8. Click **Next** when you have created all of the exemptions.
9. On the **Profile** page, check the profile for each network location type to which this set of exemptions applies, and then click **Next**.
>**Caution:**  If all of the exemptions are on the organizations network and that network is managed by an Active Directory domain, then consider restricting the rule to the Domain profile only. Selecting the wrong profile can reduce the protection for your computer because any computer with an IP address that matches an exemption rule will not be required to authenticate.
10. On the **Name** page, type the name of the exemption rule, type a description, and then click **Finish**.

View File

@ -1,78 +0,0 @@
---
title: Create an Authentication Request Rule
description: Create a new rule for Windows Defender Firewall with Advanced Security so devices on the network use IPsec protocols and methods before they can communicate.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Authentication Request Rule
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and above
After you have configured IPsec algorithms and authentication methods, you can create the rule that requires the devices on the network to use those protocols and methods before they can communicate.
**Administrative credentials**
To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the (Group Policy Objects) GPOs.
To create the authentication request rule:
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, right-click **Connection Security Rules**, and then click **New Rule**.
3. On the **Rule Type** page, select **Isolation**, and then click **Next**.
4. On the **Requirements** page, select **Request authentication for inbound and outbound connections**.
> [!CAUTION]
> Do not configure the rule to require inbound authentication until you have confirmed that all of your devices are receiving the correct GPOs, and are successfully negotiating IPsec and authenticating with each other. Allowing the devices to communicate even when authentication fails prevents any errors in the GPOs or their distribution from breaking communications on your network.
5. On the **Authentication Method** page, select the authentication option you want to use on your network. To select multiple methods that are attempted in order until one succeeds, click **Advanced**, click **Customize**, and then click **Add** to add methods to the list. Second authentication methods require Authenticated IP (AuthIP).
1. **Default**. Selecting this option tells the device to request authentication by using the method currently defined as the default on the device. This default might have been configured when the operating system was installed or it might have been configured by Group Policy. Selecting this option is appropriate when you have configured system-wide settings by using the [Configure Authentication Methods](configure-authentication-methods.md) procedure.
2. **Advanced**. Selecting this option enables you to specify a custom combination of authentication methods required for your scenario.
6. Optional: If you selected **Advanced** in the previous step, then Click **Customize** to specify a custom combination of authentication methods required for your scenario. You can specify both a **First authentication method** and a **Second authentication method**.
The **First authentication method** can be one of the following:
- **Computer (NTLMv2)**. Selecting this option tells the device to use and require authentication of the device by using its domain credentials. This option works only with other devices that can use AuthIP. User-based authentication using Kerberos V5 is not supported by IKE v1.
- **Computer certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the device to request authentication by using a certificate that is issued by the specified CA. If you also select **Accept only health certificates**, then only certificates issued by a NAP server can be used for this rule.
- **Preshared key (not recommended)**. Selecting this method and entering a pre-shared key tells the device to authenticate by exchanging the pre-shared keys. If the keys match, then the authentication succeeds. This method is not recommended, and is included for backward compatibility and testing purposes only.
If you select **First authentication is optional**, then the connection can succeed even if the authentication attempt specified in this column fails.
The **Second authentication method** can be one of the following:
- **User (NTLMv2)**. Selecting this option tells the device to use and require authentication of the currently logged-on user by using his or her domain credentials, and uses the NTLMv2 protocol instead of Kerberos V5. This authentication method works only with other devices that can use AuthIP. User-based authentication using NTLMv2 is not supported by IKE v1.
- **User health certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the device to request user-based authentication by using a certificate that is issued by the specified CA. If you also select **Enable certificate to account mapping**, then the certificate can be associated with a user in Active Directory for purposes of granting or denying access to certain users or user groups.
- **Computer health certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the device to use and require authentication by using a certificate that is issued by the specified CA. If you also select **Accept only health certificates**, then only certificates issued by a NAP server can be used for this rule.
If you check **Second authentication is optional**, the connection can succeed even if the authentication attempt specified in this column fails.
> [!IMPORTANT]
> Make sure that you do not select the boxes to make both first and second authentication optional. Doing so allows plaintext connections whenever authentication fails.
7. After you have configured the authentication methods, click **OK** on each dialog box to save your changes and close it, until you return to the **Authentication Method** page in the wizard. Click **Next**.
8. On the **Profile** page, select the check boxes for the network location type profiles to which this rule applies.
- On portable devices, consider clearing the **Private** and **Public** boxes to enable the device to communicate without authentication when it is away from the domain network.
- On devices that do not move from network to network, consider selecting all the profiles. Doing so prevents an unexpected switch in the network location type from disabling the rule.
Click **Next**.
9. On the **Name** page, type a name for the connection security rule and a description, and then click **Finish**.
The new rule appears in the list of connection security rules.

View File

@ -1,99 +0,0 @@
---
title: Create WMI Filters for the GPO
description: Learn how to use WMI filters on a GPO to make sure that each GPO for a group can only be applied to devices running the correct version of Windows.
ms.prod: windows-client
ms.collection:
- highpri
- tier3
- must-keep
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create WMI Filters for the GPO
To make sure that each GPO associated with a group can only be applied to devices running the correct version of Windows, use the Group Policy Management MMC snap-in to create and assign WMI filters to the GPO. Although you can create a separate membership group for each GPO, you would then have to manage the memberships of the different groups. Instead, use only a single membership group, and let WMI filters automatically ensure the correct GPO is applied to each device.
- [Create WMI Filters for the GPO](#create-wmi-filters-for-the-gpo)
- [To create a WMI filter that queries for a specified version of Windows](#to-create-a-wmi-filter-that-queries-for-a-specified-version-of-windows)
- [To link a WMI filter to a GPO](#to-link-a-wmi-filter-to-a-gpo)
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
First, create the WMI filter and configure it to look for a specified version (or versions) of the Windows operating system.
## To create a WMI filter that queries for a specified version of Windows
1. Open the Group Policy Management console.
2. In the navigation pane, expand **Forest:** *YourForestName*, expand **Domains**, expand *YourDomainName*, and then select **WMI Filters**.
3. Select **Action**, and then select **New**.
4. In the **Name** text box, type the name of the WMI filter. Be sure to use a name that clearly indicates the purpose of the filter. Check to see if your organization has a naming convention.
5. In the **Description** text box, type a description for the WMI filter. For example, if the filter excludes domain controllers, you might consider stating that in the description.
6. Select **Add**.
7. Leave the **Namespace** value set to **root\\CIMv2**.
8. In the **Query** text box, type:
``` syntax
select * from Win32_OperatingSystem where Version like "6.%"
```
This query will return **true** for devices running at least Windows Vista and Windows Server 2008. To set a filter for just Windows 8 and Windows Server 2012, use "6.2%". For Windows 11, Windows 10, and Windows Server 2016, use "10.%". To specify multiple versions, combine them with or, as shown in the following:
``` syntax
... where Version like "6.1%" or Version like "6.2%"
```
To restrict the query to only clients or only servers, add a clause that includes the ProductType parameter. To filter for client operating systems only, such as Windows 8 or Windows 7, use only ProductType="1". For server operating systems that are not domain controllers and for Windows 10 and Windows 11 multi-session, use ProductType="3". For domain controllers only, use ProductType="2". This is a useful distinction, because you often want to prevent your GPOs from being applied to the domain controllers on your network.
The following clause returns **true** for all devices that are not domain controllers:
``` syntax
... where ProductType="1" or ProductType="3"
```
The following complete query returns **true** for all devices running Windows 10 and Windows 11, and returns **false** for any server operating system or any other client operating system.
``` syntax
select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"
```
Specific versions of Windows 10 can be targeted by including the *major build version* in the query. The following query returns **true** for all devices running Windows 10 20H2 (which has a *major build version* of `19042`), and returns **false** for any server operating system or any other client operating system. Additional information about Windows 10 build versions can be found at [Windows 10 release information](/windows/release-health/release-information).
```syntax
select * from Win32_OperatingSystem where Version like "10.0.19042" and ProductType="1"
```
The following query returns **true** for any device running Windows Server 2016, except domain controllers:
``` syntax
select * from Win32_OperatingSystem where Version like "10.%" and ProductType="3"
```
9. Select **OK** to save the query to the filter.
10. Select **Save** to save your completed filter.
> [!NOTE]
> If you're using multiple queries in the same WMI filter, these queries must all return **TRUE** for the filter requirements to be met and for the GPO to be applied.
## To link a WMI filter to a GPO
After you have created a filter with the correct query, link the filter to the GPO. Filters can be reused with many GPOs simultaneously; you do not have to create a new one for each GPO if an existing one meets your needs.
1. Open the Group Policy Management console.
2. In the navigation pane, find and then select the GPO that you want to modify.
3. Under **WMI Filtering**, select the correct WMI filter from the list.
4. Select **Yes** to accept the filter.

View File

@ -1,133 +0,0 @@
---
title: Determining the Trusted State of Your Devices
description: Learn how to define the trusted state of devices in your enterprise to help design your strategy for using Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Determining the Trusted State of Your Devices
After obtaining information about the devices that are currently part of the IT infrastructure, you must determine at what point a device is considered trusted. The term *trusted* can mean different things to different people. Therefore, you must communicate a firm definition for it to all stakeholders in the project. Failure to do this communication can lead to problems with the security of the trusted environment, because the overall security can't exceed the level of security set by the least secure client that achieves trusted status.
>**Note:**  In this context, the term *trust* has nothing to do with an Active Directory trust relationship between domains. The trusted state of your devices just indicates the level of risk that you believe the device brings to the network. Trusted devices bring little risk whereas untrusted devices can potentially bring great risk.
## Trust states
To understand this concept, consider the four basic states that apply to devices in a typical IT infrastructure. These states are (in order of risk, lowest risk first):
- Trusted
- Trustworthy
- Known, untrusted
- Unknown, untrusted
The remainder of this section defines these states and how to determine which devices in your organization belong in each state.
### Trusted state
Classifying a device as trusted means that the device's security risks are managed, but it doesn't imply that it's perfectly secure or invulnerable. The responsibility for this managed state falls to the IT and security administrators, in addition to the users who are responsible for the configuration of the device. A trusted device that is poorly managed will likely become a point of weakness for the network.
When a device is considered trusted, other trusted devices can reasonably assume that the device won't initiate a malicious act. For example, trusted devices can expect that other trusted devices won't run a virus that attacks them, because all trusted devices are required to use mechanisms (such as antivirus software) to mitigate the threat of viruses.
Spend some time defining the goals and technology requirements that your organization considers appropriate as the minimum configuration for a device to obtain trusted status.
A possible list of technology requirements might include:
- **Operating system.** A trusted client device should run at least Windows Vista. A trusted server should run at least Windows Server 2008.
- **Domain membership.** A trusted device will belong to a managed Active Directory domain, which means that the IT department has security management rights and can configure member devices by using Group Policy.
- **Management client.** All trusted devices must run a specific network management client to allow for centralized management and control of security policies, configurations, and software. Configuration Manager is one such management system with an appropriate client.
- **Antivirus software.** All trusted devices will run antivirus software that is configured to check for and automatically update the latest virus signature files daily.
- **File system.** All trusted devices will be configured to use the NTFS file system.
- **BIOS settings.** All trusted portable devices will be configured to use a BIOS-level password that is under the management of the IT support team.
- **Password requirements.** Trusted clients must use strong passwords.
It's important to understand that the trusted state isn't constant; it's a transient state that is subject to changing security standards and compliance with those standards. New threats and new defenses emerge constantly. For this reason, the organization's management systems must continually check the trusted devices to ensure ongoing compliance. Additionally, the management systems must be able to issue updates or configuration changes if they're required to help maintain the trusted status.
A device that continues to meet all these security requirements can be considered trusted. However it's possible that most devices that were identified in the discovery process discussed earlier don't meet these requirements. Therefore, you must identify which devices can be trusted and which ones can't. To help with this process, you use the intermediate *trustworthy* state. The remainder of this section discusses the different states and their implications.
### Trustworthy state
It's useful to identify as soon as possible those devices in your current infrastructure that can achieve a trusted state. A *trustworthy state* can be assigned to indicate that the current device can physically achieve the trusted state with required software and configuration changes.
For each device that is assigned a trustworthy status, make an accompanying configuration note that states what is required to enable the device to achieve trusted status. This information is especially important to both the project design team (to estimate the costs of adding the device to the solution) and the support staff (to enable them to apply the required configuration).
Generally, trustworthy devices fall into one of the following two groups:
- **Configuration required.** The current hardware, operating system, and software enable the device to achieve a trustworthy state. However, more configuration changes are required. For example, if the organization requires a secure file system before a device can be considered trusted, a device that uses a FAT32-formatted hard disk doesn't meet this requirement.
- **Upgrade required.** These devices require upgrades before they can be considered trusted. The following list provides some examples of the type of upgrade these devices might require:
- **Operating system upgrade required.** If the device's current operating system can't support the security needs of the organization, an upgrade would be required before the device could achieve a trusted state.
- **Software required.** A device that is missing a required security application, such as an antivirus scanner or a management client, can't be considered trusted until these applications are installed and active.
- **Hardware upgrade required.** In some cases, a device might require a specific hardware upgrade before it can achieve trusted status. This type of device usually needs an operating system upgrade or another software that forces the required hardware upgrade. For example, security software might require more hard disk space on the device.
- **Device replacement required.** This category is reserved for devices that can't support the security requirements of the solution because their hardware can't support the minimum acceptable configuration. For example, a device that can't run a secure operating system because it has an old processor (such as a 100 megahertz \[MHz\] x86-based device).
Use these groups to assign costs for implementing the solution on the devices that require upgrades.
### Known, untrusted state
During the process of categorizing an organization's devices, you'll identify some devices that can't achieve trusted status for specific well-understood and well-defined reasons. These reasons might include the following types:
- **Financial.** The funding isn't available to upgrade the hardware or software for this device.
- **Political.** The device must remain in an untrusted state because of a political or business situation that doesn't enable it to comply with the stated minimum security requirements of the organization. It's highly recommended that you contact the business owner or independent software vendor (ISV) for the device to discuss the added value of server and domain isolation.
- **Functional.** The device must run a nonsecure operating system or must operate in a nonsecure manner to perform its role. For example, the device might be required to run an older operating system because a specific line of business application will only work on that operating system.
There can be multiple functional reasons for a device to remain in the known untrusted state. The following list includes several examples of functional reasons that can lead to a classification of this state:
- **Devices that run unsupported versions of Windows.** These versions include Windows XP, Windows Millennium Edition, Windows 98, Windows 95, or Windows NT. Devices that run these versions of the Windows operating system can't be classified as trustworthy because these operating systems don't support the required security infrastructure. For example, although Windows NT does support a basic security infrastructure, it doesn't support “deny” ACLs on local resources, any way to ensure the confidentiality and integrity of network communications, smart cards for strong authentication, or centralized management of device configurations (although limited central management of user configurations is supported).
- **Stand-alone devices.** Devices running any version of Windows which are configured as stand-alone devices or as members of a workgroup usually can't achieve a trustworthy state. Although these devices fully support the minimum required basic security infrastructure, the required security management capabilities are unlikely to be available when the device isn't a part of a trusted domain.
- **Devices in an untrusted domain.** A device that is a member of a domain that isn't trusted by an organization's IT department can't be classified as trusted. An untrusted domain is a domain that can't provide the required security capabilities to its members. Although the operating systems of devices that are members of this untrusted domain might fully support the minimum required basic security infrastructure, the required security management capabilities can't be fully guaranteed when devices aren't in a trusted domain.
### Unknown, untrusted state
The unknown, untrusted state should be considered the default state for all devices. Because devices in this state have a configuration that is unknown, you can assign no trust to them. All planning for devices in this state must assume that the device is an unacceptable risk to the organization. Designers of the solution should strive to minimize the impact that the devices in this state can have on their organizations.
## Capturing upgrade costs for current devices
The final step in this part of the process is to record the approximate cost of upgrading the devices to a point that they can participate in the server and domain isolation design. You must make several key decisions during the design phase of the project that require answers to the following questions:
- Does the device meet the minimum hardware requirements necessary for isolation?
- Does the device meet the minimum software requirements necessary for isolation?
- What configuration changes must be made to integrate this device into the isolation solution?
- What is the projected cost or impact of making the proposed changes to enable the device to achieve a trusted state?
By answering these questions, you can quickly determine the level of effort and approximate cost of bringing a particular device or group of devices into the scope of the project. It's important to remember that the state of a device is transitive, and that by performing the listed remedial actions you can change the state of a device from untrusted to trusted. After you decide whether to place a device in a trusted state, you're ready to begin planning and designing the isolation groups, which the next section [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) discusses.
The following table is an example of a data sheet that you could use to help capture the current state of a device and what would be required for the device to achieve a trusted state.
| Device name | Hardware reqs met | Software reqs met | Configuration required | Details | Projected cost |
| - | - | - | - | - | - |
| CLIENT001 | No| No| Upgrade hardware and software.| Current operating system is Windows XP. Old hardware isn't compatible with newer versions of Windows.| $??|
| SERVER001 | Yes| No| Join trusted domain and upgrade from Windows Server 2003 to Windows Server 2012.| No antivirus software present.| $??|
In the previous table, the device CLIENT001 is currently "known, untrusted" because its hardware must be upgraded. However, it could be considered trustworthy if the required upgrades are possible. However, if many devices require the same upgrades, the overall cost of the solution would be much higher.
The device SERVER001 is "trustworthy" because it meets the hardware requirements but its operating system must be upgraded. It also requires antivirus software. The projected cost is the amount of effort that is required to upgrade the operating system and install antivirus software, along with their purchase costs.
With the other information that you've gathered in this section, this information will be the foundation of the efforts performed later in the [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) section.
The costs identified in this section only capture the projected cost of the device upgrades. Many more design, support, test, and training costs should be accounted for in the overall project plan.
**Next:** [Planning Your Windows Defender Firewall with Advanced Security Design](planning-your-windows-firewall-with-advanced-security-design.md)

View File

@ -1,30 +0,0 @@
---
title: Enable Predefined Inbound Rules
description: Learn the rules for Windows Defender Firewall with Advanced Security for common networking roles and functions.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Enable Predefined Inbound Rules
Windows Defender Firewall with Advanced Security includes many predefined rules for common networking roles and functions. When you install a new server role on a device or enable a network feature on a client device, the installer typically enables the rules required for that role instead of creating new ones. When deploying firewall rules to the devices on the network, you can take advantage of these predefined rules instead of creating new ones. Using this advantage helps to ensure consistency and accuracy, because the rules have been thoroughly tested and are ready for use.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
To deploy predefined firewall rules that allow inbound network traffic for common network functions
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Inbound Rules**.
3. Click **Action**, and then click **New rule**.
4. On the **Rule Type** page of the New Inbound Rule Wizard, click **Predefined**, select the rule category from the list, and then click **Next**.
5. On the **Predefined Rules** page, the list of rules defined in the group is displayed. By default, they're all selected. For rules that you don't want to deploy, clear the check boxes next to the rules, and then click **Next**.
6. On the **Action** page, select **Allow the connection**, and then click **Finish**.

View File

@ -1,32 +0,0 @@
---
title: Enable Predefined Outbound Rules
description: Learn to deploy predefined firewall rules that block outbound network traffic for common network functions in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Enable Predefined Outbound Rules
By default, Windows Defender Firewall with Advanced Security allows all outbound network traffic unless it matches a rule that prohibits the traffic. Windows Defender Firewall includes many predefined outbound rules that can be used to block network traffic for common networking roles and functions. When you install a new server role on a computer or enable a network feature on a client computer, the installer can install, but typically doesn't enable, outbound block rules for that role. When deploying firewall rules to the computers on the network, you can take advantage of these predefined rules instead of creating new ones. Using this advantage helps to ensure consistency and accuracy, because the rules have been thoroughly tested and are ready for use.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
To deploy predefined firewall rules that block outbound network traffic for common network functions
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Outbound Rules**.
3. Click **Action**, and then click **New rule**.
4. On the **Rule Type** page of the New Inbound Rule Wizard, click **Predefined**, select the rule category from the list, and then click **Next**.
5. On the **Predefined Rules** page, the list of rules defined in the group is displayed. They're all selected by default. For rules that you don't want to deploy, clear the check boxes next to the rules, and then click **Next**.
6. On the **Action** page, select **Block the connection**, and then click **Finish**.
The selected rules are added to the GPO.

View File

@ -1,24 +0,0 @@
---
title: Exempt ICMP from Authentication
description: Learn how to add exemptions for any network traffic that uses the ICMP protocol in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Exempt ICMP from Authentication
This procedure shows you how to add exemptions for any network traffic that uses the ICMP protocol.
**Administrative credentials**
To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
To exempt ICMP network traffic from authentication
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. On the main Windows Defender Firewall with Advanced Security page, click **Windows Defender Firewall Properties**.
3. On the **IPsec settings** tab, change **Exempt ICMP from IPsec** to **Yes**, and then click **OK**.

View File

@ -1,26 +0,0 @@
---
title: Gathering Information about Your Active Directory Deployment
description: Learn about gathering Active Directory information, including domain layout, organizational unit architecture, and site topology, for your firewall deployment.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Gathering Information about Your Active Directory Deployment
Active Directory is another important item about which you must gather information. You must understand the forest structure. This structure includes domain layout, organizational unit (OU) architecture, and site topology. This information makes it possible to know where devices are currently placed, their configuration, and the impact of changes to Active Directory that result from implementing Windows Defender Firewall with Advanced Security. Review the following list for information needed:
- **Names and number of forests**. The forest (not the domain) is the security boundary in an Active Directory implementation. You must understand the current Active Directory architecture to determine the most effective strategy for deploying your firewall and connection security rules using Group Policy. It also enables you to understand which devices can be isolated and how best to accomplish the required degree of isolation.
- **Names and number of domains**. Authentication in server and domain isolation uses the IKE negotiation process with the Kerberos V5 protocol. This protocol assumes that devices are domain members.
- **Number and types of trusts**. Trusts affect the logical boundaries of domain isolation and define whether IKE negotiation can occur between devices in different Active Directory domains.
- **Names and number of sites**. Site architecture is aligned with the network topology. Understanding how sites are defined in Active Directory will help provide insight into replication and other details. Site architecture can provide a better understanding of the current Active Directory deployment.
- **OU structure**. OUs are logical constructs and can therefore be molded to fit many different requirements and goals. The OU structure is an ideal place to examine how Group Policy is currently used and how the OUs are laid out. You don't have to redesign an already implemented OU structure in order to effectively deploy firewall and connection security policy, but an understanding of the structure helps you know what WMI or group filtering is required to apply each GPO to the correct devices.
- **Existing IPsec policy**. Because this project culminates in the implementation of IPsec policy, you must understand how the network currently uses IPsec (if at all). Windows Defender Firewall connection security rules for versions of Windows prior to Windows Vista and Windows Server 2008 aren't compatible with earlier versions of Windows. If you already have IPsec policies deployed to devices running Windows XP and Windows Server 2003 in your organization, you must ensure that the new IPsec policies you deploy enable devices using either the old or new IPsec policies to communicate with each other.
**Next:** [Gathering Information about Your Devices](gathering-information-about-your-devices.md)

View File

@ -1,107 +0,0 @@
---
title: Gathering Info about Your Network Infrastructure
description: Learn how to gather info about your network infrastructure so that you can effectively plan for Windows Defender Firewall with Advanced Security deployment.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Gathering Information about Your Current Network Infrastructure
Perhaps the most important aspect of planning for Windows Defender Firewall with Advanced Security deployment is the network architecture, because IPsec is layered on the Internet Protocol itself. An incomplete or inaccurate understanding of the network can prevent any Windows Defender Firewall solution from being successful. Understanding subnet layout, IP addressing schemes, and traffic patterns are part of this effort, but accurately documenting the following components are important to completing the planning phase of this project:
- **Network segmentation**. This component includes IP addressing maps, showing how your routers separate each network segment. It includes information about how the routers are configured, and what security filters they impose on network traffic flowing through them.
- Network address translation (NAT). NAT is a means of separating network segments by using a device that maps all of the IP addresses on one side of the device to a single IP address accessible on the other side.
- Network infrastructure devices. These devices include the routers, switches, hubs, and other network equipment that makes communications between the devices on the network possible.
- **Current network traffic model.** This component includes the quantity and the characteristics of the network traffic flowing through your network.
- Intrusion Detection System (IDS) devices. You'll need to identify if you have any IDS devices on your network that might be negatively impacted by any encryption introduced in an Encryption Zone.
The goal is to have enough information to be able to identify an asset by its network location, in addition to its physical location.
Don't use a complex and poorly documented network as a starting point for the design, because it can leave too many unidentified areas that are likely to cause problems during implementation.
This guidance helps obtain the most relevant information for planning Windows Defender Firewall implementation, but it doesn't try to address other issues, such as TCP/IP addressing or virtual local area network (VLAN) segmentation.
## Network segmentation
If your organization doesn't have its current network architecture documented and available for reference, such documentation should be obtained as soon as possible before you continue with the design and deployment. If the documented information isn't current or hasn't been validated recently, you have two options:
- Accept that the lack of accurate information can cause risk to the project.
- Undertake a discovery project, either through manual processes or with network analysis tools that can provide the information you need to document the current network topology.
Although the required information can be presented in many different ways, a series of schematic diagrams is often the most effective method of illustrating and understanding the current network configuration. When creating network diagrams, don't include too much information. If necessary, use multiple diagrams that show different layers of detail. Use a top-level diagram that illustrates the major sites that make up your organization's network, and then break out each site into a more detailed diagram that captures a deeper level of detail. Continue until you reach the individual IP subnet level, and so have the means to identify the network location of every device in your organization.
During this process, you might discover some network applications and services that aren't compatible with IPsec. For example, IPsec breaks network-based prioritization and port/protocol-based traffic management. If traffic management or prioritization must be based on ports or protocol, the host itself must be able to perform any traffic management or prioritization.
Other examples of incompatibility include:
- Cisco NetFlow on routers can't analyze packets between IPsec members based on protocol or port.
- Router-based Quality of Service (QoS) can't use ports or protocols to prioritize traffic. However, using firewall rules that specify IP addresses to prioritize traffic aren't affected by this limitation of QoS. For example, a rule that says "From anyone to anyone using port 80 prioritize" doesn't work, but a rule that says "From anyone to 10.0.1.10 prioritize" works.
- Weighted Fair Queuing and other flow-based router traffic priority methods might fail.
- Devices that don't support or allow IP protocol 50, the port that is used by Encapsulating Security Payload (ESP).
- Router access control lists (ACLs) can't examine protocol and port fields in ESP-encrypted packets, and therefore the packets are dropped. ACLs based only on IP address are forwarded as usual. If the device can't parse ESP, any ACLs that specify port or protocol rules won't be processed on the ESP packets. If the device has an ESP parser and uses encryption, ACLs that specify port or protocol rules won't be processed on the ESP packets.
- Network monitoring tools might be unable to parse ESP packets that aren't encrypted (ESP-Null).
>**Note:**  Microsoft Message Analyzer can help in troubleshooting of unencrypted IPsec packets. The latest version of Message Analyzer is available on the [Microsoft Download Center](/message-analyzer/microsoft-message-analyzer-operating-guide).
 
## Network address translation (NAT)
IPsec NAT traversal (NAT-T) enables IPsec peers that are behind NATs to detect the presence of NATs, negotiate IPsec security associations (SAs), and send ESP-protected data even though the addresses in the IPsec-protected IPv4 packets change. IPsec NAT-T doesn't support the use of AH across NAT devices.
## Network infrastructure devices
The devices that make up the network infrastructure (routers, switches, load balancers, and firewalls) must be able communicate using IPsec after the solution is implemented. For this reason, you have to examine the following characteristics of these network devices to ensure that they can handle the technical and physical requirements of the design:
- **Make/model**. You can use this information to determine the features that the device supports. In addition, check the BIOS version or software running on the device to ensure that IPsec is supported.
- **Amount of RAM**. This information is useful when you're analyzing capacity or the impact of IPsec on the device.
- **Traffic analysis**. Information, such as peak usage and daily or weekly trends, is helpful to have. The information helps provide a baseline snapshot of the device and how it's used over time. If problems occur after IPsec is implemented, the information can help determine whether the root cause is related to greater usage of the device.
- **Router ACLs that affect IPsec directly**. ACLs directly affect the ability of specific protocols to function. For example, blocking the Kerberos V5 protocol (UDP and TCP port 88) or IP protocol 50 or 51 prevents IPsec from working. Devices must also be configured to allow IKE traffic (UDP port 500) if using NAT-T (UDP port 4500).
- **Networks/subnets connected to device interfaces**. This information provides the best picture of what the internal network looks like. Defining the boundary of subnets based on an address range is straightforward and helps identify whether other addresses are either unmanaged or foreign to the internal network (such as IP addresses on the Internet).
- **VLAN segmentation**. Determining how VLANs are implemented on the network can help you understand traffic patterns and security requirements, and then help to determine how IPsec might augment or interfere with these requirements.
- **The maximum transmission unit (MTU) size on device interface(s)**. The MTU defines the largest datagram that can be transmitted on a particular interface without being divided into smaller pieces for transmission (a process also known as *fragmentation*). In IPsec communications, the MTU is necessary to anticipate when fragmentation occurs. Packet fragmentation must be tracked for Internet Security Association and Key Management Protocol (ISAKMP) by the router. IPsec configures the MTU size on the session to the minimum-discovered MTU size along the communication path being used, and then set the Don't Fragment bit (DF bit) to 1.
>**Note:**  If Path MTU (PMTU) discovery is enabled and functioning correctly, you do not have to gather the MTU size on device interfaces. Although sources, such as the Windows Server 2003 Hardening Guide, recommend disabling PMTU discovery, it must be enabled for IPsec to function correctly.
- **Intrusion detection system (IDS) in use**. Your IDS must have an IPsec-compatible parser to detect ESP packets. If the IDS doesn't have such a parser, it can't determine if data in those packets is encrypted.
After you obtain this information, you can quickly determine whether you must upgrade the devices to support the requirements of the project, change the ACLs, or take other measures to ensure that the devices can handle the loads needed.
## Current network traffic model
After you gather the addressing and network infrastructure information, the next step is to examine the communications flow. For example, if a department such as Human Resources (HR) spans several buildings, and you want to use server isolation with encryption to help protect information in that department, you must know how those buildings are connected to determine the level of "trust" to place in the connection. A highly secured building that is connected by an unprotected cable to another building that isn't secured can be compromised by an eavesdropping or information replay attack. If such an attack is considered a threat, IPsec can help by providing strong mutual authentication and traffic encryption for trusted hosts. IPsec allows you to more securely communicate across untrusted links such as the Internet.
When you examine traffic flow, look closely at how all managed and unmanaged devices interact. These devices include non-Windows-based devices running Linux, UNIX, and Macintosh. Ask yourself such questions as:
- Do specific communications occur at the port and protocol level, or are there many sessions between the same hosts across many protocols?
- How do servers and clients communicate with each other?
- Are there security devices or projects currently implemented or planned that could affect an isolation deployment? For example, if you use Windows Defender Firewall on your devices to "lock down" specific ports, such as UDP 500, IKE negotiations fail.
Some of the more common applications and protocols are as follows:
- **NetBIOS over TCP/IP (NetBT) and server message block (SMB)**. On a LAN, it's common to have ports 137, 138, and 139 enabled for NetBT and port 445 enabled for SMB. These ports provide NetBIOS name resolution services and other features. Unfortunately, they also allow the creation of *null sessions*. A null session is a session that is established on a host that doesn't use the security context of a known user or entity. Frequently, these sessions are anonymous.
- **Remote procedure call (RPC)**. RPC operates by listening on a port known as the *endpoint mapper*, TCP port 135. The response to a query on this port is an instruction to begin communication on another port in the ephemeral range (ports numbered over 1024). In a network that is segmented by firewalls, RPC communication presents a configuration challenge because it means to open the RPC listener port, and all ports greater than 1024. Opening so many ports increases the attack surface of the whole network and reduces the effectiveness of the firewalls. Because many applications depend on RPC for basic functionality, any firewall and connection security policy must take RPC requirements into account.
- **Other traffic**. Windows Defender Firewall can help secure transmissions between devices by providing authentication of the packets in addition to encrypting the data that they contain. The important thing to do is to identify what must be protected, and the threats that must be mitigated. Examine and model other traffic or traffic types that must be secured.
**Next:** [Gathering Information about Your Active Directory Deployment](gathering-information-about-your-active-directory-deployment.md)

View File

@ -1,48 +0,0 @@
---
title: Gathering Information about Your Devices
description: Learn what information to gather about the devices in your enterprise to plan your Windows Defender Firewall with Advanced Security deployment.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Gathering Information about Your Devices
One of the most valuable benefits of conducting an asset discovery project is the large amount of data that is obtained about the client and server devices on the network. When you start designing and planning your isolation zones, you must make decisions that require accurate information about the state of all hosts to ensure that they can use IPsec as planned.
Capture the following information from each device:
- **Computer name**. This name is the device's NetBIOS or DNS name that identifies the device on the network. Because a device can have more than one media access control (MAC) or IP address, the device's name is one of the criteria that can be used to determine uniqueness on the network. Because device names can be duplicated under some circumstances, the uniqueness shouldn't be considered absolute.
- **IP address for each network adapter**. The IP address is the address that is used with the subnet mask to identify a host on the network. An IP address isn't an effective way to identify an asset because it's often subject to change.
- **Operating system, service pack, and hotfix versions**. The operating system version is a key factor in determining the ability of a host to communicate by using IPsec. It's also important to track the current state of service packs and updates that might be installed, because these packs and updates are often used to determine that minimum security standards have been met.
- **Domain membership**. This information is used to determine whether a device can obtain IPsec policy from Active Directory or whether it must use a local IPsec policy.
- **Physical location**. This information is just the location of the device in your organization. It can be used to determine whether a device can participate in a specific isolation group based on its location or the location of the devices that it communicates with regularly.
- **Hardware type or role**. Some tools that perform host discovery can provide this information by querying the hardware information and running applications to determine its type, such as server, workstation, or portable device. You can use this information to determine the appropriate IPsec policy to assign, whether a specific device can participate in isolation, and in which isolation group to include the device.
After collecting all this information and consolidating it into a database, perform regular discovery efforts periodically to keep the information current. You need the most complete and up-to-date picture of the managed hosts on their networks to create a design that matches your organization's requirements.
You can use various methods to gather data from the hosts on the network. These methods range from high-end, fully automated systems to manual data collection. Generally, the use of automated methods to gather data is preferred over manual methods for reasons of speed and accuracy.
## Automated Discovery
Using an automated auditing network management system provides valuable information about the current state of the IT infrastructure.
## Manual Discovery
The biggest difference between manual discovery methods and automated methods is time.
You can use Windows PowerShell to create a script file that can collect the system configuration information. For more information, see [Windows PowerShell Scripting](https://go.microsoft.com/fwlink/?linkid=110413).
Whether you use an automatic, manual, or hybrid option to gather the information, one of the biggest issues that can cause problems to the design is capturing the changes between the original inventory scan and the point at which the implementation is ready to start. After the first scan has been completed, make support staff aware that all other changes must be recorded and the updates noted in the inventory.
This inventory will be critical for planning and implementing your Windows Defender Firewall design.
**Next:** [Gathering Other Relevant Information](gathering-other-relevant-information.md)

View File

@ -1,69 +0,0 @@
---
title: Gathering Other Relevant Information
description: Learn about additional information you may need to gather to deploy Windows Defender Firewall with Advanced Security policies in your organization.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Gathering Other Relevant Information
This topic discusses several other things that you should examine to see whether they'll cause any complications in your ability to deploy Windows Defender Firewall with Advanced Security policies in your organization.
## Capacity considerations
Because IPsec uses mathematically intensive cryptographic techniques, it can consume significant overhead on a device. Areas to watch:
- **Encryption.** You might use 256-bit Advanced Encryption Standard (AES-256) and 384-bit Secure Hash Algorithm (SHA-384) to check integrity in situations that require the strongest available encryption and key exchange protection. If you have NICs that support IPsec Task Offload, you can reduce the effect that encryption has on network throughput. For more information, see [IPsec Task Offload](/previous-versions/windows/it-pro/windows-server-2003/cc776369(v=ws.10)).
- **Security association (SA) negotiation.** You can use a shorter lifetime for the main mode SA, such as three hours, but then you might need to make tradeoffs. Because each main mode SA occupies approximately 5  KB of RAM, situations in which a server brokers tens of thousands of concurrent connections can lead to overutilization.
- **NAT devices.** As discussed earlier, NAT doesn't allow Authentication Header (AH) conversations between hosts. If NAT devices exist on the internal network, ESP must be selected instead of AH.
- **Switches and routers.** Proper capacity planning for the implementation of IPsec is more about thorough testing and expected traffic loads than exact calculations. You might have to upgrade or reconfigure switches or routers that currently exceed 75 percent usage to allow for increased traffic on the device and still provide some extra usage for bursts of traffic.
- **Other factors.** These include CPU usage on network infrastructure servers, increased overhead on servers and workstations running IPsec (especially servers, because they usually contain more main mode SAs than clients), and increased network latency because of IPsec negotiation.
>**Note:**  When Microsoft deployed its own domain isolation solution, it found a one to three percent increase in usage on the network as a direct result of IPsec.
## Group Policy deployment groups and WMI filters
You don't have to rearrange the organization unit (OU) hierarchy of your Active Directory domains to effectively deploy Windows Defender Firewall GPOs. Instead, you can link your GPOs at the domain level (or another high level container), and then use security group filtering or WMI filtering to ensure that only the appropriate devices or users can apply the GPO settings. We recommend that you use WMI filtering to dynamically ensure that GPOs apply only to devices that are running the correct operating system. It's not necessary to use this technique if your network consists of devices.
## Different Active Directory trust environments
When you design a domain isolation policy, consider any logical boundaries that might affect IPsec-secured communications. For example, the trust relationships between your domains and forests are critical in determining an appropriate IKE authentication method.
Kerberos V5 authentication is recommended for use in a two-way (mutual) domain and forest trust environment. You can use Kerberos V5 for IKE authentication across domains that have two-way trusts established, if the domains are in the same forest or different forests. If the two domains are in different forests, you must configure two external trusts, one for each direction, between the domains. The external trusts must use the fully qualified domain name (FQDN) of the domains, and IPsec policy must allow an IKE initiator in one domain to communicate with any domain controller in the forest domain hierarchy, so that the initiator can obtain a Kerberos V5 ticket from a domain controller in the responders domain. If firewalls separate the domains, then you must configure the firewall to allow Kerberos V5 traffic over UDP destination port 88, TCP destination port 88, and UDP destination port 389.
If the use of Kerberos V5 authentication isn't possible because two-way trusts across forests can't be established as in some large enterprise environments, you can use a public key infrastructure (PKI) and digital certificates to establish IPsec-trusted communication.
## Creating firewall rules to permit IKE, AH, and ESP traffic
In some cases, IPsec-secured traffic might have to pass through a router, perimeter firewall, or other filtering device. If there's a router, unless the router filters TCP and UDP traffic or other upper-level protocol headers, no special configuration is required to allow the IPsec traffic to be forwarded.
If there's a filtering router or a firewall, you must configure these devices to allow IPsec traffic to be forwarded. Configure the firewall to allow IPsec traffic on UDP source and destination port 500 (IKE), UDP source and destination port 4500 (IPsec NAT-T), and IP Protocol 50 (ESP). You might also have to configure the firewall to allow IPsec traffic on IP protocol 51 (AH) to allow troubleshooting by IPsec administrators and to allow the IPsec traffic to be inspected.
## Network load balancing and server clusters
There are challenges implementing connection security for network traffic going to and from network load balancing (NLB) clusters and server clusters. NLB enables multiple servers to be clustered together to provide high availability for a service by providing automatic failover to other nodes in the cluster. Because IPsec matches a security association to a specific device, it prevents different devices from handling the same client connection. If a different node in the cluster responds to an IPsec connection that was originally established by another node, the traffic will be dropped by the client device as untrusted.
This dropping of traffic means that NLB in "no affinity" mode isn't supported by IPsec at all. If you must use "no affinity" mode in the cluster, then consider including the servers that make up the cluster in your IPsec exemption group, and allowing clients to communicate with the servers without IPsec.
When a TCP connection is dropped because of a cluster node failover, IPsec detects the TCP connection failure and removes the IPsec SAs for that connection. When the new TCP connection is established to another node, IPsec can negotiate new SAs immediately without having to wait for the obsolete SAs to time out.
## Network inspection technologies
Within a TCP/IP packet, IPsec without encryption changes the offsets for the destination ports and protocols. These changes can adversely affect applications that are running on network devices such as routers that monitor and manage traffic on the network. While some network applications have been updated to support IPsec, some aren't yet compatible. Check with the vendor of your device to see whether the changes in the protocol and port fields caused by IPsec are compatible with the device.
Any device designed to view network traffic, such as hardware protocol analyzers or Microsoft Network Monitor, can't parse ESP-encrypted traffic. Only the destination device, with which the originating device negotiated the connection, can decrypt the traffic.
In general, IPsec defeats network-based prioritization and port- or protocol-based traffic management. For encrypted packets, there's no workaround; the host itself must handle any traffic management functions. For unencrypted, authenticated-only packets, the devices and applications must be aware of how IPsec changes packets to be able to do anything with them other than route them to the correct host. If you can't upgrade monitoring or management devices to support IPsec, it's important that you record this information and figure it into your domain or server isolation design.
Network Monitor includes parsers for the ISAKMP (IKE), AH, and ESP protocols. Network Monitor parsers for ESP can parse inside the ESP packet only if ESP null-encryption is being used. Network Monitor can't parse the encrypted parts of IPsec ESP traffic when encryption is performed in software. However, if encryption is performed by an IPsec hardware offload network adapter, the ESP packets can be decrypted when Network Monitor captures them on either the source or the destination and, therefore, they can be parsed. To diagnose ESP software-encrypted communication, you must disable ESP encryption and use ESP-null encryption by changing the IPsec policy or connection security rule on both devices.
Message Analyzer is available on the [Microsoft Download Center](/message-analyzer/microsoft-message-analyzer-operating-guide).
**Next:** [Determining the Trusted State of Your Devices](determining-the-trusted-state-of-your-devices.md)

View File

@ -1,22 +0,0 @@
---
title: Gathering the Information You Need
description: Collect and analyze information about your network, directory services, and devices to prepare for Windows Defender Firewall with Advanced Security deployment.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Gathering the Information You Need
Before starting the planning process for a Windows Defender Firewall with Advanced Security deployment, you must collect and analyze up-to-date information about the network, the directory services, and the devices that are already deployed in the organization. This information enables you to create a design that accounts for all possible elements of the existing infrastructure. If the gathered information isn't accurate, problems can occur when devices and devices that weren't considered during the planning phase are encountered during implementation.
Review each of the following articles for guidance about the kinds of information that you must gather:
- [Gathering Information about Your Conversational Network Infrastructure](gathering-information-about-your-current-network-infrastructure.md)
- [Gathering Information about Your Active Directory Deployment](gathering-information-about-your-active-directory-deployment.md)
- [Gathering Information about Your Devices](gathering-information-about-your-devices.md)
- [Gathering Other Relevant Information](gathering-other-relevant-information.md)

View File

@ -1,32 +0,0 @@
---
title: Link the GPO to the Domain
description: Learn how to link a GPO to the Active Directory container for the target devices, after you configure it in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Link the GPO to the Domain
After you create the GPO and configure it with security group filters and WMI filters, you must link the GPO to the container in Active Directory that contains all of the target devices.
If the filters comprehensively control the application of the GPO to only the correct devices, then you can link the GPO to the domain container. Alternatively, you can link the GPO to a site container or organizational unit if you want to limit application of the GPO to that subset of devices.
**Administrative credentials**
To complete this procedure, you must be a member of the Domain Admins group, or otherwise be delegated permissions to modify the GPOs.
To link the GPO to the domain container in Active Directory
1. Open the Group Policy Management console.
2. In the navigation pane, expand **Forest:** *YourForestName*, expand **Domains**, and then expand *YourDomainName*.
3. Right-click *YourDomainName*, and then click **Link an Existing GPO**.
4. In the **Select GPO** dialog box, select the GPO that you want to deploy, and then click **OK**.
5. The GPO appears in the **Linked Group Policy Objects** tab in the details pane and as a linked item under the domain container in the navigation pane.
6. You can adjust the order of the linked GPOs to ensure that the higher priority GPOs are processed last. Select a GPO and click the up or down arrows to move it. The GPOs are processed by the client device from the highest link order number to the lowest.

View File

@ -1,68 +0,0 @@
---
title: Modify GPO Filters
description: Learn how to modify GPO filters to apply to a different zone or version of windows in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Modify GPO Filters to Apply to a Different Zone or Version of Windows
You must reconfigure your copied GPO so that it contains the correct security group and WMI filters for its new role. If you are creating the GPO for the isolated domain, use the [Block members of a group from applying a GPO](#to-block-members-of-a-group-from-applying-a-gpo) procedure to prevent members of the boundary and encryption zones from incorrectly applying the GPOs for the main isolated domain.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
In this topic:
- [Change the security group filter for a GPO](#to-change-the-security-group-filter-for-a-gpo)
- [Block members of a group from applying a GPO](#to-block-members-of-a-group-from-applying-a-gpo)
- [Remove a block for members of a group from applying a GPO](#to-remove-a-block-for-members-of-group-from-applying-a-gpo)
## To change the security group filter for a GPO
1. Open the Group Policy Management console.
2. In the navigation pane, find and then click the GPO that you want to modify.
3. In the details pane, under **Security Filtering**, click the currently assigned security group, and then click **Remove**.
4. Now you can add the appropriate security group to this GPO. Under **Security Filtering**, click **Add**.
5. In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to apply the GPO, and then click **OK**. If you do not know the name, you can click **Advanced** to browse the list of groups available in the domain.
## To block members of a group from applying a GPO
1. Open the Group Policy Management console.
2. In the navigation pane, find and then click the GPO that you want to modify.
3. In the details pane, click the **Delegation** tab.
4. Click **Advanced**.
5. Under the **Group or user names** list, click **Add**.
6. In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to be prevented from applying the GPO, and then click **OK**. If you do not know the name, you can click **Advanced** to browse the list of groups available in the domain.
7. Select the group in the **Group or user names** list, and then select the boxes in the **Deny** column for both **Read** and **Apply group policy**.
8. Click **OK**, and then in the **Windows Security** dialog box, click **Yes**.
9. The group appears in the list with custom permissions.
## To remove a block for members of group from applying a GPO
1. Open the Group Policy Management console.
2. In the navigation pane, find and then click the GPO that you want to modify.
3. In the details pane, click the **Delegation** tab.
4. In the **Groups and users** list, select the group that should no longer be blocked, and then click **Remove**.
5. In the message box, click **OK**.

View File

@ -1,20 +0,0 @@
---
title: Open the Group Policy Management Console to IP Security Policies
description: Learn how to open the Group Policy Management Console to IP Security Policies to configure GPOs for earlier versions of the Windows operating system.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Open the Group Policy Management Console to IP Security Policies
Procedures in this guide that refer to GPOs for earlier versions of the Windows operating system instruct you to work with the IP Security Policy section in the Group Policy Management Console (GPMC).
**To open a GPO to the IP Security Policies section**
1. Open the Group Policy Management console.
2. In the navigation pane, expand **Forest:** *YourForestName*, expand **Domains**, expand *YourDomainName*, expand **Group Policy Objects**, right-click the GPO you want to modify, and then click **Edit**.
3. In the navigation pane of the Group Policy Management Editor, expand **Computer Configuration**, expand **Policies**, expand **Windows Settings**, expand **Security Settings**, and then click **IP Security Policies on Active Directory (**<em>YourDomainName</em>**)**.

View File

@ -1,24 +0,0 @@
---
title: Group Policy Management of Windows Firewall with Advanced Security
description: Group Policy Management of Windows Firewall with Advanced Security
ms.prod: windows-client
ms.collection:
- highpri
- tier3
- must-keep
ms.topic: conceptual
ms.date: 09/08/2021
---
# Group Policy Management of Windows Firewall with Advanced Security
Most of the procedures in this guide instruct you to use Group Policy settings for Windows Firewall with Advanced Security.
To open a GPO to Windows Firewall with Advanced Security
1. Open the Group Policy Management console.
2. In the navigation pane, expand **Forest:** *YourForestName*, expand **Domains**, expand *YourDomainName*, expand **Group Policy Objects**, right-click the GPO you want to modify, and then click **Edit**.
3. In the navigation pane of the Group Policy Management Editor, navigate to **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **Windows Firewall with Advanced Security** > **Windows Firewall with Advanced Security - LDAP://cn={**<em>GUID</em>**},cn=…**.

View File

@ -1,18 +0,0 @@
---
title: Group Policy Management of Windows Defender Firewall
description: Group Policy Management of Windows Defender Firewall with Advanced Security
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Group Policy Management of Windows Defender Firewall
To open a GPO to Windows Defender Firewall:
1. Open the Group Policy Management console.
2. In the navigation pane, expand **Forest:** *YourForestName*, expand **Domains**, expand *YourDomainName*, expand **Group Policy Objects**, right-click the GPO you want to modify, and then click **Edit**.
3. In the navigation pane of the Group Policy Object Editor, navigate to **Computer Configuration** > **Administrative Templates** > **Network** > **Network Connections** > **Windows Defender Firewall**.

View File

@ -1,34 +0,0 @@
---
title: Open Windows Defender Firewall with Advanced Security
description: Learn how to open the Windows Defender Firewall with Advanced Security console. You must be a member of the Administrators group.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Open Windows Defender Firewall with Advanced Security
This procedure shows you how to open the Windows Defender Firewall with Advanced Security console.
**Administrative credentials**
To complete this procedure, you must be a member of the Administrators group. For more information, see Additional considerations.
## To open Windows Defender Firewall using the UI
Click Start, type **Windows Defender Firewall**, and then press ENTER.
## To open Windows Defender Firewall from a command prompt
1. Open a command prompt window.
2. At the command prompt, type:
``` syntax
wf.msc
```
**Additional considerations**
Although standard users can start the Windows Defender Firewall MMC snap-in, to change most settings the user must be a member of a group with the permissions to modify those settings, such as Administrators.

View File

@ -1,38 +0,0 @@
---
title: Restrict Server Access to Members of a Group Only
description: Create a firewall rule to access isolated servers running Windows Server 2008 or later and restrict server access to members of a group.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Restrict Server Access to Members of a Group Only
After you have configured the IPsec connection security rules that force client devices to authenticate their connections to the isolated server, you must configure the rules that restrict access to only those devices or users who have been identified through the authentication process as members of the isolated servers access group.
In this topic:
- [Create a firewall rule to access isolated servers running Windows Server 2008 or later](#to-create-a-firewall-rule-that-grants-access-to-an-isolated-server)
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
## To create a firewall rule that grants access to an isolated server
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md). You must edit the GPO that applies settings to servers in the isolated server zone.
2. In the navigation pane, right-click **Inbound Rules**, and then click **New Rule**.
3. On the **Rule Type** page, click **Custom**, and then click **Next**.
4. If you must restrict access to a single network program, then you can select **This program path**, and specify the program or service to which to grant access. Otherwise, click **All programs**, and then click **Next**.
5. If you must restrict access to only some TCP or UDP port numbers, then enter the port numbers on the **Protocol and Ports** page. Otherwise, set **Protocol type** to **Any**, and then click **Next**.
6. On the **Scope** page, select **Any IP address** for both local and remote addresses, and then click **Next**.
7. On the **Action** page, click **Allow the connection if it is secure**. If required by your design, you can also click **Customize** and select **Require the connections to be encrypted**. Click **Next**.
8. On the **Users and Computers** page, select the check box for the type of accounts (computer or user) you want to allow, click **Add**, and then enter the group account that contains the device and user accounts permitted to access the server.

View File

@ -1,43 +0,0 @@
---
title: Turn on Windows Defender Firewall with Advanced Security and Configure Default Behavior
description: Turn on Windows Defender Firewall with Advanced Security and Configure Default Behavior
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Turn on Windows Defender Firewall with Advanced Security and Configure Default Behavior
To enable Windows Defender Firewall with Advanced Security and configure its default behavior, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
## To enable Windows Defender Firewall and configure the default behavior
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the details pane, in the **Overview** section, click **Windows Defender Firewall Properties**.
3. For each network location type (Domain, Private, Public), perform the following steps.
>**Note:**  The steps shown here indicate the recommended values for a typical deployment. Use the settings that are appropriate for your firewall design.
1. Click the tab that corresponds to the network location type.
2. Change **Firewall state** to **On (recommended)**.
3. Change **Inbound connections** to **Block (default)**.
4. Change **Outbound connections** to **Allow (default)**.
 
 

View File

@ -1,59 +0,0 @@
---
title: Verify That Network Traffic Is Authenticated
description: Learn how to confirm that network traffic is being protected by IPsec authentication after you configure your domain isolation rule to require authentication.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Verify That Network Traffic Is Authenticated
After you've configured your domain isolation rule to request, rather than require, authentication, you must confirm that the network traffic sent by the devices on the network is being protected by IPsec authentication as expected. If you switch your rules to require authentication before all of the devices have received and applied the correct GPOs, or if there are any errors in your rules, then communications on the network can fail. By first setting the rules to request authentication, any network connections that fail authentication can continue in clear text while you diagnose and troubleshoot.
In these procedures, you confirm that the rules you deployed are working correctly. Your next steps depend on which zone you're working on:
- **Main domain isolation zone.** Before you convert your main domain isolation IPsec rule from request mode to require mode, you must make sure that the network traffic is protected according to your design. By configuring your rules to request and not require authentication at the beginning of operations, devices on the network can continue to communicate even when the main mode authentication or quick mode integrity and encryption rules aren't working correctly. For example, if your encryption zone contains rules that require a certain encryption algorithm, but that algorithm isn't included in a security method combination on the clients, then those clients can't successfully negotiate a quick mode security association, and the server refuses to accept network traffic from the client. By first using request mode only, you have the opportunity to deploy your rules and then examine the network traffic to see if they're working as expected without risking a loss of communications.
- **Boundary zone.** Confirming correct operation of IPsec is the last step if you're working on the boundary zone GPO. You don't convert the GPO to require mode at any time.
- **Encryption zone.** Similar to the main isolation zone, after you confirm that the network traffic to zone members is properly authenticated and encrypted, you must convert your zone rules from request mode to require mode.
> [!NOTE]
> In addition to the steps shown in this procedure, you can also use network traffic capture tools such as [Microsoft Network Monitor](https://www.microsoft.com/download/4865). Network Monitor and similar tools allow you to capture, parse, and display the network packets received by the network adapter on your device. Current versions of these tools include full support for IPsec. They can identify encrypted network packets, but they cannot decrypt them.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
## To verify that network connections are authenticated by using the Windows Defender Firewall with Advanced Security console
1. Open the Windows Defender Firewall with Advanced Security
console.
2. In the navigation pane, expand **Monitoring**, and then click **Connection Security Rules**.
The details pane displays the rules currently in effect on the device.
3. **To display the Rule Source column**
1. In the **Actions** pane, click **View**, and then click **Add/Remove Columns**.
2. In the **Available columns** list, select **Rule Source**, and then click **Add**.
3. Use the **Move up** and **Move down** buttons to rearrange the order. Click **OK** when you're finished.
It can take a few moments for the list to be refreshed with the newly added column.
4. Examine the list for the rules from GPOs that you expect to be applied to this device.
>**Note:**  If the rules do not appear in the list, then troubleshoot the GPO security group and the WMI filters that are applied to the GPO. Make sure that the local device is a member of the appropriate groups and meets the requirements of the WMI filters.
5. In the navigation pane, expand **Security Associations**, and then click **Main Mode**.
The current list of main mode associations that have been negotiated with other devices appears in the details column.
6. Examine the list of main mode security associations for sessions between the local device and the remote device. Make sure that the **1st Authentication Method** and **2nd Authentication Method** columns contain expected values. If your rules specify only a first authentication method, then the **2nd Authentication Method** column displays **No authentication**. If you double-click the row, then the **Properties** dialog box appears with more details about the security association.
7. In the navigation pane, click **Quick mode**.
8. Examine the list of quick mode security associations for sessions between the local device and the remote device. Make sure that the **AH Integrity**, **ESP integrity**, and **ESP Confidentiality** columns contain expected values.